Your credit card may have been stolen while making an online purchase.

Editor's Note:

GFM's "Financial Investigations" is currently continuing its "After the Fire, Who Will Rebuild Los Angeles?" series, tracking public issues such as post-disaster housing, insurance, mortgages, urban governance, and community equity. However, when real risks to payment security emerge, the media also has a responsibility to intervene promptly.

This article focuses on an ongoing AI Agent attack campaign. It links website testing, vulnerability exploitation, and payment data theft into a low-cost, replicable process that directly impacts consumer credit card security, merchant payment pages, PCI DSS compliance, cybersecurity, and corporate governance.

Therefore, GFM has designated this article as part of its latest special investigation on "Digital Payment Security" under "Financial Investigations," and it is not included in the "After the Fire, Who Will Rebuild Los Angeles?" series. This addresses current risks while maintaining clear and distinct editorial boundaries for both public investigations.

Jeff Morgan

(Image caption) A laptop and credit card displaying an online shopping payment interface. The screen uses abstract data routing to illustrate the security risks that payment data may face on the merchant's website, corresponding to the discussion in this article on the online shopping payment process and the theft of payment data.

Exposing the attack chain left by the server

When shopping online, consumers usually focus on the product, price, and whether the payment was successful, but rarely ask: Is the page where I enter the card number, expiration date, and security code still fully controlled by the merchant?

An ongoing cybersecurity operation has brought this issue to the forefront. Cybersecurity firm Gambit Security stated that its threat intelligence team discovered and reconstructed an attack chain centered around an AI agent on an attacker's temporary server that was accidentally exposed to the public network. The investigation revealed that the operators used concise Chinese commands to drive multiple publicly available tools, continuously scanning online merchants, attempting to gain system access, implanting card-stealing programs on checkout pages, and compiling leaked data.

What's disturbing about this incident isn't just the suspected leak of a large number of payment card records, but the changing organization of attacks. Tasks that used to require multiple technicians working together can now be broken down into continuous tasks and executed by agents over extended periods; human operators retain the ability to select targets and make key decisions, but no longer need to manually complete every technical step.

Gambit also emphasized that this is still an interim investigation report. Its judgment is based partly on the leaked data and attack tools already obtained, partly on payment page card-stealing programs that are still operating or have been removed but have left records, and partly on logs and agent reports from the attacker's servers. The scope of the damage, the amount of data, and the corporate losses still require further confirmation from the companies involved, payment institutions, and law enforcement agencies.

Numbers should not be confused.

According to Gambit's initial reconstruction, the activity dates back to July 2026 and has not yet completely ceased. Between September 10 and 15 alone, an automated tool called Cairn launched 105 attack projects; at least 27 enterprises were compromised to varying degrees.

These figures represent different levels of risk and should not be interpreted in a lumped manner. Over 600,000 payment card records that have not yet expired are allegedly from two of the victimized companies; researchers have confirmed that at least 19 victimized websites had their checkout pages implanted with programs that steal card information. In addition, over 100 websites have been identified by external researchers as being associated with the same set of skimmer infrastructure, but the timing of their infection, outflow of data, and actual losses have not yet been independently confirmed.

Gambit partnered with anti-fraud company Overwatch Data to process the card information involved and notify the card issuers. According to its published statistics on card issuers, approximately 488,000 records, or about 79% of all records, belonged to U.S. cardholders. For ordinary households, this could mean card suspension, replacements, suspicious transactions, account monitoring, and concerns about the long-term misuse of their personal payment information.

(Image caption) Servers, event timelines, and abstract network nodes in a cybersecurity investigation workspace demonstrate the investigative environment in which researchers reconstruct attack operations based on exposed servers, logs, and technical evidence.

The attack was broken down into three sets of tools.

This operation did not use the rumored secret weapons. Gambit pointed out that the operators used three publicly available AI tools in combination: Strix was used to discover website vulnerabilities and exposure surfaces; Cairn, after receiving the target and task, continuously attempted to gain system access; and Hermes was responsible for coordinating tasks, maintaining past work records, arranging the next round of operations, and providing strategic advice.

