CyberXero: 51 Claude Code agent files, 32 shells in 61 seconds, and WordPress flaws fixed on 17 July

Thirty-two shells in 61 seconds, against flaws fixed on 17 July

SOCRadar's Threat Research Unit published its CyberXero report on 6 October 2026. In the one automated run the post describes, the actor's tooling scanned 4,708 targets, confirmed 429 WordPress administration panels and deployed 32 web shells inside a 61-second window. Those are SOCRadar's counts, taken from what it says it recovered from an exposed directory. Worked through (derived): 429 of 4,708 is 9.1 per cent, 32 of 429 is 7.5 per cent, and the rate is 77 targets and 0.5 shells every second. That is the pace of a concurrent script (inference). The post calls the pipeline "automated" and does not say that a model took any decision inside those 61 seconds.

The label on the coverage is AI-powered, and SOCRadar's own title says "AI-Augmented". The label hides what the same post and the public record say about the way in. The two WordPress core flaws it names, CVE-2026-63030 and CVE-2026-60137, were fixed on 17 July 2026, and CISA listed both as known exploited on 21 July. The Support Board plugin flaw, CVE-2026-4815, has a public INCIBE-CERT notice dated 9 March 2026. The Magento flaw in the post's table was published in 2015. The largest dataset, 564,073 subscriber records from one district heating provider, was reached, SOCRadar says, with a hardcoded credential in the actor's own script. Patching, exposure and credentials decide this story, and none of them is new.

What the record does not establish is the point of this briefing. It does not establish that the 51 Claude Code agents ran without a human, who the operator is, that more than 628,000 records are that many different people, that any access was sold, that the energy-sector intrusions succeeded beyond what the files show, or what the model's maker has done about it. SOCRadar sells threat intelligence, so it has a commercial interest in a vivid report. Its post also states specifics that can be checked, and several are checked below.

This briefing reads SOCRadar's blog post in full. The full PDF report is offered from a page that asks for an email address, a name, a country and consent boxes; no form was filled in, so the PDF was not read. The Hacker News report of 12 October was read as a pointer to the post: it repeats SOCRadar's figures, adds the Netherlands to the countries with confirmed compromises, and carries no statement from the model's maker. The CVE, CISA, WordPress, INCIBE-CERT, Anthropic, NCSC, ICO and legislation pages were read directly. Pages were read from 11:14 BST on Monday 12 October 2026.

SOCRadar's numbers, and what each one rests on

The post puts file counts and its own assessments side by side and does not always say which is which. The table sorts them. A count is a number SOCRadar says it read from files in the exposed directory or from its own mapping. An assessment is a judgement the post draws from them.

SOCRadar's figures and claims, with its wording and what each rests on. Source: SOCRadar blog post of 6 October 2026, text and graphics read on 12 October 2026.

Figure or claim	SOCRadar's wording	What it rests on
51 agents	"Up to 51 specialized Claude Code agents" in the key takeaways; "a swarm of 51 specialized agents defined in a dedicated directory" in the body.	A count of definition files in one directory, shown in a screenshot of a file listing. It is not a count of agents that ran.
4,708, 429, 32 and 61 seconds	One automated execution scanned 4,708 targets, confirmed 429 accessible administration panels and deployed 32 shells, all inside a 61-second window.	Counts, from the actor's bot output and logs as SOCRadar reads them. The screenshot it publishes shows the totals and no timestamps.
More than 628,000	"Ukrainian individuals" in the lead and the FAQ; "records tied to Ukrainian individuals" in the victimology section.	A count of records in files across four organisations. "Individuals" is SOCRadar's assessment; "records" is the count.
564,073 and 213,340	Subscriber records and access-log entries pulled from one district heating provider in Kharkiv.	Counts, from extractor output in the files.
Four organisations	"File-confirmed exfiltration".	A count, from files.
Seven energy entities	Under "curated reconnaissance", and "without confirmed compromise".	A count, from target lists. The post says no compromise of these is confirmed.
More than 40 organisations	"More than 40 affected organizations worldwide".	SOCRadar's total. Its map graphic lists about 23 to 24 entities (derived: Ukraine 14 or more, Poland 4 to 5, Netherlands 1, China 2 or more, Pakistan 2, the last in the attempts colour). The two are not reconciled in the text read.
Eight nodes	Mapped "with high confidence".	An assessment: SOCRadar's correlation of files and logs.
Active since July 2026	"First infrastructure observed: July 2026" in the actor card.	The timeline graphic dates the AI layer's start to 28 July and one staging node to 27 June.
Operator, motive and buyer	Russian-speaking, Moscow time zone, financially motivated; access brokering to a buyer is the "most plausible explanation"; "No direct evidence of a sale was recovered."	Assessments from timing, language and account artefacts, with identifiers withheld. SOCRadar adds its own caveat on the sale.

