Recommended Free Tools
If you suspect a WordPress site was compromised through a file inclusion flaw, preserve a snapshot and evidence first, then investigate, contain, clean, close the entry path, and verify recovery. A vulnerability alone does not prove anyone exploited it. WordPress.org’s advice for a stressful incident is simple: “Stay calm.”
First, distinguish a vulnerability from a confirmed compromise
A file inclusion flaw occurs when vulnerable code handles a supplied file path or URL without adequate validation. Local file inclusion can cause the server to include a file already on that server; remote file inclusion involves a file from a remote source. Depending on the flaw and conditions, consequences can include disclosure of sensitive information, server-side or client-side code execution, or denial of service. These are possible impacts, not proof that an attacker succeeded. See OWASP’s file-inclusion testing guidance.
Base your response on observable symptoms and available records, not on the existence of a vulnerable component alone. WordPress.org recommends describing concrete indicators rather than relying on the ambiguous word “hacked.”
Record what happened and contact your host
Before changing files or settings, write down what prompted the concern, when it first appeared (including timezone), recent site changes, and relevant hosting details. Preserve alert messages and note who observed each symptom. Examples WordPress.org identifies as possible indicators include:
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallOutdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware match- A search engine blacklist or malware warning.
- The host disabling the site or reporting suspicious activity.
- Reports that the site is attacking other sites.
- Unexpected WordPress user accounts or visibly altered pages.
Ask the host to help determine whether the symptoms point to a compromise, a service outage, or another hosting issue. If server or access logs are available, preserve them and ask the host what records can help establish timing and requests.
Preserve a snapshot and contain active risk
Create a backup or hosting snapshot before removing files, reinstalling WordPress, or making other cleanup changes. Keep an untouched copy if possible. WordPress.org recommends taking another snapshot before cleanup, even if the site appears infected; it can provide a recovery reference or evidence if remediation does not go as planned.
If the site appears to be harming visitors or other systems, or the vulnerable route is still exposed, coordinate with your host or a qualified responder about limiting access while preserving evidence and any required service. Avoid wiping the installation as a first move: it can destroy useful evidence and content. Isolation is a general incident-response principle; the cited CISA guidance concerns Log4j, not a WordPress-specific procedure.
Investigate the whole installation, not just the first suspicious file
Use more than one evidence source where feasible. WordPress.org describes remote scanners and application-level scanners as complementary: the former inspect the site remotely, while the latter inspect from within the WordPress installation. Neither alone establishes the cause or proves remediation is complete. File comparisons and host logs may add different evidence, depending on the access your host provides.
Check WordPress core and changed files
Compare core files with the official repository versions for the WordPress version the site is running. Replacing /wp-admin and /wp-includes can be part of cleanup, but it is not a complete investigation. A dashboard reinstall may overwrite core files while leaving newly added malicious files behind.
Review wp-content, including themes, plugins, uploads, and other files, along with configuration and other changed files. Pay particular attention to unexplained changes in .htaccess, index.php, header.php, footer.php, and function.php. Do not delete wp-config.php simply because it looks suspicious: preserve a copy, identify the changes, and repair configuration and credentials deliberately.
Find and fix the vulnerable route
Identify the affected plugin, theme, custom code, or other component and determine how the attacker could have reached it. Check the component vendor’s fix and test the site’s behavior; update or disable/remove the affected component if needed. Fixing or removing the flaw matters because cleaning visible malware without closing the entry path can leave the same route available again. Do not test with exploit payloads on a live site.
Clean the site, then close access
Once you have preserved evidence and identified affected files, remove malicious changes and restore trustworthy copies of files where appropriate. Update WordPress and affected themes and plugins. WordPress.org advises changing passwords again after cleanup; consider changing the database account password as well, and update the site’s configuration to match if it changes.
Renew WordPress secret keys in the configuration to invalidate existing authenticated sessions. Also review who has administrator access and remove accounts you can establish are unauthorized. The point is to remove persistence and close access, not merely to make the visible symptom disappear.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Verify recovery and monitor for returning indicators
Check core and affected component integrity after cleanup, and use multiple suitable verification methods where feasible—for example, a file comparison alongside a scanner and relevant host logs. CISA’s recommendation to verify with multiple methods and monitor comes from its separate Log4j guidance; it is general incident-response context, not a WordPress-specific rule.
Monitor for the original symptoms and new unexplained changes after restoring service. If suspicious files or activity return, treat that as a sign that the investigation or entry-path closure may be incomplete; preserve the new evidence and involve the host or a responder rather than repeatedly deleting files without finding the cause.
When to bring in an incident-response professional
WordPress.org says a site owner may handle recovery or engage a professional organization. Consider professional help if you lack file or server access, cannot identify the affected files or entry path, see repeated reinfection, or face business, customer-data, or availability risks beyond your team’s experience. These are practical decision cues, not a formal threshold set by WordPress.org.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Scan for outdated or missing drivers - takes under a minute3Clear out junk files and repair common Windows errorsQuick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
