WordPress: the doors a default installation leaves open

A freshly installed WordPress website provides a range of addresses anyone can open without logging in. Most of them are meant for features a typical business website never uses.

That is no scandal and no fault of WordPress — it is a default meant for the general case. For your specific case it usually does not fit.

The pleasant part: you can check almost all of it yourself with the browser. These are addresses any visitor could type in. You do not have to log in anywhere, install anything or risk anything.

Why it matters

With these open addresses it is almost never about a single hole, but about groundwork.

An automated program that searches the internet for vulnerable websites first collects information: which software is running, in which version, what the users are called. Only then comes the actual attempt.

Each of these addresses is a piece of that groundwork done for it.

The order of magnitude: in 2025 more than 11,000 new vulnerabilities became known in the WordPress ecosystem, 91 percent of them in plugins. The median until the first mass exploitation is five hours.

So when a hole in a particular version becomes known, the websites that explicitly name their version are found first.

(Atlas, security/wordpress-attack-surface-2025-2026.md)

The open addresses one by one

The user list

/wp-json/wp/v2/users returns a list of users on a default installation — with display names and the slugs from which the login names can be derived.

Why it matters: a login consists of two parts. Whoever knows the user name has half. And user names are the part nobody changes regularly.

The author archives

/?author=1 redirects on a default installation to an author page whose address contains the login name.

The same result as above, by a different route. Whoever closes only the interface and forgets this has gained nothing.

The old remote interface

/xmlrpc.php is an interface from a time when blog posts were published from desktop programs. Hardly anyone needs it any more.

Why it is a problem: it allows bundled requests — many login attempts in a single call. That way limits that count per request can be sidestepped.

And a subtlety that is often overlooked: the usual switch for turning it off only blocks the methods that require a login. The pingback method keeps running unless it is removed separately. It is used for a type of attack in which other people's WordPress installations are abused as amplifiers.

The version number

It appears in several places: in /readme.html, in a declaration in the page head, and as a parameter on the addresses of style and script files.

On its own, a version number is harmless. It becomes relevant because of the five hours: whoever searches for the affected version finds first the websites that name it voluntarily.

The same goes for plugins — their versions are often in the file paths too.

Directory listings

When a directory without an index file is opened and the server outputs a list of files, anyone can see what is in it. With upload directories that is occasionally more than was intended.

The log file

The most serious case on this list. If error logging is switched on and the file is delivered through the web server, anyone can read it.

It contains whatever was logged when errors occurred — in the unfavourable case up to session identifiers with which someone can pose as a logged-in user.

That was exactly the vulnerability in a caching plugin with five million installations in 2024. No exotic case, but very widespread software.

(Atlas, wordpress/core/security/hardening-measures.md; security/wordpress-attack-surface-2025-2026.md)

The second, more harmless level

There is a related category that I explicitly rank lower than it is often presented: building blocks WordPress loads on every page even though the page does not need them.

They include the emoji converter, the connection script for the editing interface, the block stylesheet on pages without blocks, and a handful of old references in the page head for services, some of which no longer exist at all.

Honesty includes the classification: the old references in the page head come to a few hundred bytes together. Removing them is tidying up, not a loading-time optimisation. Whoever sells it as a speed measure is exaggerating.

What is still true about it: it is published surface the page does not use. And less of it is better than more.

With the emoji converter and the connection script the check is more worthwhile — they run on every page and the second one asks the server at regular intervals.

And an important caveat: if a page actually uses a feature, loading it is correct. Faulting the block stylesheet on a page built from blocks would mean advising the operator to damage their own page. Audit reports that fault everything loaded across the board are not helpful at this point.

How to check it yourself

Six addresses, six answers. Put them after your domain:

Address	What you want to see
/wp-json/wp/v2/users	no user list
/?author=1	no redirect to a name
/xmlrpc.php	an error page instead of “XML-RPC server accepts POST requests only”
/readme.html	an error page instead of a version number
/wp-content/uploads/	an error page instead of a file list
/wp-content/debug.log	an error page. Always.

For the version declaration in the page head: Ctrl+U, then Ctrl+F, search for name="generator".

And for the loaded building blocks: developer tools (F12), Network tab, reload the page. It shows what is actually loaded.

This check takes five minutes and can be repeated after every larger rebuild.

What to do

Most points are one line of configuration.

1. Close the user list and the author archives together. Remove the user endpoints from the interface registration and redirect requests with an author parameter to the home page. The two belong together — one alone achieves nothing.

2. Switch off the old remote interface twice: through the switch for the logged-in methods and by removing the pingback methods.

3. Remove version details — from the declaration in the page head and from the parameters on style and script addresses.

4. Lock the description files — answer readme.html, license.txt, wp-config-sample.php with an error response.

5. Switch off directory listings.

6. Error display off in production, logging on, log file not delivered by the server.

7. And when tidying up the building blocks: unhook the emoji converter, the connection script and the old references. The block stylesheet only where no blocks are actually used.

One point deliberately not without preparation: the login path can be moved. That is the only measure on this list where a mistake locks you out yourself. If you do it, then with a second administrator account for testing and with a backup.

What this is not

Two classifications that protect against wrong conclusions:

Recognisable plugins are not a defect. Which plugins run on a website can be read from outside from the file paths. That is an inventory, not an assessment. A plugin is not a problem because it can be recognised — it is a problem if it is outdated or not needed.

And this list is not the main thing. All the points here together weigh less than three other things: current software, few plugins, proper credentials.

Whoever closes all the doors and then does not update a plugin for a year has gained nothing. Whoever, conversely, updates cleanly and never touches this list is considerably better off.

So the order in practice is: first updates and backups, then clearing out plugins, then credentials and two-factor login — and then this list. It is cheap and quick, but it is not the beginning.

Sources

• Atlas, wordpress/core/security/hardening-measures.md — removing the user endpoints through the corresponding filter, redirecting requests with an author parameter, the note that the usual switch for the remote interface only blocks the logged-in methods and that the pingback method stays active without a separate intervention, removing the version number from the head declaration and from the script and style addresses, locking readme.html, readme.txt, license.txt and wp-config-sample.php with an error response, blocking the log file on the server, switching off the error display with logging active, unhooking the old references and the emoji entry from the page head, and the note that changing the login path is not safely reversible and should first be tested with a second administrator account.
• Atlas, security/wordpress-attack-surface-2025-2026.md — the median of five hours from publication to mass exploitation, the share of 91 percent of vulnerabilities in plugins, and the case CVE-2024-44000 in the LiteSpeed Cache plugin with five million installations, in which the log file gave away session identifiers.
• Atlas, threat-intel/patchstack-2026-state-of-wp-security.md — the more than 11,000 new vulnerabilities in the WordPress ecosystem in 2025.
• Rheinwerk, Barrierefreie Webseiten, ch. 13.3 — weighing the benefit and risk of plugins and the advance check based on the number of installations and the last update.
• Own audit practice — the six check addresses with their expected answers, the classification of the old head references as tidying up rather than a loading-time measure, the caveat that a building block actually in use is loaded correctly, the classification of recognisable plugins as an inventory rather than an assessment, and the ranking relative to updates, plugin reduction and credentials.