DGFiP Breach: Six Weeks to Disclosure, and the Count Is Still Unknown

Rows of labelled blue archive binders on a shelf, illustrating a report on stolen French tax records. Photo by Zulfugar Karimov on Pexels

PRIVACY & DATA · 15 Aug 2026 —

PARIS, 15 AUG 2026 — France's tax administration cut off an intruder in late June. Taxpayers learned about it on 14 August, two days after the attacker advertised their data on a criminal forum.

Six weeks separate the two events, and the second one did not happen until the first became impossible to keep quiet.

What happened, in order

Late Jun 2026
Access gained
Reportedly through stolen professional credentials, into a virtual private network and then an internal search tool.
Late Jun 2026
Access cut off
Detected and blocked during routine security checks. Data had already been extracted. No announcement was made.
12 Aug 2026
The attacker goes public
Someone using the name ZeroBytes advertises the database on a cybercrime forum and offers continued access for sale.
14 Aug 2026
The ministry confirms
The intrusion is verified publicly, six weeks after it was stopped. The ministry says it will report to the CNIL and notify affected taxpayers individually.

What was taken

Names, addresses, dates of birth, reference tax income, withholding tax rates, family situation, number of dependants, property-related details, internal tax identifiers, and records of past dealings with the administration.

Read that list as an attacker would. It is not a credential dump, and nothing in it can be rotated. A state-verified tax file says what you earn, where you live, who lives with you and what you own. That is the raw material for convincing impersonation, and its value lasts for years because none of it can be changed by the person it describes.

It is also close to ideal for targeting. An income figure and a home address, together, identify who is worth approaching in person.

Nobody can say how many

The figures in circulation do not agree, and the gaps are large.

Figure	Source
~678,000 records ≈393,000 individuals, ≈286,000 professionals	A breach-tracking platform; not confirmed by the ministry
600,000+	The attacker's own claim
Around 2 million	Appears in some accounts of the ministry's statement
Not yet determined	The ministry's own position

Six weeks after cutting off the access, the administration has verified that extraction occurred but has not established its scope. The real problem is not the conflicting numbers; it is that the administration's own logs cannot settle the question six weeks later. Knowing that a search tool was used is not the same as knowing what it returned.

One detail in the official account deserves more weight than it has received. The access was found during routine security checks — not by an alert. Something that ran on a schedule noticed it; nothing raised a hand while it was happening. An internal search tool being driven at volume against taxpayer records is close to the easiest anomaly there is to detect, and detecting it is considerably cheaper than reconstructing it afterwards.

The clock that actually applies

The six-week gap does not automatically mean a rule was broken, but the distinction is important. The familiar seventy-two-hour clock is for notifying the regulator, not the public.

A controller that becomes aware of a personal data breach must notify the supervisory authority without undue delay and, where feasible, within seventy-two hours, giving reasons if it is later. Telling the people affected is a separate duty, owed without undue delay when the breach is likely to result in a high risk to their rights and freedoms.

So the six weeks we can observe is the gap to public disclosure. The public record does not show whether the CNIL was told in late June. What it shows is the ministry saying on 14 August that it would report the incident — a future tense that leaves the question open.

If the regulator was notified in June while the scope was being determined, the sequence is defensible, even if the public communication was poor. If the regulator was not told until August, that is another matter. For now, both scenarios fit the public statements.

How the same incident would run here

Readers in this region operate under clocks that are, if anything, tighter — and unlike the European framework, several of them run to the regulator and the individual together.

Jurisdiction	To the regulator	To affected individuals
Singapore — PDPA	No later than 3 calendar days from assessing the breach is notifiable	As soon as practicable
Indonesia — PDP Law	3 × 24 hours from becoming aware	3 × 24 hours — same clock
Malaysia — PDPA	As soon as practicable, within 72 hours	Within 7 days of notifying the Commissioner
EU — GDPR	Within 72 hours where feasible	Without undue delay, if high risk

Singapore's clock starts only when an assessment concludes, not when the breach is first discovered. That is sensible, because an organisation cannot notify what it has not yet understood. It also creates the obvious failure mode, which is an assessment that never quite finishes.

Indonesia's is the strictest as drafted, because it collapses the two notifications into one deadline. An organisation there cannot use scoping as a reason to delay telling people, which is exactly the reason offered in France.

What a reader should actually do

If you file French tax returns, assume the data is out regardless of which count is right, and treat any contact referencing your tax affairs as hostile until proven otherwise. The specific risk is a caller who already knows your income, address and dependants — the details people use to decide a caller is genuine.

The lesson here is not just about tax data. Every organisation holds its own version of a tax file — some verified record, unchangeable by its subject, that stays valuable to an attacker for years. The control that failed here was not the perimeter, since credentials were used rather than defeated. It was the ability to say afterwards what an authenticated session had read. If your logs would not answer that question today, the six-week silence in Paris is a preview.

