Gambit's 27 'compromised' companies match 48 projects on record minus 21 that never left reconnaissance

27 is what is left when 21 are taken from 48

Gambit Security's report of 22 September 2026 carries a chart of what one of the operator's three harnesses, Cairn, did between 10 and 15 September. Its legend sorts every project into five outcomes: card skimmer deployed, 5; data exfiltrated, 5; RCE or admin panel control, 9 (RCE is remote code execution); lesser access, meaning a file read, an IDOR, an injection point and the like, 8; and reconnaissance only, 21.

Add them up and the total is 48, the number of projects the report says it could still see. Take away the 21 that never got past reconnaissance and 27 remain. That is the figure in the report's opening paragraph, at least 27 companies 'compromised to varying degrees', and it is the figure behind The Register's headline of 25 September, which names a Fortune 500 hospitality company and a major US airline and then counts '25+ other orgs'.

So the arithmetic reproduces the headline, and it shows what the headline is made of. The 27 is 56 per cent of the 48 projects on record and 26 per cent of the 105 that were launched. The other 57 projects had been deleted and were, in Gambit's words, not available for analysis. The report calls itself interim and says Gambit expects the true size and impact to be larger. Both can hold at once: the total may be higher while the share that succeeded is lower.

The card counts and the skimmer half of this campaign are covered in our earlier briefing on the same report, which found that the 617,938 card records came from two databases and not from the skimmed sites. This piece takes the other half of the record: what the agents did to get in, what a person did, and which ordinary controls sat on the path.

What 'compromised to varying degrees' contains

The 27 stacks four different outcomes. The table gives, for each furthest stage on Gambit's chart, how many projects reached it and how they ended. Completed means the objective was achieved, stopped means abandoned before the goal, and active means still running when the chart was captured. The end-state split per stage is our reading of the chart, cross-checked against the legend's own totals of 16, 19 and 13.

The 48 Cairn projects on record, by furthest stage reached, from the chart in Gambit Security's report of 22 September 2026. The end states are our reading of the chart.

Furthest stage on the chart	Projects	Completed, stopped, active	Not stated
Card skimmer deployed	5	2, 3, 0	Whether the skimmer stayed in place or captured any card
Data exfiltrated	5	3, 2, 0	What data, and which rows the 600,000 card records came from
RCE or admin panel control	9	9, 0, 0	What the access reached afterwards
Lesser access: file read, IDOR, injection point and the like	8	1, 4, 3	What was read, and whether an injection point counts as compromise
Reconnaissance only	21	1, 10, 10	Why one project marked completed produced only reconnaissance
All on record	48	16, 19, 13	How the other 57 projects ended

The 27 is the first four rows. Nineteen of them reached a skimmer, stolen data or code execution or admin control, and eight reached less. All 13 projects still running when the chart was captured were at reconnaissance or lesser access, so the chart is a snapshot and those 13 may since have moved. Ten of the 48 rows are outside the United States, including one in the UK, and the chart labels every row by sector and country only.

One loose end from our earlier briefing is resolved by the chart. The report's summary says skimmers were installed on the websites of five, while a later section says skimmers were ordered against at least 27 named victims and confirmed on 19. The chart's 5 skimmer rows match the first figure. We read the five as the Cairn sample and the 19 as the wider campaign, which is inference: the report does not reconcile them.

Four victims are described, none is named, and two descriptions match a row

Gambit names no victim, and neither does The Register, BleepingComputer or any other coverage we read. This briefing names none and does not try to work out who they are. The report's own list is four descriptions of organisations to whose assets the operator gained 'some level of access': a Fortune 500 hospitality company, a major US airline, a large private US industrial supplies distributor and a US online fashion retailer.

The size label deserves a sentence. Fortune describes its list as ranking the biggest US companies by revenue. That is a statement about turnover. It says nothing about the maturity of the code behind a login page, which is where this campaign began.

Set the four descriptions beside the 48 chart rows. There is an airline row in the United States: furthest stage RCE or admin panel control, ended completed. There is an industrial supply row, but it is reconnaissance only and was still running when the chart was captured. No row is labelled hospitality. The only fashion-type row is clothing in Australia, not the United States. The prose does describe a large American hospitality company as the place where a skimmer payload was written into a cached checkout page, but it does not say that this is the Fortune 500 company.

