Four WordPress URLs That Should Never Be Publicly Reachable. wp-login, readme, license, install

Four URLs ship with every WordPress installation. Three leak information attackers use to target you. The fourth can take over your site if left in the wrong state. The WordPress Security + Stability Audit probes all four.

1. wp-login.php reachable at the default path

The login page. Ships at /wp-login.php by default. This is not a bug. Users need to log in. But the default path is also where every WordPress brute-force bot on the internet starts, and every hit logs against your PHP worker pool.

Fix: install WPS Hide Login, iThemes Security's "Hide Backend," or Perfmatters' hide-login feature. These rename the login URL to something of your choice. Security through obscurity, yes. Also a traffic reduction of about 80 to 95 percent on a previously-unprotected site, according to WPS Hide Login's own telemetry.

Pair with a login-attempt-limit plugin (Wordfence, Loginizer, Limit Login Attempts Reloaded) so the bots that do find the new URL get rate-limited. One-two combo.

Risk: if you forget the new URL you'll lock yourself out. Write the new URL in a password manager before you ship the change.

2. /readme.html publicly reachable

Every WordPress install ships readme.html at the root. The file lists the exact core version. Attackers use this to match your install against the CVE database for that version.

Fix: delete the file after every core upgrade. Or deny with an .htaccess rule:

<Files readme.html>
  Require all denied
</Files>

Better fix: automate it. A one-line mu-plugin:

<?php
add_action('admin_init', function(){
  $r = ABSPATH.'readme.html';
  if (file_exists($r)) @unlink($r);
});

That runs on every admin page load, so the file gets re-deleted if a core upgrade puts it back.

3. /license.txt publicly reachable

Same category as readme. Ships with every install. Doesn't expose an exact version number, but it does confirm "this is a WordPress site" which is another recon signal.

Fix: the same .htaccess block pattern, plus license.txt:

<Files ~ "^(readme\.html|license\.txt|wp-config\.php\.bak|debug\.log)$">
  Require all denied
</Files>

Or add license.txt to the mu-plugin above.

4. /wp-admin/install.php showing an installer form

This is the one that matters. Normally after WordPress is installed, install.php returns a "WordPress is already installed" message. Some server configurations, some migration states, and some shared-host setups can leave install.php in its un-executed state, where it shows the initial setup form.

If install.php shows a setup form on a live public site, any visitor can complete the install with admin credentials of their choosing. That's a full takeover in one click.

Fix: the audit flags this as a critical fail when it detects the form. Remediation sequence:

1. Log into your existing admin (or rescue via database access).
2. Confirm the site is actually installed and working for you.
3. Deny install.php via .htaccess:

<Files install.php>
  Require all denied
</Files>

4. Rotate all WordPress salts (AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY, AUTH_SALT, SECURE_AUTH_SALT, LOGGED_IN_SALT, NONCE_SALT in wp-config.php). Generate new values at https://api.wordpress.org/secret-key/1.1/salt/
5. Force all users to log in again.
6. Audit recent posts, pages, users, and scheduled tasks for any unauthorized additions during the window install.php was exposed.

If the site has been publicly serving install.php for any length of time, treat it as a potential breach and do the full audit above regardless of whether you see evidence of tampering.

Why this set of four matters together

Each one is small on its own. The set of four is your "WordPress-shaped site with known fingerprint" signal. Scanners look for this exact pattern because it tells them you probably haven't hardened anything else either. Clean up all four in one push and you drop below the bot threshold for basic drive-by scans.

Related reading

• WordPress Security + Stability Audit, the tool that finds all four
• Additional WordPress Audits, the eight deeper-layer checks
• WordPress + WooCommerce Audit, performance and plugin footprint

Fact-check notes and sources

• WPS Hide Login plugin telemetry for the 80 to 95 percent bot traffic reduction claim.
• WordPress Developer Handbook on WordPress salts and wp-config.php security.
• Apache .htaccess documentation for the Require all denied directive.
• WordPress Codex on install.php behavior and remediation of exposed installer states.

This post is informational, not security-consulting or legal advice. If you suspect your site has been breached, stop reading blog posts and call a WordPress-specialist incident-response firm. Do not destroy evidence before the professionals see it.