In June 2026 I carried out the forensic analysis of a real intrusion on a client’s WordPress site. Not a lab walkthrough, not a Vulnhub box: a production site, compromised through a third-party plugin — Side Cart for WooCommerce. In this article I walk through the method I followed: what to look at, in what order, and what I learned about dependency management in WordPress.
Why WooCommerce plugins are a recurring target
WordPress core, on its own, has a fairly contained attack surface and a reasonably mature patching process. The problem is the plugin ecosystem: thousands of third-party developers, wildly variable code quality, and an update mechanism that still requires human intervention (or a well-configured cron) to actually be effective.
E-commerce plugins are particularly attractive targets because they often handle functionality with a large surface: uploads, cart management, payment integrations, poorly tested AJAX endpoints. Finding an AJAX endpoint registered with shaky permissions is more common than you’d like it to be.
Step 1: timeline before anything else
The first mistake you risk making when facing an intrusion is diving straight into modified files without first fixing a reference time window. The first thing I always do is cross-reference three sources:
- Web server logs (access log and error log), filtered for suspicious patterns on the compromised plugin’s endpoints.
- File modification timestamps on the filesystem.
- WordPress application logs and the post/page revision history.
Cross-referencing these three sources lets you build a defensible timeline: not “something happened at some point,” but an ordered sequence of events to build the rest of the analysis on.
Step 2: identifying the entry vector
Once the time window is set, the next step is isolating the vector. In this specific case, access log analysis showed anomalous requests to the plugin’s AJAX endpoints, with payloads consistent with unauthenticated file upload attempts. A classic pattern: a registered AJAX endpoint, reachable even by unauthenticated users.
An important methodological point: at this stage there’s no need (and often no benefit) to fully reverse-engineer the plugin’s code to pin down the exact CVE. What matters more is quickly confirming whether that endpoint was actually exploited, by looking at the server’s response and the side effects: new files, new users, changes to critical options.
Step 3: looking for persistence
Once the vector is found, the next question is: did the attacker leave a way back in? The areas I systematically check:
- WordPress users created or promoted to administrator within suspicious time windows.
- New or modified PHP files outside the expected plugin/theme directories — especially in
wp-content/uploads, where PHP execution should be blocked at the webserver level (and often isn’t). - Changes to
wp-config.php,.htaccess, or WordPress core files. - WordPress cron jobs registered to run code at intervals — an elegant persistence mechanism because it survives the removal of the original malicious file.
Practical lessons (transferable to any WordPress site)
- Disable PHP execution in
wp-content/uploadsat the webserver level, regardless of what the plugin does. It’s a defensive mitigation independent of the specific vulnerability. - E-commerce plugins should be treated as high-risk surface: automatic updates where possible, or at minimum active monitoring of security advisories specific to that plugin.
- Logs should be kept longer than seems necessary. More than one forensic analysis fails not for lack of skill, but because the relevant logs have already been rotated and deleted.
- Verified backups, not just configured ones. A backup that’s never been tested with a restore is a backup that doesn’t exist.
Conclusions
Forensic analysis on a real site is different from a lab walkthrough: there’s no flag to capture, there’s a client who wants to know what happened, since when, and whether they’re still at risk. The method, though, is the same — timeline first, entry vector, systematic search for persistence — with the added pressure of having to be accurate, not just fast.
Stay safe!