The report says its claims of compromise rest on three tiers of evidence: files found on the operator's staging server, live compromises it verified in the wild, and logs plus the agents' own claims, the last accepted where the first two corroborated substantial parts. It does not say which tier supports which of the four descriptions. Three explanations fit the mismatch with the chart and the report does not choose between them: the descriptions come from the 57 deleted projects, from activity since July that the chart does not cover, or from labels that differ between prose and chart. None of that is a criticism of an interim report. It does mean a headline built on the four descriptions rests on something a reader cannot check against the one published chart.

Autonomous, unattended, and 1,951 human prompts

The report's opening says the operator ran three harnesses 'almost entirely unattended'. The Register calls the attacks near-autonomous. The label paints a machine that finds a target and takes it. The same report supplies the human side in numbers and quotations, and the two pictures have to be held together.

Who did what, on Gambit Security's own account of the campaign

Step	Who, per the report	Not stated
Choosing targets	The person. Filtered a traffic-ranking list down to shops with custom code, assuming they were likelier to be vulnerable, and pasted in 301 results. Two targets were handed to the agent already holding a working administrator password	How those passwords were obtained, and whether the custom-code filter worked
Finding weaknesses	Strix, on GLM 5.2 and later DeepSeek v4 Pro: 146 deep-mode runs against 138 hosts between 23 and 31 August	How many findings were real
Getting from finding to access	Cairn, on DeepSeek v4.1 Flash. Paths chosen in real time and mostly different for each victim, up to 25 campaigns in parallel	Whether a person stepped in mid-run, and any success rate across all 105
Getting past refusals	The person. Hermes ran on Opus 4.6 after newer models refused, and a skill was added whose purpose is to remove the harness's own content filters	Which newer models refused, how often, and whether the other two models ever did
Deciding to destroy data	A wipe-after-extraction step sits in the playbook Gambit attributes to the attacker, and the person changed a live instruction 14 minutes after giving it. The agent's over-broad name match dropped 180 tables at one retailer, backups included	Who wrote the wipe skill, since Hermes can write its own skills, and how many victims lost data: the report says only 'some of the breaches'
Infrastructure	The operator: staging and command servers, skimmer hosts and three commercial proxy services	Who the operator is, or where

The tempo is real. Strix logged 633 hours of scanner time in 195 hours of clock time, which is 3.25 scans running at once, and the chart's own panel caps Cairn at up to 25 campaigns in parallel. A person does not do that. Nor does a person need to type much: 1,951 prompts across 260 sessions is 7.5 per session, in short Chinese instructions.

Gambit says that came to 'only a few prompts per target'. That holds only if the number of targets is in the hundreds, which the report's opening does say. Divide the 1,951 by any count the report does publish and the answer is larger: 19 across the 105 projects, 41 across the 48 on record, 72 across the 27 compromised. Those divisions overstate the human effort, because some prompts concern skimmer placement and not intrusion. They do show that the phrase depends on a denominator the report does not print.

All three harnesses are published openly, and their own pages ask for permission first. Strix is Apache 2.0 licensed and says to run it only against systems you own or have explicit written permission to test. The Cairn repository we found under that name is AGPLv3 with commercial terms on request and says not to use it without clear prior permission from the owner. Hermes Agent, from Nous Research, is MIT licensed and describes itself as a self-improving AI agent, not a security tool. Gambit does not link its Cairn, so whether that repository is the one the operator ran is not established here. The point is narrower: an open licence and a permission notice are statements of intent. They bound nothing, and an operator who ignored them lost nothing by doing so.

Refusals and the removed content filters are covered at length in our earlier briefing. One addition: Opus 4.6 was used 'after newer models refused', and the report does not say which, so no reader should conclude that any particular current model can or cannot be steered. The same open source framework, Hermes Agent, also appears in a Docker botnet report of the same week from a different vendor, covered in this briefing. Neither report links the two operators.

This analysis was researched with Claude, made by Anthropic.

One documented chain: fourteen steps and no CVE