Model services were also integrated into this workflow. According to account and log data held by Gambit, operators obtained model capabilities through OpenRouter; DeepSeek, GLM, and the earlier Claude Opus 4.6 were used at different stages. Researchers stated that newer models rejected some requests, prompting operators to explore other options to continue the work.

During 260 Hermes work phases, researchers recorded 1,951 user inputs. Many of these instructions were short, such as asking the system to read the vulnerability report before starting work, or to continue searching for the next entry point based on existing results.

This doesn't mean humans have withdrawn from attacks. Target selection, data processing, stopping points, and cleanup are still human decisions. The change is that humans no longer need to operate each computer individually, write code line by line, or personally trace every failed step. Agents can repeatedly test different paths within hours, read the results, and continue to the next round of work.

In the past, groups capable of simultaneously mastering vulnerability research, system intrusion, malware development, and payment data processing often required long-term accumulation and a clear division of labor. Now, these tasks can be broken down into modules and integrated into a single automated process. Capabilities don't appear out of thin air, but the cost of acquiring, coordinating, and expanding capabilities is decreasing.

Cost reductions make long-tail merchants a target.

Gambit discovered that OpenRouter model access expenditures totaled approximately $7,005.71 in the attacker's account over the four weeks ending August 25. Based on the even higher model access volumes in the following three weeks, researchers estimated the total model access cost of the operation to be between $12,000 and $18,000.

Another set of more revealing figures comes from the attackers' own cost records: in 101 completed scans, the average model cost per target was approximately $25.46, with a minimum of $3.13 and a maximum of $79.31.

This isn't the full cost of crime. Server rentals, proxy services, failed missions, data transfers, and subsequent monetization can all incur additional expenses. But for corporate governance, the key point is that the marginal cost of testing a merchant is low enough to alter how attackers choose their targets.

When testing a website costs only tens of dollars, attackers don't need to succeed every time, nor do they need to prioritize challenging the most heavily defended large platforms. They can continuously test a large number of websites, looking for historical technical debt, outdated components, misconfigurations, gaps left by outsourced development, and poorly managed third-party code.

The truly vulnerable parts of the global payments ecosystem are often not the few tech giants with large security teams, but rather the vast number of mid-sized retailers, travel websites, subscription services, vertical e-commerce platforms, and local brands. These businesses rely on website revenue but may not have the capacity to continuously audit all code, external scripts, cloud permissions, and vendor connections. AI agents allow attackers to painstakingly search for these vulnerabilities one by one at extremely low cost and with immense patience.

(Image caption) Multiple different types of retail products and website illustrations are connected to a single control node, illustrating the economic logic of automated tools testing a large number of merchants and expanding the scope of attacks at low marginal cost.

Credit cards may be intercepted before payment is made.

This type of attack is known as e-skimming in the field of payment security, and is often classified as a Magecart-style attack. Its danger lies in the fact that attackers may not need access to the bank's core system, nor may they need to directly breach the credit card company's defenses.

If a merchant's website payment page or related code is infected with malicious scripts, the card number, expiration date, and security code entered by the consumer in their browser may be copied and transmitted before being sent to the legitimate payment system. The website may still function normally to the consumer, and the order may be completed as expected, making it difficult to detect immediately.

This is precisely why the PCI Security Standards Council introduced new requirements for payment pages in PCI DSS v4.0 and v4.0.1. Section 6.4.3 requires merchants to create a list of every script loaded and executed on the payment page, confirming that it is authorized, has integrity verification, and has a reasonable business or technical justification; Section 11.6.1 requires enterprises to establish mechanisms to detect unauthorized changes to security-related HTTP headers on the payment page.

To consumers, these rules may seem technical and distant; but they answer a simple yet crucial question: Who placed that piece of code you can't see on the checkout page? Who confirmed it hadn't been replaced? Who will receive an alert if it's been tampered with?

What cardholders can do is to discover it as early as possible.

Consumers cannot inspect the code on a merchant's website themselves, nor can they determine whether a checkout page has been infected with a card-stealing program. However, they can still shorten the time to discover risks and deal with problems by following a few habits.

First, enable instant transaction notifications for your credit card and bank accounts. The earliest sign of stolen card information is often not an official letter from the bank, but rather a small, seemingly insignificant test transaction.

