This is not a bug
Every other advisory we publish describes a mistake — a missing check, a bad assumption, an off-by-one. This one describes intent. On 28 July 2026, version 10.8.7 of the Advanced Responsive Video Embedder plugin — around 20,000 active installations — shipped with a function named_arve_uc_init(), hooked onto WordPress’s init action at priority 1, so it runs before almost everything else.
The function reads a token from the _wplogin or _wpm request parameter and compares it against a SHA-256 hash hardcoded in the plugin source. If they match, the request is authenticated as any existing administrator account the attacker names. No nonce verification. No capability check. No password.
A hash embedded in source code that anyone can download is not a secret. It is a universal credential, valid on every site running that version. The classification says it plainly: CWE-506, embedded malicious code.
What made it survivable
Two things kept this from being a catastrophe. It was caught in under two hours. Wordfence’s automated analysis flagged the malicious code on 28 July, less than two hours after it was published. The plugin repository was closed for downloads the same day. Auto-updates had not yet propagated it. The WordPress.org team confirmed the malicious release had not been broadly distributed through automatic updates before the takedown. Most of those 20,000 sites never received 10.8.7. Note the irony: automatic updates, the control that would normally have protected you, is the exact channel a supply-chain compromise travels down. It was slowness that limited the damage here.Sizing your exposure
Checking your sites
Find out whether the plugin is present, and at which version:If the backdoor was present
Removing the plugin closes the door. It tells you nothing about who came through it first. Work through it in this order:- Remove the plugin.
wp plugin deactivate advanced-responsive-video-embedder && wp plugin delete advanced-responsive-video-embedder - Audit administrator accounts, including creation dates and email addresses. The backdoor authenticates as an existing admin, so a rogue account is not guaranteed — but attackers commonly add one for persistence.
- Look for files added or modified since 28 July, particularly PHP under
wp-content. - Rotate everything: administrator passwords, application passwords, API keys, database credentials, and any secret stored in
wp-config.php. Regenerate the salts while you are there. - Force-logout every session so a stolen cookie stops working:
wp user session destroy --all --all-users
What this changes about plugin trust
The uncomfortable conclusion is that reviewing a plugin’s code once tells you about the version you reviewed, not the version you will receive next Tuesday. Trust in a plugin is trust in whoever holds commit access to it — indefinitely, and usually invisibly. That does not make plugins unusable. It makes a few habits worth the effort:- Fewer plugins. Every plugin is a standing grant of code execution to a third party. The best defence is a smaller list.
- Prefer maintained, widely-installed plugins, with several maintainers rather than one. A single-maintainer plugin is a single account to compromise.
- Remove what is deactivated. A deactivated plugin still sits on disk and still receives updates. It is exposure without benefit.
- Delay non-security updates by a few days on production sites. That is exactly the window in which this backdoor was caught.
- Keep backups you have actually tested restoring. Shared hosting backups and VPS snapshots are only useful if you know the restore works.