Open-Source AI Agents Steal 600,000 Credit Cards

What Gambit documented

A credit card theft campaign has been running since July 2026 on AI agent frameworks distributed as open source, and was still active as of 22 September. It was uncovered by Gambit, a security startup that gained direct access to one of the attacker's staging servers.

The numbers published on 23 September 2026 by BleepingComputer^[1]: more than 600,000 valid card records taken from two companies, skimmers active on at least 119 sites, 27 businesses compromised in five days.

The victims include a Fortune 500 hospitality chain, a major US airline, an American industrial distributor and an online fashion retailer. The primary research remains the write-up published on the Gambit Security blog^[2]. But another detail carries more weight.

A single human operator, identified by the researchers as Chinese, gave the agents brief instructions on the goals of the operation. Everything else was executed by the models.

Three agents, three distinct roles

The attack chain rests on three tools, each with a separate job.

• Strix: penetration testing framework, used for scanning and vulnerability discovery
• Cairn: autonomous exploitation engine, driven by goals such as "get a shell" or "get admin access"
• Hermes: campaign orchestration, tactical decisions and post-exploitation work, running on the claude-opus-4.6 model

Hermes carried within it a persona called "SOUL - Red Team Operator" and 121 loaded skills, 78 of them attack-related. It is a red team operator profile packaged as a software bundle.

This separation of roles matters a great deal. Reconnaissance, exploitation and orchestration remain swappable modules: whoever runs the campaign can change the exploit engine and keep the rest of the stack. The architecture mirrors a CI pipeline, with the same maintenance advantages.

The Cairn in this campaign should be kept distinct from the identically named malware analysis tool released by Cisco Talos on 22 September 2026. Same name, opposite purposes.

The interesting technical point is that all three run on public code. The attacker's edge comes from integrating the pieces, more than from the power of any single component.

The tempo: 105 waves in five days

Between 23 and 31 August 2026 Strix was launched 146 times against 138 hosts, for a total of 633 hours of scanning. Between 10 and 15 September the attacker launched 105 distinct waves, succeeding against at least 27 targets.

This volume describes a factory, more than an intruder.

An equivalent human team would require shifts, coordination and a six-figure monthly budget. Here the marginal cost of the twenty-eighth victim tends toward that of an API call. The economics of the attack flip: the bottleneck moves from person-hours to tokens.

For defenders, the practical consequence concerns the time window. The distance between scanning and exploitation compresses from weeks to hours, and a monthly patch cycle becomes arithmetically inadequate.

Six ways to plant the skimmer

Injection of the skimming code varied according to the level of access obtained, the flaws found and the target's architecture. The methods observed by researchers span the entire technology stack.

• Code appended to the end of legitimate JavaScript files
• Script tags inserted into checkout pages or Google Tag blocks
• Content poisoning on S3 and CDNs, as well as server-side caches
• Modification of database fields
• Alteration of Kubernetes deployments
• Cron jobs that restore the skimmer after removal

That last item deserves attention. A restoration cron job turns remediation into a loop: the team removes the payload, the schedule rewrites it, monitoring reports clean in the wrong window.

The list describes an adversary that knows modern deploy pipelines. Kubernetes and CDNs were treated as persistence surfaces on a par with the filesystem. This level of operational competence, applied to hundreds of targets in parallel, was previously the preserve of structured groups.

Target selection ran through a web traffic ranking service, applied to the list produced by Strix, with priority given to sites on custom platforms. The economic logic is straightforward: high traffic means more cards per hour of agent work.

The underlying condition: the runtime is public

The condition that ties the three components together is simple: they are open projects, installable in minutes. Releasing an open-source runtime for AI agents distributes offensive capability and defensive capability under the same licence.

This is a structural property, and it should be treated as such in risk assessments.

The security community has already lived through the Cobalt Strike case and the Metasploit one. The difference today concerns the control plane: earlier tools required an operator for every session, whereas these accept a goal in natural language and produce tactical decisions on their own.

Whoever controls orchestration controls the architecture, and here orchestration costs nothing. Defence loses the advantage that came from the scarcity of capable operators.

The corollary for technology buyers: risk estimates based on "how hard is it to find good people" have expired. They need to be replaced with an estimate based on the throughput an adversary can buy with a few hundred dollars of inference.

How much of this is genuinely new

Intellectual fairness is required here. The agents exploited classic web flaws: misconfigured access, exposed components, permissive deploy chains. The research describes volume and speed, more than a novel class of exploit.

The finding is both reassuring and uncomfortable.

Reassuring because basic hygiene still works: patch management, segmentation, integrity of the files being served, control over third-party tags on payment pages. Uncomfortable because that same hygiene, applied with the delays typical of an average company, leaves open a window an agent exploits in a matter of hours.

It should be said plainly: the report documents the campaign and its metrics, and leaves out details on the agents' error rate. How many of the 105 waves failed because of model hallucination, and how many because of effective defences, remains an open question. An honest reading accounts for that margin.

Three questions for the enterprise AI team

These questions should be raised at the next application security meeting, with a written answer on the record.

1. How many minutes does it take the team to detect a change to a JavaScript file served in production, and with which integrity check?
2. What process vets the third-party tags loaded on checkout pages, and how often does it run?
3. How much time passes between the publication of a CVE affecting exposed components and the actual patch on the public perimeter?

The first question measures the ability to see the skimmer. The second measures control over the payment surface, which remains the economic target of the entire campaign.

The third measures the distance between the internal patch cycle and the adversary's tempo. A figure expressed in weeks indicates an implicitly accepted risk, and should be taken to the board as such.

Anyone answering "monitoring covers the perimeter" has already given the wrong answer: the skimmers described lived inside legitimate assets, served from the company's own CDN.

A fourth item deserves space in the minutes: the list of domains serving JavaScript to payment pages. In most businesses that list is longer than the team expects, and it is worth trimming before the next traffic peak.

Decisions for the next planning cycle

For the CTO, the review concerns the frontend delivery chain. Bundle integrity, artefact signing and Subresource Integrity on payment pages move from good practice to requirement.

For the Head of Engineering, the point is detection speed, more than breadth of tooling. A hash check on served files, run every few minutes, catches a good share of the injection methods listed by the researchers.

For the CFO, the risk profile of application security spending changes. The expected cost of an e-commerce incident rises, because the probability of being reached grows with the attacker's throughput. Budget lines for WAF, bot management and integrity monitoring need to be reread in this light.

For the technology procurement committee there is a single contractual question: which CDN provider, tag manager and e-commerce platform guarantees in writing the detection of changes to served content, and within what timeframe? Generic clauses about "security best practices" need to be replaced with measurable SLAs, with penalties attached.