Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Clear out junk files and repair common Windows errorsFree Scan →A WordPress infection can return after you delete suspicious files because the code or access that restores it may still exist somewhere else: in the database, a scheduled task, another file, an administrator account, a browser, or another site sharing the hosting account. Rotating passwords and security salts does not remove those persistence paths. A 2026 Monarx Security report describes one campaign using several of them at once; its specific behavior should not be treated as typical of every WordPress hack.
How can an infection return after credentials and salts are rotated?
Credential rotation blocks some kinds of access, but it does not erase malicious code or data already on the server. If a remaining file, database record, scheduled task, or compromised account can restore the malware, the site may be reinfected even after passwords and salts change. If an attacker can still reach the hosting account or another site in it, the WordPress login is not the only boundary that matters.
Persistence can live outside the file you cleaned
WordPress treats site files and the database as separate backup components: a copy of the WordPress directory does not include the database. That separation matters during cleanup, too. Removing a malicious plugin file does not establish that database-held code or settings, scheduled activity, or another copy of the payload is gone.
What the reported campaign did
In a report published August 17, 2026, Monarx Security described a particular infection that it said used multiple file copies, database options, scheduled tasks, hidden administrator behavior, and a browser service worker on administration or login pages. The report says the service worker could intercept credentials and automate plugin reinstallation. These are vendor-reported details about that campaign, not a checklist that proves every infected WordPress site has the same mechanisms.
#1 Best Overall
A separate WordPress.org forum post describes one user’s reinfection incident after cleanup and credential rotation. The user reported suspicious drop-ins and must-use plugin files, database payloads, cron events, hidden administrators, and a shared-memory segment among possible restoration sources. The user later said the host resolved an immutable-file issue and that a rebuild using fresh core files, a pre-infection database backup, and official plugins remained clean for a day. That is an individual account and a short follow-up, not independent confirmation or proof of lasting remediation. In particular, the report does not establish shared memory as a generally verified WordPress persistence mechanism. Shared memory should not be confused with shared hosting.
What to check when the backdoor keeps coming back
Treat a recurring infection as a site-and-hosting incident, not just a suspicious-file problem. Preserve evidence before cleanup, then work through the components that could restore access or code.
- Files beyond the obvious plugin: Review WordPress core paths, themes,
wp-content, drop-ins, must-use plugins,.htaccess, and other modified files. WordPress recovery guidance recommends replacing core directories with files from the appropriate official release and reviewing the remaining site files. Exposed configuration backups, old backups, vulnerable or pirated plugins, and server weaknesses are also possible causes cited by Wordfence. - Database and scheduled activity: Review relevant options, transients, user records, and scheduled tasks when the evidence points there. Monarx and the forum user describe database and cron persistence in their respective reports. Unknown option names by themselves do not prove compromise, and campaign-specific indicators should not be treated as universal signatures.
- Users, sessions, and account access: Look for unfamiliar administrator accounts and sessions, as well as access to hosting, FTP, and database accounts. A WordPress password reset alone cannot rule out a separate hosting-level entry path.
- Sibling sites and the hosting account: WordPress advises contacting the host because a hack on shared hosting may affect more than one site. Wordfence also identifies cross-infection from another site or application in a shared account as a possible route. Ask the provider to check sibling sites, account-level permissions, and server-side issues—not only the affected WordPress directory.
- Browsers used to administer the site: If the service-worker behavior described by Monarx is suspected, follow its report’s advice to unregister the site’s service worker and clear site data in every browser and device used by administrators. This is a campaign-specific precaution, not a standard explanation for every reinfection.
How to contain and recover safely
- Restrict access and preserve a snapshot. If needed, put the site behind restricted access while you investigate. Preserve an environment snapshot before cleanup and contact the hosting provider, particularly on shared hosting. A snapshot is evidence, not necessarily a clean restore point.
- Choose a backup only after establishing that it predates the compromise. WordPress recommends backing up both files and database and keeping copies in different locations. Do not restore an unreviewed snapshot as if it were clean. If you rebuild, restore files and database from known-clean materials together where appropriate.
- Replace or review the complete file set. Use official WordPress downloads for core files and inspect themes and plugins rather than assuming the deleted file was the only copy. Remove software you do not use and investigate modified files, backups, and configuration artifacts.
- Review database records and scheduled tasks. Investigate suspicious users, options, transients, and cron events in context. If you cannot confidently distinguish legitimate site data from malicious changes, ask a qualified incident responder or your host to help; indiscriminate deletion can break the site or destroy useful evidence.
- Resolve host-level problems before changing credentials again. Ask the provider to investigate undeletable or immutable files, account access, server vulnerabilities, and possible cross-infection. A problem outside WordPress can restore the infection after a site-only cleanup.
- After persistence is removed, rotate credentials and review access. WordPress recovery guidance recommends changing passwords after the site is clean, including considering the database account. Wordfence recommends resetting WordPress, hosting, FTP, and database passwords, enabling two-factor authentication, and removing unfamiliar accounts. Changing credentials before the remaining access path is closed may not stop a recurrence.
- Harden and monitor the rebuilt site. Keep core, themes, and plugins updated; remove unused software; use official sources; minimize write permissions; and isolate sites where possible. Maintain tested backups in separate locations. WordPress cautions that write access is especially risky on shared hosting. Its database-privilege guidance has operational caveats: plugins and major updates may require schema privileges, so do not revoke them blindly without a backup and update plan.
Should you rebuild from backup or clean the existing site?
The right approach depends on whether you have a trustworthy pre-infection backup, whether current content or transactions must be preserved, and whether you can get host-level help. WordPress notes that full replacement is not feasible for every site; when it is not, careful replacement of core components and review of wp-content are part of recovery.
| Approach | When it may fit | Main trade-off |
|---|---|---|
| Rebuild or restore from known-clean materials | A backup is confirmed to predate the compromise, and the host has addressed any account- or server-level issue. | Restoring may lose newer content or transactions; the backup must include both files and database and must actually be clean. |
| Investigate and clean the existing site | No suitable clean backup exists, or important current data must be preserved. | It requires careful file, database, account, and possibly host-level investigation; deleting only visible malware is not enough to establish that persistence is gone. |
What a scanner can—and cannot—tell you
A scanner can identify suspicious files or known patterns, but a clean scan alone does not prove that every persistence path has been removed. Wordfence notes that database content may need manual cleaning and recommends following cleanup with site- and server-level hardening. If reinfection involves database state, a browser, or another site in the account, provider or human investigation may be necessary.
Free tools Windows power users keep installed
One-click scans. No signup required.
No independently verified prevalence or impact figure for the specific Monarx campaign is established in the cited material. The findings support taking recurrence seriously, not estimating how common this particular behavior is.
Quick 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.
