IDScan breach: 153M driver's licenses and the KYC flaw

What we know about the IDScan case

According to Krebs on Security, the "Nexus" service offered:

• 153 million driver's licenses (US and Canada), roughly 63% of all US licenses;
• 3 million travel documents;
• a database that kept growing, with nearly 400,000 licenses added in a single day, a sign that the access was still feeding it.

Krebs checked his own license and those of nine relatives. Senior US officials were in the data. The service vanished shortly after the story ran. IDScan published an incident notice; the cited sources do not detail the intrusion vector, and we will not guess it here.

The detail any vendor should notice is the continuous ingestion: the attacker was not reselling an old dump, they held access that pulled in fresh documents every day.

The flaw: a KYC store is a concentration point

An identity-verification provider receives front and back photos, selfies, document numbers and addresses. That data is needed once, at check time, yet it often stays stored for years. Three defects keep coming back:

1. Unlimited retention. Images sit in a bucket or database when only the outcome ("verified on ...") is needed afterwards.
2. Overly broad access. One API key shared by every customer, a support account that can see every document, a bucket with no policy: a single stolen secret opens the whole stock.
3. Predictable identifiers. URLs like /documents/184523.jpg or signed links that never expire let anyone walk through documents one by one.

A license is also a join key: its number shows up in other databases. Combined with an address and a photo, it turns an anonymous row into a profile usable for identity theft, credit fraud or intelligence work. The Anthem, Equifax and Office of Personnel Management breaches have been cited in exactly that context.

The pattern is not unique to IDScan. AU10TIX, 5CA (Discord's age-verification vendor) and National Public Data have had similar incidents. See also our analysis of the Revolut passport leak and of the 200,000 Florida DMV licenses.

How the attack plays out in practice

Without presuming anything about IDScan, the usual paths into an ID document store are:

• IDOR on the lookup API: the client app calls GET /api/verifications/{id} and the server returns the document without checking that the caller owns it. This is the flaw covered in our article on BOLA and IDOR.
• Stolen integration key: a KYC vendor API key with access to the full history, found in a Git repo, a JavaScript bundle or an infected laptop.
• Misconfigured bucket: public listing or anonymous reads on the image storage.
• Compromised internal account: a back-office tool that can search any document, with no logging and no volume limit.

In all four cases, exfiltration is slow and quiet if nobody watches lookup volumes.

How to test it

If you store or relay ID documents, check the following with two separate test accounts (never with real documents):

1. Enumeration. Grab the URL or ID of a test document from account A. From account B, then with no session at all, request the same resource and the neighbouring ID. Anything other than 403 or 404 is a vulnerability.
2. Signed links. Note how long download URLs stay valid. Reopen one the next day. If it lasts more than a few minutes, the link is a permanent key.
3. Storage. Try an anonymous bucket listing (aws s3 ls s3://<bucket> --no-sign-request or your provider's equivalent) and a direct read of a known object.
4. Retention. Find the date of the oldest stored document. If it predates your stated policy by a wide margin, the purge is not running.
5. Integration keys. Make sure no key from your KYC vendor appears in client code, NEXT_PUBLIC_* variables or Git history.
6. Logging. View ten test documents in a row from a support account. An alert should fire, or at least a usable trace should exist.

How to fix it

• Keep only the outcome. After the check, store the status, the date and a reference, then delete the images on a short, documented schedule.
• Scope per customer. One API key per customer, limited to its own verifications, and a server-side authorization check on every read.
• Short-lived links. Signed URLs valid for minutes, and never expose sequential identifiers.
• Encrypt with a dedicated key for documents, and require a reason plus logging for back-office access.
• Alert thresholds on lookup volume per account and per key.
• Audit your vendors: ask your KYC provider what it keeps, where, and for how long.

What happens when an AI agent has system access and the IDScan breach is in play?

More and more teams plug an AI agent into customer support or compliance, with a tool such as get_customer_documents. If that tool accepts a customer ID chosen by the model, the authorization boundary becomes the prompt. An email or ticket carrying a hidden instruction can push the agent to call the tool for another customer, then summarise the document in its reply or attach it to an outgoing message.

The check has to live inside the tool: the authenticated user's identity sets the scope, never a parameter filled in by the model. And the agent should only receive the verification status.

An agent wired to identity data deserves to be attacked before it ships. That is what the Agent Red Team Express is for: five days spent trying to make it reveal what it should never show.