Quick answer
wp-config.php malware is dangerous because the file loads early in WordPress and contains sensitive configuration. Suspicious changes include unfamiliar includes, encoded code, remote loaders, changed database credentials, debug exposure, or strange constants. Back up the file, compare with a known clean copy, remove malicious additions, and rotate credentials if secrets may be exposed.
The wp-config.php file is one of the most important files in a WordPress installation. It connects the site to the database and can define security-related constants.
Because it loads before themes and plugins, attackers may modify wp-config.php to run code early, hide loaders, or change how the site behaves.
Why this matters
A malicious line in wp-config.php can affect the entire site and may survive theme or plugin changes.
The file also contains database credentials, so compromise may require credential rotation, not only code cleanup.
Warning signs to look for
- wp-config.php has unfamiliar include or require lines.
- Encoded code appears before or after normal settings.
- Database credentials changed unexpectedly.
- Debug output exposes sensitive paths.
- The file modification date matches the infection timeline.
Small additions at the top or bottom of wp-config.php are easy to miss. Review the whole file, not only the database section.
Where this usually hides
Malware may use include statements to load another file, remote request code, encoded payloads, or constants that change execution behavior.
Attackers may also add comments or spacing to make malicious code look like normal configuration.
Safe investigation steps
Back up wp-config.php and compare it with a known clean version for that site. Confirm legitimate custom settings before removing anything.
If database credentials were exposed or changed, plan credential rotation carefully so the site does not lose connection.
- Inspect top and bottom of wp-config.php.
- Look for includes, eval-like patterns, and remote requests.
- Confirm database credentials and salts.
- Review file permissions.
- Check for related backdoors.
Cleanup priorities
Remove malicious code and restore legitimate configuration. Replace authentication salts if compromise is suspected, and rotate database credentials when appropriate.
Then scan other early-loading locations such as mu-plugins, index.php, and .htaccess.
- Back up wp-config.php.
- Compare against known clean settings.
- Remove malicious loaders or code.
- Rotate exposed credentials.
- Verify the site and admin area still load.
What to avoid
Do not replace wp-config.php with a generic file unless you know all required settings. You can break database access.
Do not publish debug output publicly while troubleshooting. It can expose paths and sensitive details.
Prevention after cleanup
Restrict file write permissions, protect hosting access, and monitor critical files for changes.
Keep a secure copy of known-good configuration so future comparisons are easier.
Helpful resources
Related help includes hidden backdoor removal, WordPress security audit, and security hardening.
WordPress.org’s hardening documentation includes configuration and access practices that support safer wp-config.php handling.
When to get expert help
Get help if wp-config.php includes unfamiliar code, database access is unstable, or credentials may have been exposed.
How to confirm the cleanup worked
For wp-config.php malware, verification should match the original symptom. A single admin-side check is not enough. Test the affected URL as a logged-out visitor, from a private browser window, and from the device type involved in the report. If the issue affected search traffic, inspect the exact search-facing URL and compare the rendered source with the dashboard content.
Clear WordPress cache, server cache, CDN cache, and browser cache before making the final call. Old cached output can make a clean site look infected, while logged-in testing can make an infected site look clean. Verification should include files, database, users, redirects, and the public page output.
What evidence to save
Keep a short incident note for this case. Include the first report date, affected URLs, screenshots, warning messages, suspicious files, changed users, plugins involved, and the cleanup actions taken. That record helps if the issue returns or if hosting, Google, an ad platform, or a client asks what was fixed.
Evidence is also useful for learning the entry point. If you know which file changed first, which admin account was used, or which plugin path appeared in logs, future prevention becomes much more targeted than simply installing another security plugin.
SEO and trust impact
Security incidents affect more than code. Visitors who see warnings, redirects, broken pages, or suspicious prompts may lose trust quickly. Search engines and ad platforms may also need time to recrawl and re-evaluate the site after cleanup.
After the technical fix, check important landing pages, internal links, metadata, forms, and conversion paths. A page can be technically clean but still lose value if the user experience remains broken or if search snippets still show old compromised text.
Questions before closing the ticket
- What was the most likely entry point?
- Was any admin, hosting, SFTP, database, or API credential exposed?
- Were files, database records, users, redirects, and cache all reviewed?
- Was the vulnerable plugin, theme, setting, or password fixed?
- Is monitoring active so recurrence is caught quickly?
If any answer is unknown, mark the incident as cleaned and monitoring rather than fully closed. That small caution can prevent the same issue from returning unnoticed.
How to confirm the cleanup worked
For wp-config.php malware, verification should match the original symptom. A single admin-side check is not enough. Test the affected URL as a logged-out visitor, from a private browser window, and from the device type involved in the report. If the issue affected search traffic, inspect the exact search-facing URL and compare the rendered source with the dashboard content.
Clear WordPress cache, server cache, CDN cache, and browser cache before making the final call. Old cached output can make a clean site look infected, while logged-in testing can make an infected site look clean. Verification should include files, database, users, redirects, and the public page output.
What evidence to save
Keep a short incident note for this case. Include the first report date, affected URLs, screenshots, warning messages, suspicious files, changed users, plugins involved, and the cleanup actions taken. That record helps if the issue returns or if hosting, Google, an ad platform, or a client asks what was fixed.
Evidence is also useful for learning the entry point. If you know which file changed first, which admin account was used, or which plugin path appeared in logs, future prevention becomes much more targeted than simply installing another security plugin.
SEO and trust impact
Security incidents affect more than code. Visitors who see warnings, redirects, broken pages, or suspicious prompts may lose trust quickly. Search engines and ad platforms may also need time to recrawl and re-evaluate the site after cleanup.
After the technical fix, check important landing pages, internal links, metadata, forms, and conversion paths. A page can be technically clean but still lose value if the user experience remains broken or if search snippets still show old compromised text.
Questions before closing the ticket
- What was the most likely entry point?
- Was any admin, hosting, SFTP, database, or API credential exposed?
- Were files, database records, users, redirects, and cache all reviewed?
- Was the vulnerable plugin, theme, setting, or password fixed?
- Is monitoring active so recurrence is caught quickly?
If any answer is unknown, mark the incident as cleaned and monitoring rather than fully closed. That small caution can prevent the same issue from returning unnoticed.
FAQ
Can wp-config.php contain malware?
Yes. It is a common target because it loads early and affects the whole site.
Should I rotate database credentials?
If compromise is likely or credentials were exposed, rotation is recommended with careful planning.
Can wrong edits break WordPress?
Yes. Always back up before editing wp-config.php.
Are authentication salts important?
Yes. Replacing salts logs out sessions and can help after credential compromise.