ANTS / France Titres 2026: a basic IDOR flaw exposes 11.7 million accounts

> In short: On April 15, 2026, France's national secure titles agency (ANTS) detected unauthorized access on its ants.gouv.fr portal, which handles vehicle registration, driving licence and national ID card procedures. The cause: a textbook Insecure Direct Object Reference (IDOR) flaw, exploitable by simply changing an identifier in a URL or API request, with no advanced intrusion technique required. Official tally: 11.7 million accounts exposed; the attacker claims up to 19 million. France's Interior Ministry, the CNIL, ANSSI (national cybersecurity agency), and the OFAC anti-cybercrime unit were all notified.

An IDOR: the simplest vulnerability to understand — and yet

An IDOR happens when a resource (an account, a file, a record) is referenced by a direct, predictable identifier in a URL or API call, without verifying that the authenticated user actually has the right to access *that specific* resource. Concretely: if your account is number 4,512,890 and the API responds just as happily to /api/accounts/4512889 as to /api/accounts/4512890, any logged-in user can walk through the entire database simply by incrementing the identifier.

That's exactly what happened on ants.gouv.fr: by changing an identifier in a request, an attacker could view other accounts' data with zero server-side authorization check. No zero-day, no sophisticated exploit — a missing check, the kind of if (account.id !== session.user.id) return 403 that was either never written or was bypassed on one specific endpoint.

What was exposed (and what wasn't)

For individuals: login credentials, title, first and last names, email address, date of birth, and unique account ID, plus in some cases postal address, place of birth, and phone number. For businesses: company name, SIREN number, and licence/authorization numbers.

Attachments (photos, supporting documents) and biometric data were reportedly not compromised — an important nuance that limits, without eliminating, the risk of full identity theft. The main risk is highly credible targeted phishing: an email claiming to come from ANTS, personalized with a user's real name, date of birth, and procedure history, is nearly impossible to distinguish from a legitimate communication.

The number that raises questions: 11.7 million vs. 19 million

The gap between the official figure (11.7 million accounts) and the attacker's claim (18-19 million records) illustrates a common pattern after this type of incident: the victim organization communicates what it can technically confirm (identified access logs), while the attacker's own count may include duplicates, failed attempts, or extrapolations. Either way, the order of magnitude — tens of millions of French residents potentially affected on a near-mandatory service for registering a vehicle or renewing an ID card — makes this one of the largest breaches of the year in France.

How an audit catches an IDOR before it gets exploited

IDORs are one of the categories we find most often during our audits, and one of the simplest to fix once identified — which makes their presence in production all the more avoidable:

What organizations exposed to this pattern should do

If your service exposes an API consumed by a web or mobile app — which covers nearly every HR, payroll, and recruiting SaaS — the question to ask isn't "do we have strong authentication" but "does every API call verify, for *this specific* resource, that the current user is entitled to it." These are two different controls, and only the second one prevents an IDOR. A real-conditions audit with several test accounts at different privilege levels remains the most reliable way to catch this kind of vulnerability before an external attacker does it for you.