WordPress exposure: version, readme.html, install.php, directory listing

Attackers don't guess — they check 4 specific files. Tests #41 to #44 reveal whether your WordPress site is broadcasting its vulnerabilities to the world.

Before launching a real attack, every hacker runs the same checklist. They don't start with brute force or SQL injection. They start with reconnaissance — gathering information about the target. And WordPress makes it remarkably easy.

By default, WordPress exposes its version number in the HTML source, leaves a readme.html file in the root directory, keeps the installer script accessible, and lets anyone browse internal directories. Each of these is a free hint for an attacker.

Orilyt runs 4 complementary tests to detect these exposures. Test #41 checks version fingerprinting. Test #42 probes for readme.html and license.txt. Test #43 tests whether install.php is reachable. Test #44 checks directory listing on wp-content, wp-includes, uploads, plugins, and themes. Together, they map the entire information leak surface of a WordPress site.

Test #41: Is your WordPress version exposed?

Test #41 looks for 4 distinct signals that reveal your WordPress version to anyone who cares to look:

1. Meta generator tag — WordPress injects <meta name="generator" content="WordPress X.X"> into the HTML head by default. This is the most direct version disclosure. Any scanner picks it up instantly
2. Asset version strings — CSS and JS files from wp-includes and wp-content include ?ver=X.X.X query parameters. These version strings often match the WordPress core version exactly
3. REST API endpoint — /wp-json/ is accessible by default and confirms WordPress is running. The response includes namespace information that reveals the API version
4. Link header — WordPress sends a Link HTTP header referencing wp-json, confirming the CMS even before the page body loads

Scoring: if both the meta generator and asset version strings are present, the score drops to 30/100. One critical signal plus the REST API = 50. The REST API alone (without version data) = 80. If all signals are hidden, the score is 100.

Test #42: Are readme.html and license.txt accessible?

Every WordPress installation ships with two files at the root: readme.html and license.txt. They serve no purpose in production — but they confirm the CMS and may reveal version details:

1. readme.html — this file is a formatted HTML page that says "WordPress" in large text and often includes the exact version number. It's the simplest fingerprint check: request /readme.html, check if it returns 200
2. license.txt — contains the GPL license text with "WordPress" in the header. Less directly useful to attackers than readme.html, but it still confirms the CMS and that no hardening was applied

Scoring: both files accessible = 30/100. Only readme.html accessible = 40. Only license.txt = 60. Both return 403 or 404 = 100. These files should simply not be served in production.

Test #43: Is install.php reachable?

WordPress's installer lives at /wp-admin/install.php. On a properly configured site, this script either redirects to the login page or returns 403/404. But on misconfigured servers, it can be directly accessible:

1. The test requests /wp-admin/install.php and checks the HTTP response. If the response is 200 and the body contains "install WordPress" or "wp-install" keywords, the script is exposed
2. An accessible installer is a critical finding. In the worst case, an attacker could trigger a reinstallation — resetting the database connection, creating a new admin account, and taking over the site entirely
3. Most hosting environments protect this automatically, but custom server configurations, Docker setups, or Nginx without proper rules often leave it exposed

Scoring: if the installer page is accessible and looks like the WordPress installation wizard, the score drops to 30/100. A 403/404 response scores 100. A redirect scores 95.

Test #44: Is directory listing enabled?

Directory listing (autoindex) lets anyone browse the contents of a folder through the web browser. Test #44 checks 5 critical WordPress directories:

1. /wp-content/ — the main content directory. Listing it reveals all installed plugins, themes, and upload folders in one glance
2. /wp-includes/ — WordPress core files. Listing confirms the installation structure and version
3. /wp-content/uploads/ — user-uploaded files. May contain sensitive documents, invoices, or backup files that were never meant to be public
4. /wp-content/plugins/ — every installed plugin is visible with its exact directory name, making it trivial to search for known vulnerabilities in each one
5. /wp-content/themes/ — all themes visible, including inactive ones that may have unpatched security flaws

The test requests each directory and looks for autoindex markers in the response: "Index of /", "Directory listing for", "Parent Directory" links. If the server returns an HTML page listing files instead of a 403, the directory is exposed.

Scoring: 3 or more directories exposed = 20/100. Two exposed = 35. One exposed = 50. All blocked (403/404) = 100. The uploads directory gets extra weight because it may contain user data.

Common fixes — all under 5 minutes

Every single one of these exposures can be fixed with simple configuration changes. No code, no plugins, no downtime:

1. Remove the generator meta tag — add remove_action('wp_head', 'wp_generator') to your theme's functions.php. One line, instant effect
2. Strip version query strings — add a filter to remove ?ver= parameters from enqueued scripts and styles. Or use a security plugin that does it automatically
3. Block readme.html and license.txt — add a deny rule in .htaccess: <Files "readme.html"> Require all denied </Files>. Or simply delete the files (they'll come back on updates, so .htaccess is better)
4. Block install.php for non-authenticated users — most managed hosts handle this, but if yours doesn't, add an .htaccess rule in wp-admin/ that restricts access to install.php
5. Disable directory listing — add Options -Indexes to your root .htaccess. This single line blocks autoindex for the entire site. It should already be there on most WordPress installations, but many custom configs miss it

The pattern is consistent: these are all default-configuration issues. WordPress ships in a permissive state for ease of installation. Hardening is a separate step that most owners never take.

Why these findings sell maintenance contracts

For freelancers and agencies, these 4 tests are powerful conversation starters. They're easy to demonstrate, visually obvious, and the client doesn't need to understand code:

In the Orilyt report, each test generates an FIA recommendation:

1. Fact: "WordPress version 6.4.1 is visible in the HTML source" or "5 directories are openly browsable"
2. Impact: "Attackers can search known exploits for this exact version" or "All installed plugins are visible, enabling targeted vulnerability scanning"
3. Action: "Remove the generator meta tag and strip version query strings" or "Add Options -Indexes to .htaccess"

These findings create urgency because they're tangible. You can open the client's browser, type /readme.html, and show them the WordPress version on screen. You can browse /wp-content/plugins/ and list every plugin they run. It's not abstract — it's a live demonstration of exposure.

The 4 files hackers check first — tested in seconds

WordPress exposure isn't about sophisticated attacks. It's about low-hanging fruit. Version numbers, default files, accessible installers, directory listings — these are the first things any scanner or attacker checks. And they're all fixable in minutes.

Tests #41 to #44 cover this entire surface. They detect every common information leak, score the severity, and generate clear recommendations. Run them before an attacker does.

For client-facing audits, WordPress exposure findings are the perfect entry point. They're visual, they're urgent, and the fixes are fast. If a site fails these 4 tests, there's a security conversation to have — and likely a contract to sign.