What we could not establish

How many people are affected. The ministry has not settled on a figure and the published numbers range from roughly 600,000 to around two million.

Several key questions remain. Was the CNIL notified within seventy-two hours of the June detection? When will individuals be told? Did the credentials belong to an employee or a contractor, and how was any multi-factor authentication bypassed? ZeroBytes also claims to retain access, which officials dispute. The account of the entry route comes from the attacker and has not been corroborated by the DGFiP.

What to watch

Whether the CNIL opens an investigation, and whether it says when it was told. That answers the only question that separates a communications failure from a compliance one.

Whether the final count lands nearer 678,000 or two million. A threefold uncertainty six weeks after the fact is itself a finding about the monitoring.

And whether the data appears in fraud campaigns. Tax files do not age out, so the absence of activity in August says very little about next year.

Priya Nair’s Verdict Privacy

The detail I keep returning to is not the six weeks. It is that six weeks after stopping the intruder, the administration still cannot say how many people were affected, and the public figures range from six hundred thousand to two million. A threefold uncertainty at this stage is not a communications problem. It means the logging could not reconstruct what an authenticated session had read, and that is the control failure underneath this incident. The perimeter was not defeated; credentials were used. What was missing was the ability to answer, afterwards, what those credentials had touched. I want to be careful about the legal accusation, because the obvious one is slightly wrong. The seventy-two-hour clock everyone cites runs to the supervisory authority, not to the public, and telling individuals is a separate duty triggered by high risk. So the six weeks we can see is the gap to public disclosure, and whether the CNIL was told in June is genuinely not answerable from what has been published. The ministry's future-tense promise on 14 August to report the incident invites the question without settling it. If the regulator was told in June, this is bad communications; if it was not, it is something else. I am not going to assert which. On the data itself: this is a tax file, so nothing in it can be rotated. An income figure with a verified home address and a count of dependants is the exact combination that makes an impersonation call sound legitimate, and it stays valid for years. For readers here the comparison is instructive rather than smug. Our clocks are tighter — Indonesia's three-times-twenty-four hours covers the regulator and the individual on the same deadline, which forecloses precisely the excuse offered in Paris. But Singapore's clock starts when the assessment concludes, and an assessment that never quite finishes is how a tight rule produces a slow disclosure. Ask your own team one question this week: if a valid credential were used against your systems today, could you say afterwards what it read? If the answer is no, the rest of this story is available to you too.

Sources & cross-checks

Primary: Brussels Signal — for the record count of about 678,000 (roughly 393,000 individuals and 286,000 professionals) attributed to a breach-tracking platform and not confirmed by the ministry; the data categories including names, addresses, dates of birth, reference tax income, withholding rates, family situation, dependants, property details and internal identifiers; the attacker's account that entry came via stolen professional credentials, a VPN and an internal search tool; the ministry's confirmation that the intrusion enabled consultation and extraction of taxpayer information; and its commitment to report to the CNIL and notify each affected taxpayer individually with no timetable given.
Also primary: The Record and The Register — for the intrusion and its detection both falling in late June 2026, the criminal-forum claim on 12 August and official confirmation on 14 August, the alias ZeroBytes, the attacker's claim to retain access being disputed by officials, and the differing counts in circulation.
The legal clocks: GDPR Article 33 for the 72-hour notification to the supervisory authority with reasons required if later, and Article 34 for notifying individuals without undue delay where there is high risk. Regional comparisons: Singapore's PDPA (3 calendar days to the PDPC from completing the assessment that a breach is notifiable), Indonesia's PDP Law (3 × 24 hours to both the regulator and data subjects), and Malaysia's PDPA (72 hours to the Commissioner, 7 days to affected individuals thereafter).
What could not be established: ⚠ How many people are affected — figures range from roughly 600,000 to two million and the ministry has not settled on one. Also unestablished: whether the CNIL was notified within 72 hours of the June detection, when individual notifications will be sent, whose credentials were used, how any multi-factor authentication was bypassed, and whether access is retained. The entry route is the attacker's account and has not been corroborated by the DGFiP.
Method and limits: Compiled 15 August 2026. The distinction between the Article 33 clock to the regulator and the Article 34 duty to individuals, the reading that a threefold uncertainty in the count points at a logging failure rather than a disclosure one, the observation that Singapore's clock starts at the end of the assessment, and the point that a tax record cannot be rotated by its subject are RECATOOLS analysis rather than claims by any authority.

Priya Nair

Data, AI Governance & Policy Analyst

Priya Nair covers AI governance, data protection, privacy, and digital trust topics for RECATOOLS.

View author profile → · Editorial policy

About this byline Priya Nair is a RECATOOLS editorial persona for AI governance, privacy, and digital trust coverage. Articles are produced and reviewed under RECATOOLS editorial supervision.

Corrections policy