The report documents one completed Cairn project step by step. Counted as the report lists it, the chain has 14 steps, from an unauthenticated SQL injection at a login field to a verified decryption of a stored card column. No step names a CVE, a product version or a patch. Every step is a weakness class with a long-standing ordinary control, which is the useful thing to know. The table gives each control and where it would show in your own telemetry. It describes controls only; nothing in it is a method.

The chain Gambit documents, grouped into seven rows, with the ordinary control that breaks each and where it would show. The controls are ours and the cited standards'; the report does not say which victim had which weakness.

Steps in the chain	Control that breaks it	Where it would show
Unauthenticated SQL injection at a login field	Parameterised queries, so input is never treated as code, and an application database account with only the rights it needs (OWASP; PCI DSS 6.2.4)	Database errors on the login route; login fields far longer than any real email address
One-time passcode read in plaintext from a database table, which bypassed MFA	Do not keep a usable second factor where the login code path can be tricked into reading it; short expiry and single use (NIST SP 800-63B-4 caps out-of-band authentication at 10 minutes)	Reads of the passcode table by anything other than the verification code
Admin panel access, then an unrestricted file upload leading to code execution on the host	Admin interfaces off the public internet; allowlisted extensions and type checks; uploads stored off the web server or outside the web root (OWASP)	Non-image content arriving in an image field; new executable files in upload locations
Root through a passwordless sudo rule for a scripting interpreter, then an NFS export that kept root	Remove passwordless privilege for general-purpose interpreters; root squashing, which the NFS manual describes as the default	sudo use by the web service account; mounts of internal storage from a web host
Database credentials in a configuration file on the share, a new blog admin added through the database, a plugin upload	Secrets out of files on shared storage; least-privilege database accounts; plugin installation disabled in production	New admin accounts outside a change window; new plugin files
A full dump of 46 secrets from a cloud secrets store, then the main commerce database	Scope each role to the secrets it needs and keep the path private (AWS Secrets Manager best practice); a blog host has no route to payment credentials	One principal reading many secrets in a short window; commerce database connections from the blog tier
Encryption key extracted, stored card column decrypted	Do not store card numbers you do not need; protect keys against disclosure and keep them out of reach of the host that holds the data (PCI DSS 3.5.1, 3.6.1)	Reads of key material; bulk selects of the card column

Read down the middle column and one thing stands out: there is no patch in it. The first weakness is an application flaw class, in code the report does not describe as bespoke or off the shelf, although the operator's filter aimed at bespoke. The rest are configuration and privilege choices, and none of them waits on a vendor. That is why the report's argument that patch speed 'stops being the only lever' needs care here. It rests on a statistic about flaws exploited on or before the day they are disclosed, attributed by Gambit to a16z and not checked by us, and this chain contains no disclosed flaw.

Break any one link and this chain stops. The campaign does not, because Gambit says each attack path was chosen in real time and was mostly different across victims. So the control worth having is the one that removes a class of weakness everywhere, not one matched to this chain. Nor does the report say whether any victim ran a web application firewall, endpoint detection or central logging, so 'would have stopped it' is a statement about the weakness, not a test of any product.

What the certificate covers: bespoke code sits outside Cyber Essentials

The operator's target filter kept shops with custom code, on the stated assumption that bespoke code was likelier to be vulnerable. Set that beside the most common assurance label in the UK.

The NCSC's Cyber Essentials requirements for IT infrastructure, version 3.3 of April 2026, set the scope for software development this way: publicly available commercial web applications are in scope by default, and 'Bespoke and custom components of web applications are out of scope.' The same paragraph says the best way to mitigate application vulnerabilities is robust development and testing, and points to the Software Security Code of Practice. The NCSC describes that code as a voluntary code for technology providers, setting out principles expected of organisations that develop or sell software.

So a Cyber Essentials certificate is evidence about five infrastructure controls: firewalls, secure configuration, security update management, user access control and malware protection. It is not evidence about the code in a login form, an upload field or an admin panel. Some later steps in the chain, the privilege and share configuration, fall within themes Cyber Essentials does test, subject to what a given certificate scoped in. The first steps sit in application code. If that code was bespoke, which the report does not say for this victim, they fall outside the scope note.

