An attacker logged in to France's tax administration systems using the stolen passwords of staff. They took tax data on hundreds of thousands of taxpayers and businesses across June and July. The reporting puts the time to discovery at seven weeks.

No exploit is named in the account. No CVE, no malware family, no zero-day. The credential was the vulnerability, and it worked as designed: a valid username and a valid password produced a valid session.

Bulk extraction over that period means the sessions did something staff sessions do not normally do, at a volume that has to register somewhere. Hundreds of thousands of taxpayer records leaving through legitimate accounts for weeks is a logging question before it is a phishing question. Either nothing alerted on it, or something did and nobody read it. The published account does not say which.

That is the part a bank should check against its own estate. Staff credentials on internal case-management and customer-data systems are the same class of asset. The relevant tests are short. Does a password alone open a session to bulk-export functions? Does anything fire when one account pulls records at a rate no clerk ever would?

(Seven weeks is long enough for the attacker to have taken a holiday, though the record does not suggest they did.)

The control that would have changed the outcome is phishing-resistant multi-factor authentication on staff accounts, such as hardware security keys, because a stolen password alone would then have opened nothing. The second is per-account volume alerting on record exports, which would have shortened seven weeks to days.