Secondly, when shopping online, it is advisable to prioritize using credit cards over debit cards directly linked to bank accounts; credit cards typically have clearer dispute resolution procedures. If the issuing bank offers virtual card numbers, digital wallets, or one-time payment options, it can also reduce the chances of your physical card number being repeatedly exposed to different merchant systems.

Finally, consumers should check their transaction history regularly, rather than just waiting for the end-of-month bill. If they discover unfamiliar, small, or vaguely described transactions, they should immediately contact the card issuer and take steps to suspend or replace their card. Large, seemingly reputable merchants are not necessarily safe; the most difficult place for payment page theft is precisely where it might be hidden within a long-trusted, seemingly functioning website.

(Image caption) A consumer is preparing to make an online purchase payment in front of a laptop. The transparent layer conceptually presents the integrity of the payment page and the issue of code security, reminding readers that successful payment does not mean that the data is absolutely safe.

Businesses must safeguard payment pages at machine speed.

Once attackers continue their work using automated tools, companies that still rely entirely on manual alerts, cross-departmental meetings, and scheduled patching will easily find their response time stretched thin. This doesn't mean companies should delegate all critical decisions to AI, but rather that their defense processes should also be fast enough.

Enterprises should continuously review their internet-facing assets, payment pages, and third-party dependencies, and monitor script integrity, abnormal administrator access, and unusual data transfer behavior. When payment page programs, cloud permissions, or management accounts exhibit abnormalities, the system should be able to isolate high-risk connections first and promptly hand over the most critical incidents to cybersecurity personnel.

For listed companies, this presents both a disclosure and governance issue. The U.S. Securities and Exchange Commission's Form 8-K Item 1.05 stipulates that once a company determines a cyber incident to be material, it must typically disclose the nature, scope, timing, and actual or reasonably probable impact of the incident within four business days. This timeline begins with the determination of materiality, not with the initial discovery of the incident; however, companies cannot unreasonably delay the determination of materiality.

With increased attack speed, technical forensics, legal, finance, cybersecurity, customer service, and investor communications can no longer operate independently. They must be integrated into the same decision-making chain from the very beginning of an incident; otherwise, companies may miss the critical window for isolation, notification, and disclosure before fully assessing the damage.

(Image caption) The enterprise cybersecurity and operations team monitors the abstract payment page and abnormal alert information, which corresponds to the article's proposal that enterprises need to safeguard the digital payment environment through continuous monitoring, access control, and rapid response.

Banning accounts cannot resolve the entire risk chain.

This operation also illustrates that while model security barriers are necessary, they cannot be considered the whole answer. The new model rejects dangerous commands, increases the cost of abuse, and leaves important anomalous signals; however, attackers can use different models, different frameworks, different accounts, and different cloud resources.

Therefore, the responsibility cannot fall solely on a single modeling company. Modeling service providers need to identify high-risk task orchestrations and abnormal tool calls; open-source agent frameworks should incorporate access control, tool sandboxes, and audit logs into their default designs; cloud and domain service providers should address clearly malicious control nodes more quickly; and payment companies and merchants must bear direct responsibility for the integrity of payment pages and the governance of third-party code.

Cyber insurance, PCI DSS compliance, incident response drills, and board risk reports also require a new assumption: future attackers will not work only during the day, will not get tired of repetitive tasks, and will not need to manually test each company one by one.

This incident does not prove that AI will inevitably lead to uncontrolled cybercrime. The same agent capabilities can also be used for code review, vulnerability patching, threat detection, and incident response. The real dividing line lies in whether the defender is willing to update its policies, permissions, and security infrastructure at the same pace.

For every cardholder, the most direct reminder is simple: credit card security depends not only on whether you have the card in your hand, but also on whether the checkout page where you enter your card number is still properly guarded by the person who should be responsible for it.

Disclaimer

This article is based on publicly available information and interim investigations by cybersecurity researchers. Some of the scope of the damage, the scale of the outflow, and the technical details still need to be further confirmed by companies, law enforcement, and regulatory authorities. The content is for news research and information reference only and does not constitute legal, investment, or cybersecurity advice.