PCI DSS is different in kind. Version 4.0 requirement 6.2.4 requires techniques to prevent or mitigate common attacks in bespoke and custom software, and names injection attacks including SQL. Requirement 3.5.1 requires a stored card number to be rendered unreadable, and 3.6.1 requires the keys protecting it to be secured, with key-encrypting keys stored separately from data-encrypting keys and keys held in the fewest possible locations and forms. Gambit does not say where the key was held or whether either victim was assessed, so this briefing draws no conclusion about compliance. It is the text a reader can hold their own estate against. The wording is from the v4.0 SAQ D for Merchants; v4.0.1 is the current version and its text is behind a licence gate we did not bypass.

Hours, measured against the chart

Gambit's summary says that where access was achieved it usually took less than a day and in many cases a few hours. The chart lets us test that. We measured the bar for each of the 14 completed projects that reached a skimmer, stolen data or RCE or admin control. The measurement is by pixel on the published image, so it is good to about an hour, and a bar runs from the project's launch to its end marker.

The fastest took about 7 hours, the median about 13 and the slowest about 53. Ten of the 14 finished inside 24 hours and eight inside 13. So 'usually less than a day' holds. 'A few hours' holds only if a few stretches to seven or more, since none of the 14 bars is shorter than about six hours.

$25.46 is the price of a scan, not of a compromise

The report's title and The Register's subhead lead with $25. The report's figure is the operator's own cost review: a mean of $25.46 over 101 completed scans, from $3.13 for the cheapest to $79.31 for the dearest. Three checks follow.

First, 101 times $25.46 is about $2,571. Against Gambit's estimated total model spend of $12,000 to $18,000, the completed scans account for 14 to 21 per cent of it, and the report does not say what the rest bought. Second, 'completed scans' is not defined, and 101 matches no other count in the report: not 27, 48, 105, 138 or 146. Third, spread the whole bill over the 27 companies and it is $444 to $667 each. That is a ceiling on cost per compromise, not an estimate, because the bill covers about seven weeks (four weeks to 25 August, then three more) and the 27 covers six days. Gambit's own framing, a few dollars to a few tens of dollars per targeted company, needs a denominator in the hundreds that the report does not publish.

None of this rebuts the economics. Even $667 is small beside what a retailer loses, and a person nudging a harness is cheap. It does mean that $25 should not be repeated as the price of a breach.

What the coverage added, and Gambit's commercial position

Three places where coverage runs past Gambit's report of 22 September 2026

Coverage	The report's own words	The gap
The Register headline: 'break into' a Fortune 500 hospitality company, a major US airline and '25+ other orgs'	'Some level of access to the assets of' companies including those four; 27 compromised 'to varying degrees'	Eight of the 27 are labelled lesser access. 25+ is 27 minus the two named, which is at least 25
The Register: 'at least 105 attacks'	105 attack projects were launched	Projects are not attacks or companies, and 'at least' is the coverage's addition
TechRadar headline: 'Massive Chinese hack'	Prompts and a persona are in Chinese; no attribution is made	Language is not attribution. The report names no state, group or country

Method and accusation are different things. Gambit recovered the operator's staging server and rebuilt the campaign from it, which is a much stronger position than inferring an actor from artefacts, and nothing above disputes that. What the report cannot yet tell you is how its evidence tiers map onto each headline number.

Gambit's business is cyber resilience, and the report's closing argument is resilience: it says organisations should shift to a resilience-first mentality and a security stack that matches AI speed. That is a commercial position, and it fits part of the evidence, since the destruction here was a side effect of a cleanup routine. It is not the only conclusion the evidence permits. The chain above supports a plainer one: fix the ordinary weaknesses first.

What to do, in the order worth doing it

For the checkout page itself, script inventories and tamper detection, use the checklist in our earlier briefing.

The question that exposes the gap

The operator filtered for custom code on the assumption that it was likelier to be vulnerable, and custom code is exactly where the Cyber Essentials scope note stops. That filter needed no artificial intelligence. The harnesses supplied stamina, and the person supplied the choice of where to point it.

So take the certificate, the audit report and the line in the last board paper that says MFA is on, and ask of each what it says about the code your own developers wrote for the login page, the upload field and the admin panel.

Does the scope of the assurance you hold cover the custom code an agent would filter you in for, and if the answer is that you would have to check, who is checking before the next 25 projects run at once?