Finding a vulnerable plugin version makes it a plausible entry point, but it does not prove that every malicious change came through that plugin. Attackers may create administrators, scheduled tasks and files outside the plugin directory after initial access.
Preserve version and request evidence, then rebuild the complete trust boundary.
Record the affected component
Capture plugin name, source, installed version, status and file hash/listing before updating or deleting it. Record the first known malicious activity and last known good time.
Do not run the vulnerable plugin on a public staging site to reproduce exploitation. Preserve a copy under restricted access without executing it.
Check whether the plugin is active, network-active or merely present.
Verify the vulnerability applies
Read the vendor advisory or trusted vulnerability notice for affected versions, required authentication and impact. Compare it with the installed version and site configuration.
A vulnerability requiring an administrator is less likely to explain anonymous exploitation unless a privileged account was already stolen. A public exploit date after the incident may still not prove causation.
Document evidence and confidence separately.
Correlate access logs
Search web logs for requests to the plugin’s routes, AJAX actions, REST endpoints or uploaded files around initial activity. Preserve method, path, status and timestamp without copying personal request bodies.
Correlate suspicious requests with file changes, user creation and outbound network/mail events. IP alone is not attribution.
Log absence may limit confidence; state that rather than inventing certainty.
Contain the vulnerable path
Disable/remove the plugin from public execution or block the exact exposed route at a trusted layer. If the plugin supports a critical checkout or membership function, provide a safe maintenance/fallback process.
Do not only update in place and assume the attacker disappears. An update closes one path but leaves existing persistence.
Check sibling sites with the same component and credentials.
Inspect post-entry persistence
Review administrators, application passwords, must-use plugins, scheduled tasks, wp-config.php, root bootstrap, uploads/cache PHP and database options/widgets.
Check hosting users, SFTP/SSH keys, email/DNS and cron if the plugin could execute arbitrary code. Rotate exposed database and application secrets from a clean device.
Preserve unknown IDs and files before removal.
Replace code from trusted sources
Install clean WordPress core, plugin and theme packages into a new root or replace untrusted components after snapshots. Validate custom code and uploads separately.
If the plugin is abandoned, remove it and migrate its required functionality to a maintained alternative. Do not download a "fixed" copy from an unofficial archive.
Import only assessed database/content into recovery.
Check uploads and data created by the plugin
Plugins that accept files, forms or imports may leave data outside their own directory. Inventory their upload folders, custom database tables, scheduled jobs and temporary files.
Do not delete those locations with the plugin until business records and evidence are assessed. Rebuild required data into the maintained replacement and block direct execution in upload storage.
Review API/webhook credentials stored by the plugin and rotate them if code execution could read configuration.
Address data and business impact
Determine what the vulnerability allowed and what the logs show was accessed or changed. Escalate possible customer/order exposure through the organisation’s incident process.
Reconcile WooCommerce orders, form entries and mail sent during the incident window. Avoid claiming no data access solely because no visible export exists.
Keep remediation and notification decisions with authorised owners.
Verify closure and monitor
Test the replacement functionality, login, forms, checkout, cron and mail. Confirm no unknown accounts/tasks, no vulnerable package on sibling sites and no recurrence of indicators.
Monitor file changes, privileged actions and requests to the former endpoint. Document the likely entry point with evidence and uncertainty.
Request urgent rescue when the plugin allowed code execution or the exploit window is unclear. Share advisory/version and redacted logs—never credentials, customer data or exploit payloads.