France's tax agency breach: found in June, disclosed in August

France's tax authority found the intruder in late June. The public found out on August 14. In between, an account calling itself ZeroBytes posted the data for sale, and only then did the Directorate General of Public Finances confirm the tax agency data breach that had already been closed six weeks earlier. If you want a clean picture of how disclosure actually works when nobody is forcing the clock, this is it.

What actually happened

Per The Record, DGFiP confirmed an attacker gained unauthorized access in late June by stealing or misusing someone's identity, and that the access allowed the attacker "to view and extract data belonging to individuals and businesses." Officials detected and terminated the access later that same month, during routine security checks.

The Register reports the entry path as stolen credentials paired with an MFA bypass — the attacker did not break the login, they wore it. ZeroBytes also claimed to still hold administrative access and offered to sell it; DGFiP disputes that, saying the access was severed at the end of June and new restrictions are in place.

The volume is unsettled, and worth being precise about. ZeroBytes claimed more than 600,000 people in the forum post The Record saw, and a larger figure elsewhere. The French finance ministry has confirmed the extraction but not a number: it says further probes are underway "to determine which specific data and the exact number of taxpayers affected." Treat every circulating count as the attacker's marketing until the regulator publishes one. Affected users will be individually notified, and the CNIL will be told.

Note the word businesses. Professional taxpayer records were in scope, not just personal ones.

Why breach disclosure timing matters for your business

The audit that finds the intrusion does not start the disclosure clock — someone else's forum post does. DGFiP did the hard part in June. What it did not do in June was tell anyone. That gap is where your customers form their opinion of you, and you don't control when it closes, because the attacker does.

Your controls assume the login is the boundary. It isn't. Stolen credentials plus an MFA bypass is the ordinary shape of a 2026 intrusion. MFA is table stakes, not a perimeter. What actually limits blast radius is what a valid session is allowed to do: query scoping, export limits, and an alert when an authenticated account starts reading records at a rate no human works at. Nobody bypasses an export cap by having the right password.

"We can't confirm the number yet" is an inventory problem. DGFiP is six weeks past detection and still counting. If your systems can't answer which rows did this session read from logs, you'll be in the same position — and the only number in circulation will be the one the attacker made up. Log reads on sensitive tables, not just writes.

We build the boring version of this: scoped service accounts, per-session query logging, and rate limits on anything that can export a customer list. It's cheap before an incident and unbuyable during one.

Sources: The Record, The Register, Reuters via The Star.