WordPress configuration file served

The database host, name, user and password, which together are direct access to every piece of content and every account record.

The authentication salts, which are what session cookies are signed with — knowing them allows a valid session cookie to be constructed.

The table prefix, which removes the only obstacle to a prepared query against the database.

Frequently additional credentials added over time: a mail service, a payment gateway, an object storage account.

Debug settings, which reveal whether the installation is currently writing a log and where.

An editor writing a backup alongside the original with a tilde or a backup suffix, which the web server serves as text.

A manual copy made before a change — the same filename with a dated or numbered suffix.

A crash-recovery file from a terminal editor, left in the directory after a session ended badly.

A file renamed to disable it during debugging and never renamed back.

A full-site archive written into the web root by a backup plugin, which contains the configuration file among everything else.

With debug logging enabled to a file, WordPress writes that file inside the content directory, which is served.

It accumulates whatever the application wrote while something was going wrong, including query fragments and occasionally credentials.

It grows indefinitely, so a log enabled once during an investigation is still collecting years later.

Its path is conventional, which means it does not need to be discovered — it needs only to be requested.

Logging to a location outside the web root, or to the error log rather than a file, removes the exposure.

Remove the file from the web root immediately. This stops further exposure and does nothing about what has already been taken.

Rotate the database password. The credential has been publicly readable for an unknown period.

Regenerate the authentication salts, which invalidates every existing session and forces everyone to sign in again — that is the intended effect.

Rotate every other credential the file contained, including third-party service keys.

Review the access log for requests to the path, which tells you whether anything actually fetched it and from where.

Block requests for the configuration filename pattern at the server level, including suffixed variants, so a future copy is refused rather than served.

Move the configuration file one directory above the web root, which WordPress supports and which makes the whole class impossible.

Write backups somewhere that is not served, which is a backup plugin setting on every one of them.

Set debug logging to the server error log rather than to a file inside the content directory.

Disable directory listings, so a directory containing such a file does not advertise it.

Request the configuration filename directly and confirm the response is empty or refused rather than text.

Try the common suffixed variants — backup, old, dated, and the editor artefacts — and confirm each is refused.

Request the conventional debug log path and confirm it does not answer.

List the site directory over a file protocol if you have server access, which shows what is actually there rather than what answers.

Do the same for any staging copy, which frequently has looser configuration and the same credentials.

`wordpress.config_exposure` is a defensive check for accidentally served configuration, backup or debug files. Contents are never stored or displayed — only the fact that the path answered.

`wordpress.detected` establishes the platform first, from signals the profile detector already collected.

`exposure.secrets.private` reports credentials found in served files generally, which is the same class through a different route.

`exposure.assets.coverage` states how much of the public surface was inspected.

Only a fixed set of conventional paths is requested: nothing is enumerated and no filename is generated.