ANTS Breach 2026: 11.7M Accounts and the IDOR Hypothesis

What do we actually know about the ANTS incident?

ANTS says it detected an incident on April 15, 2026 and made it public on April 20. The Interior Ministry reported the facts to the Paris prosecutor, and the national cybercrime office (OFAC) is investigating. On April 21 the ministry announced 11.7 million affected accounts. A seller on an underground forum reportedly claims up to 19 million records: that figure is unconfirmed.

The data cited for individual accounts is the login, title, last name, first names, email address, date of birth and unique account ID. Depending on the account, the postal address, place of birth and phone number may be added. Attachments to application files are reportedly not affected. No official statement describes the cause: the IDOR label comes from secondary sources and should be treated as a hypothesis.

What is an IDOR and why is it so common?

An IDOR occurs when an application refers to a resource (account, file, document) by an identifier and does not check that the logged-in user may access it. If the API answers /api/accounts/4512889 as readily as /api/accounts/4512890, any user can walk the whole database by incrementing the number.

OWASP ranks this family first in its API Top 10 under the name BOLA (Broken Object Level Authorization, API1:2023). It is common because authentication works: the user really is logged in. The missing piece is the second question, authorization on that specific object. We cover the pattern in our article on BOLA and IDOR in APIs and in the OWASP API Top 10 guide.

Who is exposed to this kind of flaw?

Any application whose API accepts an identifier from the client: citizen portals, customer areas, HR systems, health platforms, marketplaces. Exposure grows with the number of accounts and the predictability of identifiers (sequential numbers, emails, license plates). On the official figures, the ANTS incident is one of the largest leaks of the year in France, to be compared with the France Travail leak in 2024.

The main risk for users is targeted phishing: an email quoting your name, your date of birth and a real procedure is hard to tell from a legitimate message.

How do you test for an IDOR in practice?

The short answer: with two test accounts and an intercepting proxy. The protocol we apply:

1. List every endpoint that carries an identifier (path, query string, JSON body, header) and note the object it targets.
2. Create two accounts of the same level (A and B), then replay requests carrying B's identifiers using A's session. A 200 response with B's data is an IDOR.
3. Replay with a lower-privilege account against a more privileged account's resources to detect vertical escalation.
4. Test every method: a GET may be protected while PUT or DELETE are not.
5. Test indirect identifiers: case numbers, document references, file names in object storage.

Safety rule: count readable records, do not download real personal data, and stop as soon as the proof is made.

How do you fix an IDOR and keep it from coming back?

The fix is a server-side check on every access: does the requested object belong to the session's user, or does that user hold an explicit right to it? Centralize the check (middleware, per-resource policy, row-level security in the database) rather than repeating it in each route.

Unpredictable identifiers (UUIDs) make enumeration harder, but they complement the authorization check and do not replace it. Add automated two-account tests to your CI pipeline, rate limits on read endpoints, and alerts on sequential identifier walks. The OWASP IDOR prevention cheat sheet describes these measures.

What changes when an AI agent has access to this API?

An AI agent calling the API on the user's behalf turns a curiosity-level IDOR into an automated extraction tool. Three differences matter.

The agent's identity is not the user's. Many agents use a powerful service token, sometimes with no per-user restriction. If the API checks authorization only from the service token, the agent can read any account, and the user can ask it to. This is a confused deputy: the agent holds rights the user does not.

Identifiers flow through the model's context. The model sees identifiers returned by tools and can reuse them. An indirect prompt injection hidden in an email or a document the agent reads can tell it to call the API again with other identifiers and send the result out. See our page on prompt injection.

Speed changes the scale. An agent loops over thousands of identifiers without fatigue. A missing server-side check becomes exploitable in bulk, with a trace that looks like legitimate use of the service account.

The defenses are to carry the end user's identity down to the API (a delegated, narrowly scoped token instead of a general service token), enforce authorization object by object on the server, cap calls per agent session, and log every tool call with the requesting identity. This maps to LLM06 (Excessive Agency) in the OWASP Top 10 for LLM Applications. For more, see our page on AI agent security.

How can you check your own exposure?

Start with an inventory: which APIs accept identifiers, which are called by an agent, and with which token? Then run the two-account test on those endpoints, using the agent's token and the user's. Our Agent Red Team Express (EUR 1,900, 5 days) tests exactly this case: a real agent, its tools, its credentials and the authorization checks behind them, with reproducible evidence at the end.