Think of a black-market shop where criminals buy and sell stolen credit card numbers — the same way someone might sell secondhand electronics, except everything sold is illegal and belongs to real people who have no idea their financial information is up for sale. That is what a "carding marketplace" is.
These sites operate in the hidden corners of the internet called the dark web, away from regular search engines. Buyers pay for batches of stolen card numbers, then use them to make fraudulent purchases before the real cardholder notices anything unusual.
Now here is the twist in this story: a major carding marketplace called Jerry's Store tried to build its own technical platform using AI coding tools to run its operation more efficiently — and accidentally left the front door wide open for anyone to walk in, exposing the very stolen data it was trying to sell.
Introduction
When cybercriminals outsource their infrastructure to AI and forget to check the output, the results can be darkly ironic. On April 16, 2026, researchers at Cybernews discovered an unprotected server belonging to Jerry's Store — a dark web carding marketplace that trades in stolen payment card data. The server, built largely using Cursor, a legitimate AI coding assistant, had been left completely open to the public internet: no authentication, no access controls, no login required.
The exposed data contained nearly 345,000 stolen credit card records — split between roughly 145,000 cards the platform had flagged as valid (complete with full card numbers, CVV codes, expiry dates, cardholder names, and billing addresses) and around 200,000 marked invalid. This is not a story about a sophisticated state-sponsored breach. It is a story about what happens when criminals use AI coding tools without understanding what those tools actually produce — and why the broader "vibe coding" trend carries real security consequences that extend well beyond criminal enterprises.
This post examines how the leak happened, what data was exposed, why AI-generated code without security review creates systemic risk, and what security teams and organisations should take from this incident.
How Jerry's Store Built — and Broke — Its Own Infrastructure
The "Vibe Coding" Approach That Failed
Jerry's Store operators built their carding platform using Cursor, an AI coding assistant developed by the U.S.-based company Anysphere. Cursor is a legitimate, widely used tool for professional software development. The criminals gave it vague natural-language instructions describing what they wanted — dashboards, server logic, card validation tooling — and the AI wrote the code.
This approach has a name in developer circles: vibe coding. The premise is straightforward — describe what you want in plain English and let the AI write the implementation. For rapid prototyping and non-sensitive tooling, it works. The fundamental risk is that AI coding tools generate functional code, not secure code. They execute the instructions given to them. If those instructions do not include "require authentication," the generated code will not require authentication.
That is exactly what happened. Cursor produced a working dashboard. Nobody reviewed it for security. The result was a fully functional, publicly accessible admin panel — visible to anyone with a browser — with no login prompt and no IP restrictions.
Important: This is the core failure mode of AI-assisted development that security teams need to understand. AI coding tools do not independently apply security best practices unless explicitly instructed to do so. "Build me a dashboard" does not produce a secure dashboard. CIS Control 16 (Application Software Security) and NIST SP 800-53 SA-11 (Developer Testing and Evaluation) both require security review of code regardless of how it was generated.
What the Exposed Server Contained
Cybernews researchers found the following data sitting on the open server:
- Approximately 145,000 card records flagged as valid — including full Primary Account Numbers (PANs), CVV security codes, expiry dates, cardholder names, and billing addresses
- Approximately 200,000 card records flagged as invalid — still containing partial card data and metadata
- Internal operational data showing the platform's card validation process
- Staff dashboards with administrative access to the marketplace's backend operations
The validation methodology itself added a further dimension of harm. Jerry's Store verified stolen cards by using them for small test transactions against real merchants, including Amazon, Grubhub, Sam's Club, Temu, Lyft, Elf Cosmetics, and CountryMax. To do this, the operators had created hundreds to thousands of fake accounts at these retailers — generating a trail of fraudulent account creation events (MITRE ATT&CK: T1585 — Establish Accounts) that legitimate fraud detection systems may or may not have flagged.
The Card Validation Economy: How Carding Platforms Actually Work
Understanding why an operation like Jerry's Store builds a validation tool matters for anyone designing fraud prevention controls.
Why Criminals Validate Stolen Cards Before Selling Them
Stolen card data degrades in value rapidly. Card issuers cancel compromised cards as soon as fraud is detected. A batch of 10,000 stolen cards may contain anywhere from 20% to 80% still-active cards depending on how recently the data was obtained. Buyers on carding marketplaces will pay significantly more for "validated" cards — those confirmed to still be live.
This creates a validation economy. Platforms like Jerry's Store offer buyers a service: pay a small fee, submit a card number, and the platform tests it against a real merchant transaction to confirm whether the card is active. This is sometimes called "card checking" or "CC checking" in underground forums.
The merchants used for validation suffer real consequences. Every test transaction, even if later reversed, creates chargeback costs, fraudulent account signals, and strain on fraud detection systems — effectively externalising the cost of criminal quality assurance onto legitimate businesses.
Attack Chain: From Stolen Data to Validated Sale
| Stage | Criminal Activity | MITRE ATT&CK Reference |
|---|---|---|
| Data acquisition | Buying stolen card dumps from dark web sources or skimmers | T1657 — Financial Theft |
| Account creation | Creating fake accounts at target merchants (Amazon, Lyft, etc.) | T1585 — Establish Accounts |
| Card validation | Testing cards via micro-transactions on fake merchant accounts | T1657 — Financial Theft |
| Marketplace listing | Listing validated cards for sale on Jerry's Store dashboard | T1583 — Acquire Infrastructure |
| Buyer purchase | Carding buyers purchase validated card data | — |
| Fraudulent use | Buyers use live cards for purchases or cash-out | T1657 — Financial Theft |
Why AI-Generated Code Without Security Review Is a Systemic Risk
The Deeper Problem This Incident Surfaces
It would be easy to dismiss this incident as criminals failing at operational security — and they did fail, spectacularly. But the same underlying failure mode exists in legitimate enterprise environments wherever AI-generated code is deployed without a proper security review process.
Cursor, GitHub Copilot, Amazon CodeWhisperer, and similar tools generate code that compiles and runs. They are not security scanners. They do not automatically add authentication middleware, enforce least-privilege database access, validate input, or apply encryption at rest unless the developer explicitly asks for and verifies those controls. Studies of AI-generated code in 2024 and 2025 have consistently found that security vulnerability rates in AI-assisted code are comparable to — and in some contexts higher than — those in human-written code, largely because developers tend to treat AI output as reviewed when it has not been.
Pro Tip: Treat AI-generated code exactly as you would code submitted by an external contractor: it requires a full security review before deployment to any environment containing sensitive data. Static Application Security Testing (SAST) tools should be integrated into the CI/CD pipeline to catch common flaws such as missing authentication, injection vulnerabilities, and hardcoded credentials — regardless of whether the code was written by a human or an AI.
Security Controls That Would Have Prevented This Exposure
| Missing Control | What It Should Have Done | Framework Reference |
|---|---|---|
| Authentication on admin dashboard | Prevented any unauthenticated browser access | CIS Control 6, NIST AC-3 |
| Network access control / IP allowlisting | Restricted dashboard access to known admin IPs | CIS Control 12, NIST SC-7 |
| Code security review (SAST) | Flagged missing auth controls before deployment | NIST SA-11, ISO 27001 A.14.2.8 |
| Secret scanning | Detected any hardcoded credentials in Cursor-generated code | CIS Control 4 |
| Vulnerability scanning of exposed services | Identified the open port/dashboard before attackers could | CIS Control 7, NIST RA-5 |
What This Means for Fraud Detection and Cardholder Protection
Indicators for Financial Institutions and Fraud Teams
Validated cards from a platform like Jerry's Store present a specific detection challenge. The validation step means that by the time a stolen card reaches a buyer, it has already been confirmed active — the window for issuer-side detection before fraudulent purchases begin narrows significantly.
Financial institutions should watch for these patterns that may indicate card testing activity:
- Multiple small-value authorisations (often under $1) from the same IP or device across different merchant categories
- Sudden creation of new accounts at major e-commerce merchants followed immediately by small transactions
- Authorisation attempts across cards from the same BIN (Bank Identification Number) range in rapid succession — a statistical signature of automated testing (MITRE ATT&CK: T1657)
Compliance Exposure for Affected Cardholders
Cardholders whose data appeared in the Jerry's Store leak face a range of downstream risks beyond immediate fraudulent transactions. Full card data combined with billing addresses enables not only card-not-present fraud but also targeted phishing attacks and, in some cases, identity theft attempts.
Organisations handling payment card data must maintain PCI DSS compliance. Issuers aware that cards have been compromised carry obligations under their card network agreements to notify affected cardholders and initiate reissuance. The broader data protection picture — particularly for cardholders in the EU — implicates GDPR Article 33 breach notification obligations for any merchant whose systems may have been the original source of the card data.
Key Takeaways
- Jerry's Store, a dark web carding platform, accidentally leaked 345,000 stolen credit card records because operators used AI coding tools to build their server infrastructure without any security review or access controls.
- The platform used legitimate retailers — Amazon, Lyft, Grubhub and others — to validate whether stolen cards were still active, inflicting chargeback costs and fraud signal noise on those businesses.
- AI-generated code does not include security controls by default. Treating AI output as secure without review is a critical mistake that affects both criminal operations and legitimate enterprises equally.
- Integrate SAST tools into any CI/CD pipeline where AI-generated code is deployed. Missing authentication is not a subtle bug — it is a first-pass catch for any competent code review process.
- Financial fraud teams should monitor for small-value multi-merchant authorisation patterns that indicate automated card testing activity against their portfolio.
- Any organisation storing or processing payment card data should verify that its developer workflows — including AI-assisted workflows — explicitly require and document security review before production deployment.
Conclusion
The Jerry's Store incident would be almost darkly amusing if the downstream harm were not so real — stolen payment data belonging to hundreds of thousands of cardholders, exposed by the very criminals trying to profit from it. But the incident carries a serious and broadly applicable lesson: AI coding tools generate code that works, not code that is secure.
That distinction matters enormously as "vibe coding" and AI-assisted development workflows become standard practice across every type of organisation, including those handling sensitive financial, health, or personal data. The absence of an authentication control on an admin dashboard is not an edge case that only naive criminals miss. It is a routine finding in enterprise security assessments of AI-generated and rapidly prototyped applications.
The practical next step for any security team is concrete: audit your current development pipeline for where AI-generated code enters production, confirm that SAST tooling covers those pipelines, and add a mandatory checkpoint requiring explicit sign-off on authentication and access controls before any new server or dashboard goes live. Jerry's Store's mistake was skipping that step. Your organisation should not make the same one.
Frequently Asked Questions
What exactly is Jerry's Store and how does it operate? Jerry's Store is a dark web marketplace that buys and sells stolen payment card data. It also offers a card validation service — buyers can pay a small fee to have a stolen card tested against real merchant accounts to confirm whether it is still active before purchasing it. The platform was built using AI coding tools, which generated server infrastructure and dashboards that were never properly secured before being deployed online.
How did Cybernews researchers find the exposed data? Cybernews researchers discovered the exposed server on April 16, 2026. The server was accessible on the public internet with no authentication — meaning any researcher, journalist, or additional criminal actor with a browser could access the dashboard directly. This type of exposure is typically found through internet-scanning tools that index publicly reachable IP addresses and open ports across the internet.
Does this mean AI coding tools like Cursor are unsafe to use? No. Cursor is a legitimate product used by professional developers globally. The failure here was not the tool itself but how it was used: the operators gave vague instructions, and nobody reviewed the output for security before deployment. Any code — AI-generated or human-written — requires security review before it handles sensitive data or is exposed to the internet. AI tools do not automatically add authentication controls, encryption, or access restrictions unless explicitly instructed and verified.
How can I tell if my card data was part of this leak? There is no public search tool for this specific dataset. However, if you notice unfamiliar small-value transactions on your card statement — particularly charges under a dollar from merchants you do not recognise — that may indicate your card is being tested by a fraud operation. Contact your card issuer immediately, request a new card number, and review your recent statement for any other unrecognised activity. Services like HaveIBeenPwned track some leaked datasets but may not have indexed this specific exposure.
What should merchants do if they suspect their platform was used for card validation testing? Review account creation logs for bursts of new accounts created in short time windows, especially accounts immediately followed by small-value transactions. Flag accounts with implausible creation patterns — identical device fingerprints, sequential email addresses, or rapid geographic inconsistencies — for manual review. Implement CAPTCHA and velocity limits on account creation and transaction authorisation attempts. Ensure your fraud monitoring rules include card-testing detection signatures, which look for statistical clustering of small-value authorisations across multiple cards from the same source IP or device.
Enjoyed this article?
Subscribe for more cybersecurity insights.