A vulnerable plugin and a stolen administrator password can exist at the same time. Blaming the plugin solely because it is outdated can leave credential theft unresolved; blaming credentials without checking public endpoints can leave anonymous access open.
Build two evidence timelines and test which one explains the first privileged action.
Preserve both evidence sets
Record plugin/theme versions and source, WordPress users/roles, application passwords, sessions, login events and relevant web requests. Snapshot files/database and logs before updates or password resets where safe.
Do not export password hashes or full request bodies into a ticket. Use IDs, timestamps and paths.
Separate first observed compromise from later attacker activity.
Look for authenticated activity
Review successful logins, password-reset events, session creation and administrator actions before malicious changes. Check whether the user’s normal browser/device pattern changed, while recognising VPNs and shared IPs.
An attacker using a stolen session may not produce a fresh password login. Application-password API activity can also appear under the parent user.
Correlate account evidence with the exact action.
Look for public endpoint activity
Search logs for requests to the suspected plugin route, AJAX action, REST endpoint or upload handler. Compare installed version and configuration with the vendor advisory.
Determine required authentication and impact. A vulnerability that only changes low-privilege content may not explain server-wide file writes without another step.
Do not replay exploit payloads against production.
Consider post-compromise camouflage
After gaining access through one route, attackers can log in normally, upload a plugin or create a second account. Later evidence may resemble the other vector.
Focus on the earliest high-confidence event and what permissions it supplied. Document alternate explanations.
Lack of old logs should lower confidence, not increase certainty.
Build an attack-chain timeline
Place each event in order: first suspicious request/login, privilege change, file upload, cron creation, outbound spam and public symptom. Note the capability needed for every step.
If the first observed action required administrator privilege, credential/session compromise is necessary unless an earlier vulnerability supplied that role. If an anonymous endpoint wrote executable code before any login, the plugin hypothesis strengthens.
Keep missing log periods visible rather than filling them with assumptions.
Secure credentials regardless
Rotate owner email, WordPress, hosting, database and application credentials appropriate to exposure. Revoke sessions, application passwords and unknown accounts from a clean device.
Enable MFA and unique per-user access. Check password reuse across email, cPanel/Plesk and sibling sites.
Do not email replacement secrets or store them in the theme.
Close vulnerable code regardless
Update or remove the affected plugin from a trusted source, including inactive copies and sibling installations. Replace untrusted core/plugins/themes and validate custom code.
If the plugin is abandoned, migrate its functionality. An account rotation does not patch anonymous exploitation.
Keep the route contained until clean-build verification.
Review likely credential-theft routes
Check phishing reports, malware on the administrator’s device under the organisation’s process, browser extensions, leaked password repositories, shared accounts and exposed backup/config files.
Do not conduct invasive personal-device analysis without authorisation. Secure recovery channels and provider sessions.
Record evidence rather than attributing intent to a user.
Check other sites and services
Search for the same username/password exposure, plugin version and indicators on sibling sites. Review primary email and hosting access because either can reset WordPress or deploy code.
Do not reuse replacement passwords or assume an MFA-protected WordPress account secures cPanel. Separate every control plane and rotate according to demonstrated exposure.
Report confidence, not a story
State facts, gaps, most likely vector and alternatives. For example: "A successful administrator session preceded file upload; plugin version was vulnerable but no relevant request logs remain."
Use the conclusion to improve controls: patch cadence, MFA, individual accounts, log retention and alerts.
Request emergency assessment when entry-vector uncertainty affects several sites. Share redacted timelines and versions—never passwords, hashes, exploit data or customer information.