motiberman

For a WordPress site on a budget, a solid free starting mix is Wordfence’s free plugin (https://wordpress.org/plugins/wordfence/), WPScan’s free site check (https://wpscan.com/), and Mozilla’s HTTP Observatory for public header configuration (https://developer.mozilla.org/en-US/observatory). Keep core, themes, and plugins updated, use unique strong passwords with 2FA, and keep offline backups. Automated tools miss a lot of logic and access-control bugs, especially on sites that hold user data — treat them as one input, not a clean bill of health.

When Imunify keeps finding the same payloads inside WP Rocket cache after a purge, the source is usually regenerating them from a theme file, plugin, mu-plugin, uploads PHP, or a database option — not the cache alone. Purge Rocket completely, then hunt those locations for injected scripts and unknown admins; your host’s Imunify quarantine list helps map the paths. Because you are on Wordfence Premium, wordpress.org free support cannot take the case — use the Premium channel your license opens, as Peter noted. Rebuilding cache only after the source is clean is what stops the loop.

Use Wordfence’s “View Differences” on wp-includes/version.php before worrying — a real content change matters more than a timestamp quirk after an update. If the diff shows unexpected code, replace wp-admin and wp-includes from a clean copy of your exact WordPress version, then review users, plugins, and mu-plugins. Confirm you are on a current security release afterward. Restoring those two folders is a first step, not proof the whole site is clean.

Your first install, with the plugin.upload_plugin Central log, lines up with the known October incident; keep that evidence and finish every step in https://teamupdraft.com/blog/security-incident-october-2026/ For the Free install that never knowingly used Central, keep other vectors on the table: shared admin machines, reused passwords, hosting-level access, or an old key/option still in the database. After the malicious folders are gone from disk, rotate salts and every credential that could have been readable on those servers, and watch both sites for reinfection over the next several days.

A third site getting the same svc… admin pattern usually means something left behind (plugin, mu-plugin, or credential) rather than a brand-new Central session. Over SFTP, remove every unknown folder under wp-content/plugins/ and wp-content/mu-plugins/ by deleting the folders on disk — not only from the Plugins screen — then remove unrecognized admins and rotate WordPress, hosting, SFTP, and database passwords, and shuffle salts in wp-config.php. TeamUpdraft’s current checklist still applies, including sites that looked clean after the first round: https://teamupdraft.com/blog/security-incident-october-2026/ Ask your host for access logs around the day the new admin appeared so you can see how that known account was used.