No exploit, no malware: a valid login opened a national registry

Event dated 15 February 2026 · Published 2 September 2026 · 3 sources

France's finance ministry disclosed that somebody used stolen credentials to reach the national bank account registry, exposing data tied to roughly 1.2 million accounts. There was no exploit, no malicious code and no anomalous protocol behaviour: the access was an ordinary successful login followed by ordinary queries. Every control designed to recognise an attack had nothing to recognise, which is what distinguishes this class of incident from the ones that carry a CVE number — and why the defence is phishing-resistant authentication rather than faster patching.

January produced three findings with severity scores and patch deadlines. This one has neither, and it reached a more consequential system than any of them: a central registry of who holds which bank account, which is precisely the sort of index that makes every subsequent fraud easier.

What happened, as far as the public accounts establish, is that credentials belonging to somebody authorised were used by somebody not authorised. That sentence contains the entire technical description. There is no second half about a vulnerability, because there was not one.

Why this defeats most of the stack

Security tooling is largely built to distinguish the anomalous from the normal. An exploit is malformed input. Malware is unfamiliar code. Lateral movement is a pattern of connections that a workstation does not usually make. All of it is recognisable because it differs from what should be happening.

A valid credential produces none of those differences. The session is well formed, the queries are the queries the account exists to make, and the volume is whatever the attacker chooses it to be. The only signal available is contextual — this account does not normally sign in from there, at that hour, and does not usually read that much — and that signal requires knowing what normal looks like for each account, which is a substantially harder thing to build than a rule that matches bad input.

Where the credential came from matters less than it seems

Public accounts say stolen, without establishing how. It could have been phishing, an infostealer on a personal machine, reuse of a password exposed elsewhere, or a credential left in a repository. The response is the same in every case, which is the useful thing to notice: making the credential insufficient on its own.

A password that works from anywhere, presented by anyone who has it, is a bearer token for a national registry. Binding authentication to something that cannot be handed over — a key held in hardware, checked against the site that is actually being visited — removes the entire category, whichever route the password took to get out.

The registry problem underneath

There is a second question that the authentication answer does not address. A registry exists to be queried, and its value to a legitimate user and to an attacker is the same value: the ability to look up many people quickly. Strong authentication decides who gets in. It does not decide how much one authorised session should be able to read.

That is a rate and volume question, and it is the one control on this page that would have limited the damage rather than preventing the entry. An account that can look up ten records a day and an account that can enumerate the register are the same account until somebody decides otherwise, and in most systems nobody has.