French Tax Data Theft via Stolen Staff Passwords: What Every Broker Should Check Today

TL;DR

• Stolen staff passwords let an attacker take French tax data on over 350,000 individuals and over 250,000 businesses across June and July.
• The theft went undetected for seven weeks because a password reset on one system did not end the attacker's open session on a second system.
• The security operations centre was not monitoring that second system at all.
• Accounts with no special privileges could still reach a large volume of sensitive data.
• ANSSI recommends revoking every active session across all connected applications whenever a password is reset.

This incident did not require a sophisticated attack. It required weak login protection, poorly separated systems, and gaps in monitoring.

What actually happened?

France's national cybersecurity agency, ANSSI, published a report on 29 September 2026 detailing how an attacker used stolen passwords belonging to staff at the DGFIP, France's tax administration, to access a tool called E-Contact. That tool is used by taxpayers to message the tax administration. The stolen data covers a little over 350,000 individuals and a little over 250,000 businesses.

The passwords were probably taken by infostealers, malware that quietly copies saved logins, from computers the DGFIP did not manage. Most likely those were staff's own personal devices. Two portals the attacker used asked only for a password, so a stolen one worked immediately.

The theft became known on 12 August, when the attacker claimed it on an online forum, seven weeks after the first batch of data was taken.

Why did the password reset fail to stop the breach?

This is the part every broker should read carefully.

On 23 June, a threat intelligence provider flagged a compromised account. The security operations centre opened a ticket at 8:50 p.m. Paris time. At 4:26 a.m. the next morning, the attacker began pulling data using automated scraping tools. The SOC handled the ticket at 10:40 a.m. by resetting the account's password.

The reset addressed the alert on the first portal. It did not terminate the attacker's open session on the second portal, ADER. Data kept flowing for almost 16 more hours, until 2:31 a.m. on 25 June.

The SOC was not monitoring ADER at all. No system linked the warning signs together: logins at night, connections from VPNs, connections from addresses in India, connections from addresses known to be malicious. Data volumes raised no alert, including 11 GB exchanged between 22 and 25 June. The number of requests each user made was not checked, even though scraping requires one request per page.

ANSSI's point is precise: on their own, such signals cause many false alarms, but together they could have raised an alert.

What does this mean for a broker's own systems?

A broker's CRM, document portal, and call recording platform are not a government tax system. But the structural failure here is not unique to government. It is a failure that can exist in any multi-application environment where staff log in from personal devices.

Consider the typical broker setup. Staff access a CRM, a document collection tool, a lender portal, and possibly a voice agent platform. Each may handle its own sessions independently. If a staff member's laptop is compromised by an infostealer and their credentials are used to open a session in one application, resetting the password on that application may not close sessions already open in connected tools.

For a broker, the data at risk includes tax returns, payslips, bank statements, identification documents, and the full loan application history of every client. That is a Privacy Act exposure, a potential AFCA complaint, and a reputational problem that does not resolve quickly.

The ANSSI report also notes that accounts with no special privileges could still reach a large volume of data. That is worth checking in your own CRM. Does a standard staff login have access to every client record, or only the records that staff member is actively working on?

The AI security risk is related. If your broker platform uses an AI agent that connects to your CRM or document store, that agent's credentials are another surface. We covered a similar credential exposure pattern in SalesBleed: What a Hidden Prompt in an Enquiry Form Did to Salesforce's AI Agent and in An OpenAI Agent Broke Into Australia's Medicare Portal. The common thread is that access controls designed for human staff do not automatically apply sensibly to automated processes.

Three checks a broker can run this week

Ask your platform vendor one question. When a staff password is reset, does that action terminate every active session on every connected application, or only the session that triggered the alert? If the vendor cannot answer clearly, treat that as a gap.

Review what a standard staff login can see. If a compromised account with no special privileges can export or view every client record in your CRM, that is a configuration choice you can change. Limit access to active files.

Check whether your monitoring covers all applications. The DGFIP's SOC was watching one portal and not the other. If your practice management software, document portal, and CRM each have their own logs, ask whether anyone is correlating those logs. Unusual request volumes, off-hours logins, and logins from new locations are signals that matter when read together.

For more on how credential theft intersects with AI deployments specifically, Anthropic's September 2026 Threat Report: What Broker AI Deployments Need to Know covers the credential abuse patterns ANSSI's findings echo.

The full ANSSI report is available via The Hacker News coverage published 29 September 2026.

FAQs

Does this incident affect Australian brokers directly?
No. The breach involved France's tax administration. But the failure modes, stolen staff credentials, incomplete session revocation, and unmonitored connected systems, are not specific to any country or industry. Any broker using cloud platforms where staff log in from personal devices faces a structurally similar risk.

What is an infostealer and how does it reach a broker's systems?
An infostealer is malware that copies saved usernames and passwords from a device, often without the user noticing. ANSSI assessed that the DGFIP passwords were probably taken from staff's personal devices. If a broker's staff member saves work credentials in a personal browser on a home computer, an infostealer on that computer can copy those credentials and pass them to an attacker.

What should a broker ask their CRM or document portal vendor about session management?
Ask whether resetting a user's password immediately terminates all active sessions for that user across every connected application. Ask whether the platform logs the number of records accessed per session and whether unusual volumes trigger an alert. If the vendor cannot answer both questions, escalate to their security team in writing.

Is this a Privacy Act issue for Australian brokers?
If a broker's client data were accessed through a similar credential compromise, the Australian Privacy Act 1988 and the Notifiable Data Breaches scheme would likely apply. Brokers holding tax returns, bank statements, and identification documents are handling sensitive personal information. A breach of that data requires assessment and, in most cases, notification to the OAIC and affected individuals.

Originally published at theautomate.io.