decrypted · 21 july 2026 · vulnerabilities and patching · supply chain · ai and llm security

Two small bugs in WordPress core added up to a takeover that needed no login

Two long-known building blocks of WordPress core, a batch API endpoint and a query filter, turned out to fit together into a full unauthenticated takeover this week. WordPress patched it fast and forced the update onto affected sites without asking permission first. That is the good news. The bad news is that proof-of-concept exploit code is already public, and the security firm watchTowr says it is seeing the first signs of exploitation in the wild. With WordPress running a large share of the UK's small business, charity and parish council websites, this is the one to check today, not at the next patch cycle.

Two bugs, no login required

CVE-2026-63030 is a mix-up in WordPress's REST API batch endpoint, /wp-json/batch/v1, which lets several sub-requests run in one call. It tracks those sub-requests in two lists that are meant to stay in step. Feed it a sub-request that errors out and the two lists slip by one, so a later request gets processed under the wrong handler, one that was never meant to see unauthenticated input. Picture a hotel front desk handing out room keys from a list that has quietly shifted by one row: the guest at the counter gets someone else's key, and nobody behind the desk notices.

That confusion opens the door to CVE-2026-60137, a SQL injection sitting in the author__not_in parameter of WP_Query. The code expects an array there and validates it as one; hand it a string instead, and the validation is skipped, letting the raw value drop straight into the query. Chain the two together against a default WordPress install, no plugins, no theme customisation, no account, and an anonymous visitor can reach remote code execution on sites running 6.9.0 to 6.9.4 or 7.0.0 to 7.0.1 (the older 6.8 line carries the SQL injection but cannot chain to RCE). WordPress shipped fixes in 6.8.6, 6.9.5 and 7.0.2 on Friday.

The patch that didn't wait to be asked

The genuinely useful decision here was not the fix, it was what WordPress did next: it switched on forced auto-updates for every affected site, whether or not the owner had opted into automatic updates at all. That is the Secure by Design lesson worth taking from an otherwise routine core bug. A parish council or small charity running a five-year-old WordPress install with no in-house IT was never going to patch this itself within 24 hours of a public proof-of-concept landing. Compare that with the last fortnight of on-prem SharePoint and AD FS patching, where the fix existed but organisations still had to find it, test it and apply it themselves, and attackers walked through the gap in the meantime. Making the secure state the default, not an opt-in click, is what actually closes the window. UK organisations running WordPress should still confirm their version manually rather than assume the forced push landed: WordPress has not said whether sites that switched auto-updates off entirely were reached.

Also this week

A RubyGems supply chain attack woke up old accounts to plant new malware. Three gems, including one impersonating Microsoft's Git Credential Manager, were pushed from maintainer accounts dormant since 2019, carrying a payload that fetches a binary from a self-hosted git server and persists via cron and systemd. It deliberately checks for CI environment variables and exits if it finds them, aiming squarely at developer laptops rather than build pipelines. Any UK team with Ruby or Rails in its stack should treat long-unused maintainer accounts on any package registry as a live risk, not a historical curiosity: dormant credentials are exactly what Secure by Design is supposed to retire.

An autonomous AI agent breached Hugging Face's own infrastructure, and the company's account of the incident is worth reading for what it reveals about both sides. The attacker chained a malicious dataset loader and a template injection to get code execution on a processing worker, then ran thousands of automated actions across disposable sandboxes to harvest credentials and move across internal clusters, all without a human at the keyboard throughout. Hugging Face's own defence relied on an AI model to sift 17,000 logged events into a timeline. No UK data was implicated, but the pattern of agents attacking agent infrastructure, at agent speed, is the one to watch as UK firms plug AI platforms into anything that holds credentials.

LockBit 5.0 posted a claim against Briggs of Burton, a UK process engineering firm dating to 1732, threatening to publish stolen data unless contacted. Briggs of Burton has not commented publicly, and the only reporting so far comes from a dark web monitoring service, so this belongs in the unverified column rather than the confirmed one. Still, it is a reminder that heritage manufacturing and engineering firms, not just banks and tech companies, sit on LockBit's target list.

Sources

Questions about what any of this means for your own systems? Get in touch.

More like this

Get the next post by email: subscribe to Decrypted. Double opt-in, unsubscribe any time, or take the RSS feed.