How to Know if wp-config.php Is Infected in WordPress

When WordPress site owners hear “malware,” they usually think about plugins, uploads, or random PHP files.

But one of the more serious places to find malicious code is wp-config.php.

That matters because wp-config.php sits close to the core boot process and often survives the obvious cleanup steps people try first.

Why wp-config.php matters so much

If malicious code lands in wp-config.php, it is no longer living in a disposable plugin folder.

It is sitting in one of the most trusted and consistently loaded files on the site.

That makes it useful for attackers who want:

  • persistence after a plugin is updated or removed
  • code execution on every request
  • hidden redirects or spam logic
  • a place administrators are less likely to inspect casually

In other words, config compromise usually means the incident went deeper than “we had a vulnerable plugin.”

Signs wp-config.php may have been tampered with

Common warning signs include:

  • unexpected code blocks that are not part of your normal setup
  • obfuscated PHP, strange includes, or suspicious remote calls
  • unfamiliar comments, variable names, or long encoded strings
  • file changes that line up with a known plugin compromise or malware warning
  • a site that still behaves strangely after the original plugin was patched or removed

The exact payload varies.

The important question is whether the file contains anything that does not belong to your environment.

Why people miss it

Because teams often focus on the visible source of the incident.

If the story starts with a plugin compromise, they inspect the plugin.

If the plugin is updated, they relax.

But recent WordPress incidents showed why that is not enough.

A malicious update or backdoor can write persistence outside the plugin itself, and wp-config.php is one of the places that deserves attention.

What a config compromise often means

If wp-config.php has malicious changes, assume the site may also need checks for:

  • hidden admin users
  • mu-plugins persistence
  • theme-file modifications
  • suspicious options or cron jobs
  • redirects or cloaked SEO spam

Config compromise is usually a sign of a wider incident, not an isolated file-edit problem.

Do not compare only against memory

A common mistake is opening the file and saying, “this looks roughly right.”

That is not enough.

Good review means comparing against:

  • a known-clean version
  • the actual needs of the hosting environment
  • the recent incident timeline

Many compromised files are dangerous precisely because they look close enough to normal configuration that a rushed review misses them.

Deleting suspicious code is not the whole job

Even if you identify malicious code in wp-config.php, that does not automatically mean the incident is solved.

You still need to ask:

  • what wrote it there?
  • can that access path still execute?
  • did the attacker create users, files, redirects, or other persistence elsewhere?

That is why config-level malware sits closer to incident response than simple file cleanup.

For the practical workflow around that, the WordPress incident response process page explains how I validate persistence instead of stopping at the first suspicious file edit.

When to take this especially seriously

Escalate the situation if wp-config.php changes appear alongside:

  • unknown admin users
  • recent malicious plugin update history
  • redirect behaviour
  • hidden spam pages in Google
  • malware that returned after someone already cleaned the site once

That combination usually points to persistence rather than a one-off anomaly.

If you need help

If you suspect wp-config.php was modified during a WordPress incident, the most relevant next pages are:

Because once malware reaches configuration level, the useful question is not “can we edit this one file?”

It is “how far did the compromise spread, and what still has the ability to come back?”