Skip to content
Security & Trust

A WordPress forced update and a plugin backdoor show updates need an owner

Wordfence's July report covers a core flaw fixed by a forced update and a plugin backdoor. Someone must own both.

W
WebPulse Newsroom
AI-assisted · 4 min read
Share on X LinkedIn
A WordPress forced update and a plugin backdoor show updates need an owner
In brief
  • Wordfence's July report describes a WordPress core flaw chain, patched on July 17 in three release lines, and a plugin backdoor in two ARVE versions, 10.8.7 and 10.8.8.
  • The two cases show why updates need an owner: one update was the fix for a flaw, and the other may have been a route for code from a compromised developer account.
  • Confirm your WordPress version is patched, check whether ARVE 10.8.7 or 10.8.8 is installed, and ask how plugin updates are reviewed.

After a security scare, site owners usually hear one instruction: update. July 2026 offers two cases that test that advice. In one, the update was the fix. In the other, the plugin's own code is described as carrying the way in.

Two cases from one monthly report

Wordfence published its July bug bounty report on October 29. It says the program received 1,077 vulnerability submissions in the month. Its case studies highlight two cases.

The first is a flaw chain in WordPress core. The WordPress Security Team shipped fixes on July 17 for two vulnerabilities that, used together, can let an unauthenticated attacker run code on a site's server. In plain terms, a stranger can take over the server without logging in. The chain is known as wp2shell. Wordfence credits Adam Kues of Assetnote / Searchlight Cyber with discovering and reporting it.

The patched builds came in three release lines: 6.8.6, 6.9.5 and 7.0.2. Wordfence says WordPress's release notes rate the issues as one critical and one high severity. Per those notes, WordPress also switched on forced automatic updates for affected versions, because of how serious the problem was.

How the core flaw works

Wordfence says the problem sits in the REST API batch endpoint, /wp-json/batch/v1. The REST API lets programs talk to a site. The batch endpoint bundles several requests into one.

Wordfence describes a mismatch between route and validation. A request is checked as one thing but dispatched to a different handler. That bypasses the allow_batch restriction and the input cleaning on the target route. Wordfence says this can be chained with SQL injection, a way of slipping commands into the database.

Think of a guard who checks a visitor's pass for one door, while the visitor is sent through another. The check happened. It just did not apply.

The plugin case: a login with no password

The second case involves the Advanced Responsive Video Embedder (ARVE) plugin. Two releases, 10.8.7 and 10.8.8, are said to contain a built-in login that anyone can use. Wordfence's report does not say who found it.

A function called _arve_uc_init() runs at the earliest point of every request, before authentication checks. It reads a token from the _wplogin or _wpm parameter. It compares that token to a SHA-256 hash written into the plugin source. Wordfence says there is no nonce check, no capability check and no password validation.

The result, per Wordfence: an unauthenticated attacker who supplies the known token is logged in as any existing administrator, with full control. Wordfence's guess is that the code was probably planted by someone who had taken over the developer's commit access, meaning the ability to change the plugin's source.

The report does not say how many sites installed those versions. It does not say whether the backdoor was used. It also does not say how the affected versions reached sites.

What the pair shows

The lesson here is that the update channel is a control, not a reflex. In July, WordPress used forced updates to close a hole fast. In the plugin case, a compromised developer account appears to have been the route for the bad code.

This part is our inference, not the report's. Plugin updates are how new code reaches a site, so a compromised developer account can reach sites the same way. For a site owner, the same update mechanism can carry a fix or a problem.

Context from WebPulse's scan

WordPress is common among popular sites. In WebPulse's September 2026 scan of the Tranco top 10,000 domains, 7,064 responded and a platform was detected on 2,491. WordPress accounted for 719 of those, or 28.9%, second to Next.js at 791. Exposure to the core flaw depends on the version a site runs. The scan does not measure versions, so it cannot say how many of these sites were affected.

A protection gap to ask about

Wordfence says its Premium, Care and Response users get firewall protection in real time. It says free users are protected in 30 days. That is the vendor's own description of its service. If your site relies on a firewall rule while a patch is pending, know which tier covers you.

What to ask your team this week

First, which WordPress version does each of our sites run, and is it 6.8.6, 6.9.5, 7.0.2 or later? Second, is ARVE installed anywhere, and was it ever at 10.8.7 or 10.8.8? If so, review administrator accounts and recent logins.

Third, who reviews a plugin when its version changes? Automatic plugin updates save time, but they can also pass along whatever a developer's account publishes. Fourth, who holds publishing access to the plugins your business depends on, and how is it protected?

An update is only as trustworthy as the account behind it. Someone in your organisation should own that question by name.

Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Wordfence.

WordPress vs Next.js