What an attacker sees before doing anything

A lot about a website's security can be found out from the outside, without logging in: what system runs under it, how far behind its updates are, and whether the versions it runs have known flaws. Automated attacks also begin by collecting public data. In the July 2026 attack on Hugging Face, 10 July was a quiet day: the agents mostly searched code search engines and Hugging Face's public API for the identifiers they had seen in their own environment. The main attack began the next day.

What shows from outside, and how to check it

The table lists what can be read from an average WordPress site without logging in, and which public tool shows it.

What the source code gives away

The browser downloads the page source on every visit, and a lot stays in it. By default, WordPress writes its own version number into the page header, and plugin files are often loaded with their version: their address ends in ?ver= and a number. A readme.txt with the version can often be requested from the plugin's folder too.

The version is worth looking up in the public vulnerability databases. Several companies maintain one, for example WPScan, Patchstack and Wordfence. If the running version has an entry and the fixed release is already out, the flaw is public and the fix is not installed.

Hiding the version number helps little. Mass attacks typically try the flaw on every site without checking the version, while for the owner the version is exactly what shows what has fallen behind.

What the server's response gives away

Connecting shows how long the certificate is valid and which encryption the server allows. The response headers show which security rules the page asks the browser to follow, for example not to load scripts from elsewhere, or to come back only over an encrypted connection; and sometimes also which software runs on the server, in which version.

The certificate and the encryption settings are checked by the Qualys SSL Labs test, the headers by Mozilla's HTTP Observatory; both are free.

What gets left on the server

The riskiest layer is files that were not made for visitors and can still be requested: a database backup left behind after a move, a copy of wp-config.php, a log file that records errors along with server paths. A downloadable backup can give away the whole database, including users' data.

From outside, these can only be found by guessing: attack tools request the usual file names one after another, site after site. On your own site it is simpler to look from the inside. In the hosting file manager, anything in the root folder that is not meant for visitors is suspicious, for example files ending in .sql, .zip, .bak or .log, and old copies. What is needed should move above the root folder, and the rest can be deleted.

On my own site I found six such files in the root folder in August 2026: backups of the web server's settings, from which the whole rule set could be read. Since then, those backups go above the root folder.

If you check your own site

An outside check is best done slowly. Hosting servers often sit behind a protection system that treats dense, suspicious requests, such as many requests for non-existent files in a row, as an attack, and blocks whoever is asking.

It happened to me in August 2026: my own checking script requested a few non-existent files on my own site, and the host's firewall blocked my computer for hours. Neither the website, nor the server's command line, nor the hosting control panel was reachable, while visitors browsed without any trouble. Since then my checks identify themselves by name, pause between requests, and only request files I know exist.

What does not show from outside

Several important things only show from the inside: who has an admin account, whether backups are made and whether they can be restored, what is in the error log, and which plugins are installed but deactivated. A deactivated plugin's files stay on the server, and the ones that can be opened directly can still run while it is deactivated. These need access; what signals from the inside that a site has already been hacked is covered in a separate piece.

What to do with what you find

Urgent if the running version has a known flaw that has already been fixed, or if a backup can be downloaded. According to Patchstack's 2026 report, for mass-exploited WordPress flaws a median of five hours passed between disclosure and the first mass attack. The update is then worth installing the same day, with a full backup first.

Worth fixing: a certificate about to expire, missing security headers, and a server that announces its version. All three are a matter of settings.

Can wait: an overdue update with no known flaw. Putting it off for months is not worth it, though, because an update that skips several versions is more likely to break something.

What I do about it in my own work

I look at the sites I maintain from the outside every day, too. A check running in the cloud looks at whether the certificate or the domain is about to expire, whether every image and script loads, whether anything on the page arrives unencrypted, and whether a secret key has ended up in a page's source. The check deliberately does not run from my work computer: if the host's firewall blocked my computer again, the monitoring would keep working.

In the first assessment of a new site I go through the same part that shows from outside: what runs under it and how far behind it is, whether its versions have known flaws, and whether the certificate, the security headers and the email authentication are in order. I do not go looking for hidden files, and I do not try passwords. I write up what I find in three groups: what is urgent, what is worth fixing, and what can wait. No access is needed, and the assessment is free.

Questions on this topic

← Back to Writing