How to diagnose a compromised WordPress site after unauthorized admin accounts appear

Unauthorized WordPress administrator accounts are a strong sign that a site may have been compromised, but they do not automatically prove that malware is being served to visitors. In this case, the investigation traced the intrusion to a known vulnerability in Divi Form Builder, identified six unauthorized administrator accounts and an unauthorized installation of Filester, and confirmed through file, database, and frontend scans that no malware, payment skimmers, spam content, or malicious scripts were present. The priority was to close the vulnerable plugin path, remove unauthorized access, and improve ongoing monitoring.

Issue background

A WordPress site reported suspicious administrator accounts shortly before a high-traffic business event. The site owner had already deleted several unfamiliar users and asked for an urgent investigation.

The primary questions were:

• When were the unauthorized accounts created?
• How did the attacker gain access?
• Was the site serving dangerous content?
• Would Wordfence improve the site’s security?
• Why had Jetpack not prevented the incident?
• Was the attack targeted or part of a broader campaign?

The site also contained an unexpected Filester installation. Activity logs showed that the plugin had been added by one of the unauthorized administrator accounts rather than by the legitimate site team.

Diagnosis

The investigation reviewed WordPress users, activity records, plugin versions, site files, the database, and public-facing pages.

Six unauthorized administrator accounts had been created across three separate dates over roughly two weeks. The account names followed a repeated pattern associated with automated exploitation rather than a manually targeted attack.

The entry point was traced to an outdated version of Divi Form Builder. Versions through 5.1.2 were affected by a known vulnerability involving the plugin’s registration functionality. Automated scanners were actively searching for websites running vulnerable versions.

The attacker used that flaw to create administrator accounts without going through the normal WordPress login process. This distinction explains why conventional brute-force protection would not necessarily have stopped the initial intrusion.

The investigation also clarified the role of common security tools:

• Wordfence adds firewall rules, brute-force protection, malware scanning, and monitoring, but it cannot guarantee prevention before a new third-party vulnerability is known and covered.
• Jetpack may provide security-related features depending on the plan and configuration, but it is not a universal web application firewall for every plugin vulnerability.
• Saving a page in Divi does not remove hidden malware from theme files, plugins, uploads, or the database.

Comprehensive scans found no evidence that the site was serving harmful content. Specifically, the review found no:

• Malware in the site files
• Malicious database scripts
• Payment-card skimmers
• Injected spam pages
• Malicious frontend JavaScript

The site content appeared clean, but the vulnerable plugin remained an open door until it was updated or removed.

Resolution steps

1. Preserve evidence before making broad changes. Export activity logs, user records, plugin lists, and relevant server logs so the intrusion timeline can be reconstructed.
2. Review all administrator accounts. Remove unauthorized users and confirm the identity and purpose of every remaining privileged account.
3. Record account creation times. Compare WordPress user timestamps with plugin, server, and security logs to identify the likely attack window.
4. Audit recently installed plugins. Investigate any plugin that the legitimate team did not install, including file-manager tools such as Filester.
5. Check vulnerable plugin versions. Compare installed versions of Divi Form Builder and other plugins against current security advisories.
6. Update or remove the vulnerable plugin. Close the known entry point before treating the site as secure.
7. Rotate privileged credentials. Reset administrator passwords, hosting credentials, SFTP or SSH passwords, database credentials, and API keys when exposure is possible.
8. Review active sessions. Force logout for administrator accounts and invalidate sessions created before the cleanup.
9. Scan the entire filesystem. Review WordPress core, plugins, themes, must-use plugins, uploads, and unexpected PHP files.
10. Scan the database. Check options, posts, widgets, users, scheduled tasks, and plugin settings for injected scripts or unauthorized changes.
11. Inspect public pages manually. Test representative pages for redirects, spam, unfamiliar scripts, payment skimmers, and altered forms.
12. Verify WordPress core integrity. Compare core files with official checksums and replace modified core files when necessary.
13. Install or configure Wordfence. Enable firewall protection, malware scanning, login safeguards, and alerts appropriate to the site.
14. Do not rely on one security plugin. Combine updates, least-privilege accounts, backups, server logging, firewall protection, and ongoing monitoring.
15. Review registration features. Disable public registration workflows that are not needed and test any plugin that can create users.
16. Monitor for recurrence. Watch for new administrators, unexpected plugin installations, file changes, failed logins, and suspicious requests.
17. Document the incident. Record the timeline, entry point, affected accounts, evidence reviewed, cleanup actions, and follow-up requirements.

Deleting suspicious users is necessary, but it is not enough. If the vulnerable code remains active, automated attackers can simply recreate the accounts.

Final outcome

The investigation confirmed that the site had been compromised through a known Divi Form Builder vulnerability. Six unauthorized administrator accounts were identified and deleted, and the unexpected Filester installation was linked to unauthorized activity.

File, database, and public-page scans found no malware, malicious scripts, payment skimmers, or spam content. The site was not found to be serving dangerous content to visitors at the time of the review.

The incident appeared to be part of a broader automated campaign targeting vulnerable Divi Form Builder installations rather than a site-specific attack.

The documented remediation priority was to update or remove the vulnerable plugin, strengthen monitoring with Wordfence, review privileged access, and maintain a regular patching process.

The key lesson is that a clean malware scan does not mean an intrusion should be ignored. Unauthorized administrator creation proves that access controls were bypassed, and the vulnerable entry point must be closed even when no malicious payload is found.

For help investigating unauthorized WordPress users, responding to plugin vulnerabilities, or hardening a compromised site, contact Freshy.