A page asks a visitor to "verify you are human," wears Cloudflare's look, and ends with a hidden backdoor on a WordPress site. If you log into your own WordPress dashboard, that is a fair thing to lose sleep over. The fake Cloudflare verification WordPress attack that security researchers reported in October 2026 needs one thing from you: a browser that is already signed in to your admin account.
Securonix Threat Research (Akshay Gaikwad and Aaron Beardslee) describes the attack in its report TRUST#GRAFT: JavaScript Attack Targets WordPress Admins with PHP Backdoor, available by October 27, 2026. A script on the fake screen checks whether your browser is logged in to WordPress, then uses that session to upload and switch on a plugin you never chose.
You can run the first check yourself in about ten minutes. It starts with your list of administrators and ends with a folder that WordPress keeps out of its plugin list.
Key Takeaways
Securonix reports that the fake verification screen looks for a browser already logged in to WordPress with permission to install plugins, then uploads a fake plugin called Web Media Optimizer.
Users, Plugins, the wp-content/mu-plugins/ folder (look for wmedia-recovery.php) and your server logs. A clean result lowers the risk but does not certify the site.
Cloudflare says its Turnstile challenge usually needs no action from the visitor, so a page that asks you to open Run, PowerShell or Terminal is not a Cloudflare check.
Know what the attack does the moment an admin lands on the page
The fake screen is only the first step. Securonix says a script on that page fingerprints your browser, routes the page content through the attacker's servers, and may try to put a command on your clipboard for you to paste. That clipboard step is a reported capability, not a confirmed execution.
The step that matters to a site owner comes next. The script checks whether your browser is already logged in to WordPress. If your account can install plugins, it borrows that session and does the rest on its own, using the same upload and activation pages you would use yourself.
The reported sequence, as Securonix describes it
- 1
Step 1
A loader shows a fake Cloudflare-style verification screen and fingerprints the browser.
- 2
Step 2
The script checks whether the browser is already authenticated to WordPress.
- 3
Step 3
If the account can install plugins, it requests /wp-admin/plugin-install.php?tab=upload and reads a WordPress nonce, the one-time token WordPress uses to confirm a request is real.
- 4
Step 4
It downloads wm.zip and posts it to update.php?action=upload-plugin.
- 5
Step 5
It asks WordPress to activate the plugin, a fake "Web Media Optimizer" that installs a persistent PHP backdoor.
This is abuse of a legitimate administrator session and WordPress's normal plugin workflow, so it is not a flaw in WordPress core. The same logic gives you a useful limit: an account without plugin-install rights is not what this chain is built to use. How the fake screen first reaches an administrator is still unresolved, so the checks work whatever the route.
Get a yes or no on your own site in ten minutes
Work in this order. Each step is quick, and each one can end the search early if you find something.
Start with Users. Open the Users screen in WordPress and read every administrator. Anyone you cannot explain should be suspended or removed, but confirm who owns the account and save a record of it before you delete anything. Then open Plugins and look for one named Web Media Optimizer, anything added recently, and anything you did not install yourself. Confirm that two-factor login is on for every administrator.
The ten-minute check, in order
Read every administrator. Suspend what nobody can explain, and save evidence before deleting.
Look for Web Media Optimizer, recent additions and plugins you did not install.
Confirm it is on for every administrator.
With hosting access, open wp-content/mu-plugins/ and look for unexpected files, especially wmedia-recovery.php.
Search recent requests for the upload and activation paths and the file and domain names in the table.
The fourth step is the one that catches people. WordPress documents that must-use plugins switch on automatically, do not appear in the normal plugin list, and cannot be turned off from that list. Securonix names `wp-content/mu-plugins/wmedia-recovery.php` as the persistence file. A site can look clean on the Plugins screen and still carry a copy there.
| Indicator from the Securonix report | Where to look |
|---|---|
| Plugin named Web Media Optimizer | Plugins screen in WordPress |
| wp-content/mu-plugins/wmedia-recovery.php | Hosting file manager or SFTP |
| /wp-admin/plugin-install.php?tab=upload | Web server access logs |
| /wp-admin/update.php?action=upload-plugin | Web server access logs |
| /wp-admin/plugins.php?action=activate | Web server access logs |
| /p/wm.zip | Web server access logs |
| gerlace[.]com, vtevens[.]icu, caapman[.]me | Logs and page source (loader candidates the report lists) |
| wm2_a, wm2_src, wm2_hc | Logs and files (strings the report lists) |
Ask your host for the access logs if you cannot reach them yourself. A clean result across all of this lowers the risk. It does not prove the site is clean, so keep the admin habits in place even when nothing turns up.
Spot a real Cloudflare check before you act on a fake one
A genuine check asks very little of you. Cloudflare says its Turnstile challenge runs in the visitor's browser and in most cases needs no further action; when interaction is needed, it may show a simple checkbox. Its documentation on how challenges work covers the browser-based checks, full-page challenge screens and embedded widgets a visitor can meet.
Nothing in that flow asks you to open the Windows Run box, Command Prompt, PowerShell or Terminal, or to paste anything. A page that does is inconsistent with the documented Turnstile flow. Close it, and do not run the command. MITRE tracks this trick as malicious copy and paste. A related lure is covered in our post on fake ChatGPT custom GPTs and ClickFix malware.
The Cloudflare look of a screen says nothing about who built the page. Securonix describes a Cloudflare-style screen, so treat the branding as imitation.
Stop the next fake screen from reaching your site
Securonix recommends separating WordPress administration from ordinary browsing. In practice, that means signing in to the dashboard in its own browser or browser profile, signing out when you finish, and doing your everyday browsing somewhere else. That lowers the chance that an unrelated page can reach your admin session. It does not replace updates, backups or account security.
Two-factor login still belongs on every administrator account, since WordPress's hardening guidance recommends two-step authentication. It protects the sign-in. The reported chain reuses a session that is already signed in, so two-factor login alone does not stop it.
The same hardening guidance suggests turning off dashboard PHP editing by adding `define( 'DISALLOW_FILE_EDIT', true );` to the site's configuration. Test it with your host first, since some workflows depend on file editing. Keep WordPress and plugins updated, install only from trusted sources, and review the Users screen on a schedule. Our guides to adding and removing admin users and checking plugins for urgent security updates cover those routines step by step.
Decide what to do if something turns up
If any indicator appears, treat it as a real incident. Save your logs and backups first. Isolate the site, rotate the passwords for WordPress, hosting, the database and any deployment accounts, and get a complete cleanup. Deleting only the visible plugin leaves the mu-plugins copy in place, so the access can come back. Securonix recommends removing both the visible and the hidden components.
You can handle the first check alone. Bring in outside help when you find an unexplained administrator, the Web Media Optimizer plugin, an unexpected mu-plugin, suspicious PHP, unexplained plugin-upload requests, or logs that are missing. The work at that point is evidence preservation, complete removal, credential and session recovery, a clean restore and verification that nothing is left. Our walkthrough of the first 24 hours after a site is hacked lays out the order for the early hours.
Sometimes the files cannot be trusted at all, because no clean backup exists or the site has been altered in many places. In that case a rebuild on clean code is safer than cleaning around the damage, which is where web design work earns its place.
Check what you know about this attack
Pick an answer to begin.
1. What does the reported attack need in order to install the fake plugin?
2. Where does the report say a persistent copy of the backdoor can sit?
3. A verification page tells you to open PowerShell and paste a command. What should you do?
Frequently Asked Questions About Fake Cloudflare Verification Pages on WordPress
Can a fake Cloudflare check install a WordPress backdoor?
Securonix describes a path that can. A script on the fake page uses an administrator's signed-in browser to upload and activate a malicious plugin. It needs a session with plugin-install rights.
Is this a hole in WordPress itself?
Securonix describes abuse of an authenticated administrator session and WordPress's normal plugin upload, not a flaw in WordPress core. Keeping WordPress updated still matters, but updates alone do not stop a signed-in session from being used.
What should I check first?
Check Users for administrators you do not recognize, Plugins for Web Media Optimizer or anything you did not install, and wp-content/mu-plugins/ for unexpected files such as wmedia-recovery.php. Then review your logs for the upload and activation requests.
Does two-factor login stop it?
Two-factor login protects the sign-in and belongs on every administrator account. The reported chain reuses a session that is already signed in, so keep a separate browser for admin work as well.
Does seeing a fake verification page mean my site has a backdoor?
Not by itself. The WordPress step in the report requires an administrator browser that was already signed in with plugin-install rights. Run the ten-minute check, and treat any indicator as an incident.
Should I paste a command that a Cloudflare check gives me?
No. Cloudflare says Turnstile usually needs no further action, and a page that asks you to open Run, Command Prompt, PowerShell or Terminal is inconsistent with that flow.
The Bottom Line
The reported attack leans on one thing: an administrator who is signed in to WordPress while browsing elsewhere. Check Users, Plugins, the mu-plugins folder and your logs, in that order. Keep admin work in its own browser, keep two-factor login on every account, and never run a command that a verification page hands you.
A clean result gives you peace of mind for today and a routine for next month. An indicator gives you a clear reason to preserve evidence and bring in someone who can clean the whole site rather than the part you can see.
If something turns up, or the result is unclear, Web Leveling can run a website security audit that covers the files, mu-plugins, logs, credentials and backups, and verifies the cleanup afterward. We work with small and medium businesses across the country and overseas. Contact us about a security review and we will tell you what we find, including when the answer is that nothing needs fixing.
Terms
Words used in this post
Tap a term to see what it means.
Administrator session. The logged-in state of your browser after you sign in to WordPress, which lets it act with your permissions until you sign out.
Nonce. A one-time token WordPress uses to confirm a request came from a real action on the site.
Must-use plugin (mu-plugin). A plugin stored in wp-content/mu-plugins/ that WordPress turns on automatically and leaves out of the normal Plugins list.
Backdoor. Hidden code that lets an attacker get back into a site later.
Turnstile. Cloudflare's challenge that checks a visitor in the browser, usually without any action from them.
Persistence. A way for malicious code to stay on a site after the first visit, such as a file that reloads itself.