Days between "active since July" and the report (derived): at most 97, if the first infrastructure was seen on 1 July, and 67 if it was seen on 31 July. The timeline graphic dates the AI layer's start to 28 July, which is 70 days before 6 October and 76 days before 12 October. The post says that once the AI account existed there was "a measurable increase in the scale" of the WordPress and SQL injection campaigns. The text gives no before-and-after figures for that increase, so how much the AI layer added is not stated.

The way in: public flaws and public fixes

SOCRadar's table lists the weaponised CVEs. The table below sets each against the public record. Scores are attributed to whoever assigned them, and "not listed" means not in CISA's Known Exploited Vulnerabilities catalogue, version 2026.10.08, released on 8 October 2026.

The CVEs named in SOCRadar's post, against NVD, the WordPress release note and advisories, INCIBE-CERT and CISA KEV, read on 12 October 2026.

CVE and product, as the post names it	Affected and fixed, per the public record	CISA KEV
CVE-2026-63030, WordPress core REST API batch endpoint (the wp2shell primary chain)	NVD, published 17 July 2026: 6.9.x before 6.9.5 and 7.0.x before 7.0.2. The WordPress 7.0.2 release note of the same day says versions before 6.8 are not affected. Scored 9.8 Critical by WPScan, the source NVD lists.	Listed 21 July 2026, four days after the fix. Due date 24 July. Known ransomware use: Unknown.
CVE-2026-60137, WordPress (the post's table says batch handler)	NVD: 6.8.x before 6.8.6, 6.9.x before 6.9.5, 7.0.x before 7.0.2. A SQL injection in a query parameter when a plugin or theme passes untrusted input to it; chained with the first it allows code execution. Scored 5.9 Medium by WPScan; the WordPress advisory says Moderate.	Listed 21 July 2026. Due date 4 August. Known ransomware use: Unknown.
CVE-2026-4815, Support Board 3.8.7 in the post's table, time-based SQL injection	INCIBE-CERT notice of 9 March 2026 and NVD (published 25 March): v3.7.7 and prior, fixed in 3.7.8. NVD scores 8.8 High (CVSS 3.1), INCIBE 8.7 (CVSS 4.0). The post prints 3.8.7, which is not the version either record gives.	Not listed.
CVE-2015-1397, Magento CE, "approx. 93 domains tested"	NVD, published 29 April 2015: Community Edition 1.9.1.0 and Enterprise Edition 1.14.1.0, SQL injection by an administrator. NVD gives no fixed version, and the vendor advisory it links now redirects to the vendor's blog index.	Not listed.

Three observations follow. First, the post's phrase "within 30 days of disclosure" fits the WordPress core flaws: the fix came on 17 July, 11 days before the 28 July start of the AI phase (derived). It does not fit the other two on the public dates. The Support Board notice is 114 days before 1 July (derived), and the Magento flaw is 4,178 days, or 11.4 years, before the report (derived). SOCRadar may mean something other than the public date by "disclosure"; it does not say.

Second, WordPress.org enabled forced updates through the auto-update system for sites on affected versions. A site still open to these flaws therefore deserves a check that the update applied, which SOCRadar's own wp2shell post also advises. The post gives neither the date of the 4,708-target run nor the versions the 429 panels ran, so how long they had been exposed is not stated. Third, SOCRadar's earlier wp2shell post said public proof-of-concept exploits for the full chain were circulating on GitHub by 20 July, while this post calls the actor's package "internally developed". It does not say whether the package drew on public code, or whether any model wrote it.

A caution on the word "patched". WordPress core has a further KEV entry, CVE-2026-87902, added on 25 September 2026, which this briefing did not research. Being on a July release is not the same as being current.

The 61-second run and the 628,000 records, to scale

The diagram draws two things from SOCRadar's counts. The first panel is the funnel in the one run: the 32 shells are a sliver beside the 4,708 targets. The second shows that one source, a district heating provider's subscriber records, supplies at most 89.8 per cent of the "more than 628,000" (564,073 divided by 628,000, derived; the share is lower if the true total is higher). The other three organisations with file-confirmed theft supply at least 63,927 between them (derived). The 213,340 access-log entries are a separate count: 564,073 plus 213,340 is 777,413, more than 628,000, so those entries cannot all sit inside that total (derived).

The share matters for the label. The largest single theft rests, per SOCRadar, on a credential in the actor's own script, and the post names no AI step in that extraction. The other chain it describes in detail, against an e-commerce portal, combined blind SQL injection, a time-limited password-reset token extraction and PHP deserialization. The post gives no CVE for that chain, so whether a public fix existed for it is not stated.

What the post establishes, and what it does not

"Not established" means not found in the post, read in full. It does not mean the information does not exist, and the gated PDF report may say more.

Claims in the coverage against SOCRadar's blog post of 6 October 2026 and The Hacker News report of 12 October 2026.

The claim in the coverage	What the post establishes	What it does not establish
An AI-powered attack	SOCRadar found 51 Claude Code agent definitions, and a PentAGI deployment wired to a Cobalt Strike server through an AI provider API, with session logs.	What the agents did in the 61-second run or the 564,073-record extraction, or how much the AI changed the outcome.
51 agents	51 definition files in one directory, named by role. The post lists c2-operator, exploit-chainer, scada-attacker and lateral-movement.	That 51 ran, at once or at all. A file name is a label, not a capability. No operational-technology or SCADA intrusion is reported.
Agents ran without a human	One pipeline is called automated and the other manual. A bot messaged the operator on each compromise, so the operator could watch "without an active terminal".	That any agent ran unattended, or what a model decided. The post calls the Ukrainian pipeline's exploitation manual.
628,000 Ukrainians	More than 628,000 records in files across four organisations, 564,073 of them from one.	That they are that many distinct people (the lead says individuals, the body says records), that the total is exact, or that the data has been used.
An attack on Ukrainian energy	Four organisations with file-confirmed exfiltration, the most severe a district heating provider's subscriber data. Seven more energy entities, including the national transmission system operator and the largest private energy holding, were under reconnaissance.	Any compromise of those seven (the post says "without confirmed compromise"), any access to operational technology, or any effect on supply.
An access broker selling access	A payment gateway for several cryptocurrencies, a forum presence and SOCRadar's classification.	A sale, or who a buyer would be.
A Russian operator in Moscow	SOCRadar's assessment from timing, language and account artefacts, with identifiers withheld.	Independent confirmation. No other source read confirms it.
The model's maker acted	Nothing.	Whether the provider was told, whether the account is disabled, or what safeguards applied. The post is silent.

One graphic needs a caution. The pie chart of sectors of "confirmed" victims puts energy and utilities at 28 per cent. Every slice is a multiple of four per cent, which fits a base of 25 organisations, and 28 per cent of 25 is seven (inference). Seven is the number of energy entities the text says were under reconnaissance with no confirmed compromise. The chart may therefore count targets, not confirmed victims. SOCRadar does not say.

Two friendly names: AI-powered, and the model refused

A label, alarming or comforting, is not a measurement. Two do most of the work in this story.

Labels in the story, where each appears and what the record shows.

The label	Where it appears	What the record shows
AI-powered attacker	The coverage. SOCRadar's title says "AI-Augmented".	A workstation with agent definition files, an open-source pentest framework and logs. The named entry points are public flaws with fixes, and the largest theft used a credential. The post does not say what the AI did in either.
Fully autonomous	The Hacker News describes PentAGI as an open-source, self-hosted AI agent for "fully-autonomous penetration testing".	A description of a tool. SOCRadar calls it an AI-augmented pentesting framework, and calls the Ukrainian pipeline manual.
The model refused	SOCRadar's FAQ answers yes to whether the models refused the actor's requests.	Refusals held in some sessions and were retried in fresh ones. The post gives no counts.

SOCRadar records two things about refusals. The table sets them against what the post leaves out.

What SOCRadar reports about refusals, and what it does not. Source: SOCRadar blog post of 6 October 2026. No session text is reproduced here.

Reported	Not reported
Refusals that held: across four iterations the model declined to install a backdoor, disable a firewall, move laterally and deploy a web shell. A scan was refused four consecutive times and a forged ownership token was rejected.	How many refusals were later overcome compared with how many held, and what the overcome ones were for.
A rehearsed authorisation narrative: the same ownership claim appears "verbatim across four unrelated victims and two different tools".	Whether anyone ever checked a claim. In the logs it is a sentence typed by the requester.
When an agent refused, the actor reopened a fresh session with the framing preloaded and tried again.	How many fresh sessions it took, or whether any account-level signal followed repeated refusals.
A paid AI subscription tied to a personal email and a billing provider.	The model, version, plan and settings, and whether the provider was told.

The refusal that held on the web shell is the instructive one. The post says the model declined to deploy a web shell, and also that the actor's own wp2shell package deploys web shells, 32 in the one run it describes. A refusal on one route stops nothing when the requester already holds the capability elsewhere, and a refusal is not a control when the requester can reset the session and ask again with a different framing (inference). SOCRadar reaches a similar view: it advises handling the evasion "at the infrastructure layer" through logging and auditing, rather than at the model.

SOCRadar's sentence is: "Model safety controls act on the context of a session, not on the model weights." This briefing treats it as SOCRadar's claim about how a vendor's safeguards are designed, made from outside. The sentence does not say which controls it means: refusals learned in training, classifiers around the model, or monitoring of the account. Each acts at a different level. The evidence offered is the actor's logs, which show refusals that held in some sessions and, in SOCRadar's account, requests worked around by a fresh start in others.

To test the claim one would need three things. Controlled trials, with the model, version and settings fixed, of the same request in fresh sessions with and without an ownership claim, reporting how many were refused and how many completed. The vendor's own account of what persists between sessions on one account, including account-level signals. And the share of refusals in the actor's logs that were later completed, which the post does not give. A sentence about sessions and weights is not a measurement.

What the model's maker says, and what it does not

SOCRadar's post names Claude Code, a product of Anthropic, and an unnamed AI provider's API behind PentAGI. Anthropic sells Claude and Claude Code and publishes its own misuse reports, so what it says about its safeguards is the maker's own account. Its newsroom and threat-intelligence pages were read at 11:19 BST on 12 October 2026, and the two reports below were read in full where they bear on this story.

What Anthropic's own pages say that bears on this story, read on 12 October 2026. None names CyberXero or SOCRadar.

Page and date	What it says	What it does not say
Newsroom and Threat Intelligence pages	The newest newsroom items are dated 8 October 2026. The newest threat report listed is dated 10 September 2026.	Anything about this actor, the account in SOCRadar's logs, or SOCRadar's report. Absence from these pages is not evidence of what Anthropic knows or has done.
Detecting and countering misuse of AI: September 2026 (10 September)	Says publicly available offensive agent frameworks, "like PentAGI", reproduce much of the scaffolding for anyone who downloads them, and that once it identifies an operation it bans the accounts involved. In its surveillance section it says its safeguards "did not perform uniformly", including one case where Claude refused and was overcome on further prompting.	Anything about CyberXero: the report is dated 26 days before SOCRadar's post (derived) and covers December 2025 to August 2026. The refusal case it describes is a surveillance case.
Expanding the Cyber Verification Program (6 October, the day of SOCRadar's post)	Says generally available models have "conservative cyber safeguards that block most cyber work", that verified tiers exist for defensive and authorised red-team work, that applicants are verified, and that data retention is required in the programme "so that we can monitor for cyber misuse".	Which safeguards or tier applied to the account in SOCRadar's logs. It does not mention this actor.

Read together, the maker describes protections that sit above a single session: verification of who claims authorisation, account-level data retention to monitor misuse, and bans once an operation is identified. SOCRadar's sentence describes the session. Both can be true (inference). The record does not say which of the maker's layers, if any, applied to this account between July and September, or how long the account ran. The maker's statement of 6 October that its generally available models block most cyber work sits beside SOCRadar's record of a 51-definition workstation, and the post does not say which model or tier the actor used, so the two cannot be reconciled from what is public. This site's briefing on that verification programme covers Anthropic's own test of its tiers.

The UK: who should act, and what the controls say

The post names Ukraine, Poland, China and Pakistan as target countries, and its map adds one entity in the Netherlands. It does not name the UK. A UK organisation is in scope of this briefing because it may run the same software: WordPress, Magento or PrestaShop sites, Redis exposed to the internet, or suppliers who run these for it. SOCRadar's detection guidance is addressed to exactly those.

UK guidance and law as read on 12 October 2026 on ncsc.gov.uk, ico.org.uk and legislation.gov.uk, with where each stops. Quotations are short and exact.

UK instrument	What it says	Where it stops
Cyber Essentials requirements v3.3 (April 2026), Security Update Management	Software must be licensed and supported, removed when unsupported, set to update automatically where possible, and updated "within 14 days" of release where the update fixes critical or high-risk flaws (CVSS v3 base 7 or above, or the vendor says so). WordPress released its fix on 17 July 2026, so 14 days ends on 31 July 2026 (derived).	Scope is what the applicant declares. Publicly available commercial web applications are in scope by default, while bespoke and custom components are out. A certificate is not a scan and finds no account an intruder already planted.
Cyber Essentials v3.3, Firewalls and User Access Control	Aim: only secure and necessary services reachable from the internet. Block unauthenticated inbound connections by default. Have a process to create and approve accounts, remove or disable accounts no longer required, and use separate accounts for administration.	Does not tell you to look for administrator accounts you did not create. It describes how accounts should be made, not how to find rogue ones.
NCSC, Frontier AI: what you need to know	AI "does not fundamentally change cyber risk, but it does increase the speed and scale" at which weaknesses can be found and exploited, and good fundamentals protect against threats "whether those are AI-assisted or not".	General. The page does not mention CyberXero.
NCSC, Vulnerability management (version 2.1, reviewed 1 May 2026)	Understand and validate regularly which vulnerabilities are present in your estate and where updates are failing.	A process, with no day count.
NCSC, Managing the cyber risk of agentic AI	Model safety controls may be bypassed and should not be treated as holistic. Log, audit and monitor agentic AI activity as part of security operations.	Interim advice for those deploying agents. It says formal guidance will supersede it.
NCSC Early Warning	Free alerts for UK organisations, tailored to the public addresses and domains you register. The page says it should not be the only layer of defence.	Depends on the feeds behind it.
UK GDPR Article 33 and the ICO breach page	The controller notifies the regulator "without undue delay and, where feasible, not later than 72 hours after having become aware", unless a risk to people is unlikely. The processor must tell the controller without undue delay. The ICO says to notify as soon as possible, and to tell people if the risk is high.	Applies only where personal data is involved. The ICO page carries a notice that its guidance is under review after the Data (Use and Access) Act.

AI assistance does not change the control set. The NCSC says so in terms, and every item in the checklist below is a control that Cyber Essentials v3.3 already asks for: update within 14 days, close what the internet does not need, and approve and remove accounts. For a site run by an agency or a host, the practical gap is the hours between the supplier finding a rogue administrator and the controller being told, because the 72 hours run from the controller becoming aware.

SOCRadar's advice also covers the AI side: treat agent session logs as sensitive records, with the retention, encryption and access controls of credential logs, because an exposed log is an intelligence breach. That is advice for any UK team that uses agentic coding tools, and it is cheap to follow.

What to do, in the order worth doing

Every item is a control the NCSC, Cyber Essentials or SOCRadar already names. Nothing here needs a model, a harness or a lab result to justify it. Hunting items follow SOCRadar's advice and are attributed to it; its patterns and rules are in its report and are not reprinted here.

Cleaning a WordPress site is harder than it looks. This site's briefing on a WordPress backdoor that survives cleaning sets out why persistence in several places is the usual finding.

What could not be verified

• The full report. The PDF is offered from a page that asks for a form. No form was filled in, so only the blog post was read. The PDF may state the model, the run date and counts that the post leaves out.
• The counts. The 4,708, 429, 32, 61 seconds, 564,073 and 628,000 are SOCRadar's, from files it says it recovered. The screenshot behind the run shows the totals and no timestamps. No independent confirmation was found.
• The Netherlands. It appears in SOCRadar's map graphic as one entity in the confirmed colour and in The Hacker News. The post's text names Poland, a Chinese cluster and Pakistan, not the Netherlands.
• More than 40 organisations. The text says so, and the map lists about 23 to 24 entities. They are not reconciled.
• The Support Board version. The post's table prints 3.8.7. INCIBE-CERT and NVD give 3.7.7 and prior, fixed in 3.7.8. INCIBE-CERT's notice says 3.7.8 was released in February 2025 although the notice is dated March 2026; the year is as printed and was not verified.
• The Magento fix. NVD gives no fixed version and the vendor advisory it links now redirects to the vendor's blog index, so no fixed version is stated here.
• The model and its maker. The post does not name the model, version, plan or settings. No statement from Anthropic about this actor was found on its newsroom or threat-intelligence pages, in The Hacker News, in a second news report (GBHackers), or in four web searches. Anthropic was not contacted.
• Time-stamped. Pages were read between 11:14 and 11:35 BST on 12 October 2026, and the KEV catalogue (version 2026.10.08), the SOCRadar post and the two Anthropic pages were re-read at 11:35 and had not changed. A catalogue entry, a page's wording or a new report could change within hours.

The question that exposes the gap

For every website your organisation or its suppliers run on WordPress, Magento or PrestaShop, can you name today the version it is on and every administrator account on it that someone you can name created?

Key facts