Entre juin et juillet 2026, des accès illégitimes au système d'information de la Direction générale des Finances publiques ont reposé sur l'usurpation des identifiants d'un agent de la DGFiP et d'un tiers habilité. Avant leur interruption, ces accès ont servi à consulter ou extraire des données concernant environ 678 000 particuliers et professionnels. Les espaces personnels sur impots.gouv.fr et les mots de passe des contribuables n'ont, eux, pas été compromis, selon le communiqué officiel du ministère de l'Économie et des Finances.
Le point le plus instructif n'est donc pas qu'un pirate aurait « cassé le site des impôts ». Les informations disponibles indiquent plutôt qu'il a utilisé des identifiants internes que le système pouvait reconnaître comme légitimes. Les comptes concernés ont bien été coupés après la détection des intrusions, mais les contrôles réalisés à ce moment-là n'ont pas identifié que des données avaient déjà été emportées.
En bref
- Confirmé : deux usurpations d'identifiants, des accès internes illégitimes, l'extraction ou la consultation de données et environ 678 000 particuliers et professionnels concernés.
- Non confirmé : la manière dont les identifiants ont été obtenus, le chemin réseau exact, un éventuel contournement du MFA et le niveau précis de privilèges atteint.
- Leçon de sécurité : authentifier une identité ne suffit pas. Il faut également limiter ce qu'elle peut faire, observer son comportement et pouvoir révoquer tous ses accès rapidement.
Que s'est-il exactement passé à la DGFiP ?
État des informations au 18 août 2026
Organisation concernée
Direction générale des Finances publiques (DGFiP)
Période des intrusions
Juin et juillet 2026
Accès initial confirmé
Usurpation des identifiants d'un agent de la DGFiP et d'un tiers habilité
Impact confirmé
Consultation ou extraction de données relatives à environ 678 000 particuliers et professionnels
Données citées officiellement
Revenu fiscal de référence, quotient familial, taux de prélèvement à la source, raison sociale, SIREN et certaines données cadastrales
Éléments non compromis selon la DGFiP
Espaces Finances publiques des usagers, identifiants et mots de passe des particuliers et professionnels
État de l'enquête
Investigations et enquête judiciaire en cours ; audit approfondi demandé à l'ANSSI
Le chiffre de 678 000 ne correspond pas à une fuite de mots de passe. Les données fiscales, familiales, professionnelles et immobilières exposées peuvent néanmoins rendre un hameçonnage ou un appel frauduleux beaucoup plus crédible. Les notifications ont commencé le 17 août pour un peu plus de 350 000 particuliers, selon l'AFP.
Notre lecture : le danger commence dès l'authentification
Notre lecture de l'attaque tient en une séquence très simple, même si tous ses détails ne sont pas encore confirmés par l'enquête : un identifiant. Un mot de passe. Un second facteur. Puis un VPN qui ouvre l'accès aux outils internes. Sur le papier, chaque étape semble sécurisée. Dans les faits, dès que le système reconnaît cette identité comme légitime, l'attaquant peut accéder à bien plus d'informations qu'un administrateur ne souhaiterait jamais exposer à un compte compromis. Le problème n'est donc pas seulement l'entrée : c'est la confiance et l'étendue des droits accordés après l'authentification.
La chronologie montre un écart entre couper l'accès et comprendre l'impact
- Juin et juillet 2026 : les accès illégitimes interviennent. Les comptes sont interrompus dès la détection, sans que le vol de données soit alors identifié.
- 12 et 13 août : un acteur malveillant revendique les accès et des investigations approfondies sont engagées.
- 14 août : le ministère confirme publiquement les deux intrusions, le recours à des identifiants usurpés et l'exposition d'environ 678 000 particuliers et professionnels.
- 17 août : les notifications individuelles commencent et le Premier ministre demande à l'ANSSI un audit approfondi afin d'établir les circonstances et les causes de l'incident.
- 18 août : le périmètre exact et la cause racine technique restent en cours d'investigation.
Cette chronologie illustre une différence essentielle : prouver qu'un accès a été révoqué ne prouve pas que rien n'a été extrait auparavant.
Ce que l'on sait sur le point d'entrée et ce que l'on ignore encore
L'administration confirme l'usurpation d'identifiants appartenant à un agent et à un tiers autorisé, sans préciser comment ils ont été obtenus. Hameçonnage, vol de secrets, compromission d'un poste ou détournement de session restent donc des hypothèses.
L'attaquant affirme avoir obtenu un accès à un VPN et à un outil interne de recherche. Cette version est rapportée par FrenchBreaches et Le Monde, mais n'est pas confirmée par Bercy.
Il n'est pas davantage établi qu'un second facteur d'authentification ait été contourné. La séquence « identifiant, mot de passe, second facteur, puis VPN » constitue donc, au 18 août, un scénario possible mais pas un fait démontré.
- Accès initial
Ce qui est établi : Des identifiants internes ont été usurpés
Ce qui reste inconnu : Méthode de compromission et éventuel vol de session
- Connexion au SI
Ce qui est établi : Des accès illégitimes ont eu lieu
Ce qui reste inconnu : Chemin réseau exact, rôle du VPN et état du MFA
- Action sur les données
Ce qui est établi : Des données ont été consultées ou extraites
Ce qui reste inconnu : Outil exact, automatisation et volume détaillé par type de donnée
- Détection et confinement
Ce qui est établi : Les comptes utilisés ont été interrompus
Ce qui reste inconnu : Temps d'exposition exact de chaque accès
- Élévation ou mouvement latéral
Ce qui est établi : Aucun élément public ne permet de les établir
Ce qui reste inconnu : Privilèges obtenus, systèmes traversés et mécanismes de persistance éventuels
Pourquoi une identité usurpée peut-elle passer pour un utilisateur légitime ?
Un système d'authentification vérifie d'abord si une personne ou une machine présente les éléments attendus. Si l'attaquant les possède ou détourne une session validée, la connexion peut paraître légitime alors que l'intention a changé.
Le MFA, surtout lorsqu'il résiste au phishing, relève fortement le coût d'une compromission. Il ne décide toutefois pas quelles données sont accessibles après la connexion et ne remplace ni le moindre privilège, ni la surveillance des usages, ni la limitation des exports.
Un VPN protège un canal et ouvre un périmètre réseau ; il ne constitue pas automatiquement une politique Zero Trust. Celle-ci doit continuer à vérifier le contexte, limiter chaque ressource et réévaluer les droits pendant la session. Ici, l'utilisation du VPN reste une revendication, pas une conclusion officielle.
Quels contrôles auraient pu réduire la probabilité ou l'impact ?
Aucune source publique ne permet d'affirmer qu'un produit unique aurait empêché cette attaque. En revanche, plusieurs contrôles auraient pu réduire certains scénarios de compromission, raccourcir le temps d'exposition ou limiter le volume accessible, à condition d'être correctement déployés.
Identité cryptographique et authentification passwordless résistante au phishing
Effet recherché : Réduire le risque de vol et de réutilisation d'un mot de passe ou d'un secret partagé
Limite à garder en tête : Ne protège pas seule contre un poste ou une session déjà compromis
Autorisation par ressource et moindre privilège
Effet recherché : Empêcher qu'une identité compromise accède automatiquement à tous les outils ou toutes les données
Limite à garder en tête : Dépend de la précision et de la couverture des politiques
Droits temporaires et contextualisés
Effet recherché : Limiter la durée et le périmètre des accès des agents, prestataires et tiers
Limite à garder en tête : Exige une intégration opérationnelle avec les applications
Détection des requêtes ou extractions anormales
Effet recherché : Repérer un volume inhabituel, un scraping ou des consultations incohérentes avec la mission de l'utilisateur
Limite à garder en tête : Nécessite des journaux applicatifs, des seuils et une supervision adaptés
Révocation coordonnée des comptes, sessions et droits
Effet recherché : Réduire le délai entre la détection et le confinement réel
Limite à garder en tête : Ne permet pas de récupérer des données déjà exfiltrées
Corrélation identité, terminal, ressource et action
Effet recherché : Reconstituer précisément ce qu'une identité a fait et accélérer l'évaluation de l'impact
Limite à garder en tête : Suppose une journalisation complète et une durée de conservation suffisante
Ce que Vaultys aurait pu changer sans prétendre avoir « empêché l'attaque »
VaultysID repose sur une identité vérifiable et une authentification sans mot de passe. Dans un scénario de vol ou de partage d'un secret, cette approche peut réduire l'exposition au phishing. La compromission initiale restant inconnue, on ne peut pas affirmer qu'elle aurait bloqué ces intrusions.
Découvrir VaultysID
VaultysHub gouverne ensuite les accès : visibilité, politiques de droits, moindre privilège, révocation et preuves d'audit. Correctement configuré, il aurait pu limiter les ressources accessibles, accélérer la révocation et réduire le rayon d'impact.
Découvrir VaultysHub
La sécurité d'un système d'information ne repose jamais sur une seule barrière. Le risque d'intrusion; et surtout son impact; diminue à mesure que l'organisation combine des couches complémentaires : identité décentralisée, authentification passwordless et multifacteur résistante au phishing, politiques Zero Trust, accès réseau de type ZTNA, moindre privilège, supervision continue et piste d'audit. Aucune couche n'est infaillible seule ; leur combinaison évite qu'une défaillance unique suffise à ouvrir tout le système d'information.
C'est précisément l'approche de Vaultys : réunir dans une même plateforme la gestion des identités et des accès, l'authentification cryptographique, la gouvernance Zero Trust, la révocation, le suivi des connexions et la génération de preuves d'audit, avec la possibilité d'exporter les journaux vers les outils SIEM existants. Vaultys simplifie ainsi le déploiement et le pilotage de ces protections, tout en restant complémentaire de la sécurité des postes, de la DLP et des contrôles applicatifs.
nous contacter
Huit vérifications à lancer après un incident de ce type
- Inventorier les comptes internes et tiers ayant accès aux données sensibles, avec un propriétaire métier identifié.
- Supprimer les identités partagées et distinguer salariés, prestataires, services et administrateurs.
- Tester la révocation de bout en bout des comptes, sessions, accès réseau, applications et jetons.
- Appliquer le moindre privilège aux outils de recherche, d'export et d'administration.
- Corréler les journaux d'identité, de terminal, de réseau et d'application pour déterminer les données réellement consultées.
- Alerter sur les comportements anormaux : volumes, consultations en série, horaires ou exports inhabituels.
- Limiter l'extraction par des quotas, une minimisation des données visibles et des contrôles applicatifs.
- Simuler une identité compromise pour mesurer le rayon d'impact et la vitesse réelle de confinement.
La vraie question : que peut encore ouvrir une seule identité volée ?
La cyberattaque de la DGFiP ne démontre pas que le MFA, le VPN ou une technologie précise ont échoué. Elle montre qu'une identité reconnue comme légitime peut devenir le véhicule d'une attaque et être coupée après le départ des données.
Le Zero Trust ne promet pas qu'aucune attaque n'arrivera. Il vise à empêcher qu'un seul accès compromis suffise à tout ouvrir, puis à rendre chaque action attribuable, observable et révocable.
Le point de départ est une cartographie concrète : quelles identités existent, quelles ressources peuvent-elles atteindre et combien de temps faut-il pour couper réellement tous leurs accès ? VaultysHub et VaultysID permettent ensuite de contrôler ces identités, de maîtriser leurs accès et de les révoquer rapidement lorsque cela devient nécessaire.