Le 14 avril 2026, le ministère de l’Éducation nationale a confirmé une cyberattaque massive sur la plateforme ÉduConnect, survenue fin décembre 2025. Près de 3,5 millions d’élèves mineurs sont concernés selon les éléments rendus publics, avec plus de 7,2 millions de bulletins scolaires et 400 000 rapports ASSR2 exfiltrés. Au-delà de l’ampleur du préjudice, l’incident illustre une réalité qui dépasse largement le secteur éducatif : la faille IDOR qui a rendu l’attaque possible est l’une des vulnérabilités web les plus banales — et l’une des plus dévastatrices.
Ce qui s’est passé : une attaque en deux temps
Le scénario combine deux mécanismes classiques. D’abord, l’usurpation d’identité d’un compte habilité appartenant à un personnel administratif — probablement obtenue par phishing ou par compromission d’un mot de passe réutilisé. Ensuite, l’exploitation d’une faille technique de type IDOR identifiée en décembre 2025 mais corrigée trop tard.
L’attaquant a pu télécharger des données bien au-delà du périmètre de l’établissement initialement visé. Les informations exposées incluent les noms et prénoms, identifiants ÉduConnect, établissements et classes, adresses e-mail lorsqu’elles étaient renseignées, et codes d’activation pour les comptes non encore activés. Le ministère a réinitialisé l’ensemble des codes concernés et mis en place une double authentification.
IDOR : la faille qui devrait disparaître depuis 20 ans
IDOR signifie Insecure Direct Object Reference : référence directe non sécurisée à un objet. C’est une vulnérabilité applicative dans laquelle un identifiant de ressource (numéro de dossier, ID utilisateur, ID d’établissement) est exposé dans l’URL ou dans une requête, et le serveur ne vérifie pas que l’utilisateur connecté a bien le droit d’y accéder.
Concrètement, dans le cas d’ÉduConnect : il aurait suffi de modifier un numéro dans la barre d’adresse — passer de etablissement=12345 à etablissement=12346 — pour consulter les données d’un autre établissement, sans que le système ne bloque la requête.
Cette faille est référencée depuis 2007 dans le top 10 de l’OWASP, l’organisme de référence en sécurité applicative. Elle figure aujourd’hui dans la catégorie Broken Access Control, première cause de vulnérabilités web identifiée par l’OWASP. Sa persistance dans des systèmes de l’État en 2026 est révélatrice d’un problème structurel : le contrôle d’autorisation côté serveur reste un angle mort dans beaucoup de développements, y compris dans des projets à haute exposition.
Pourquoi le secteur éducatif est-il particulièrement exposé ?
L’attaque ÉduConnect n’est pas isolée. Sur le seul premier trimestre 2026, le secteur éducatif français a subi plusieurs incidents majeurs : l’application Compas (243 000 agents exposés en mars), AgroParisTech (cyberattaque par rançongiciel en janvier), le CROUS (774 000 étudiants), sans compter les incidents touchant les établissements du premier degré dans l’enseignement catholique.
Cette concentration s’explique par plusieurs facteurs structurels :
- Une centralisation maximale des données. ÉduConnect agrège les données de millions d’élèves sur une plateforme unique — la moindre faille devient catastrophique à l’échelle nationale.
- Des budgets IT contraints. Les établissements scolaires, comme beaucoup d’acteurs publics, peinent à financer une maintenance et une supervision de sécurité à la hauteur des enjeux.
- Une dette technique importante. Beaucoup d’applications métier ont été développées il y a dix ou quinze ans, et les contrôles d’autorisation n’ont pas toujours été repensés au fil des évolutions.
- Une surface d’attaque large. ENT, applications académiques, outils administratifs, plateformes de vie scolaire : chaque service est une porte d’entrée potentielle.
Que retenir pour les établissements et les DSI ?
Pour les établissements scolaires comme pour toute organisation manipulant des données sensibles, l’incident ÉduConnect rappelle quelques fondamentaux trop souvent négligés.
1. Activer la double authentification partout où c’est possible
L’attaque a commencé par l’usurpation d’un compte habilité. Une 2FA aurait considérablement compliqué la tâche de l’attaquant. Sur les comptes administratifs, à privilèges élevés, c’est désormais un minimum non négociable.
2. Auditer les contrôles d’autorisation des applications métier
Une faille IDOR ne se trouve pas avec un antivirus ni un pare-feu. Elle se détecte par un audit applicatif — automatisé (DAST, SAST) ou manuel (pentest). Les applications développées il y a plusieurs années sans test de sécurité régulier sont particulièrement à risque.
3. Cartographier ses données sensibles
Quelles données votre établissement stocke-t-il ? Où ? Qui y a accès ? Cette cartographie, exigée par le RGPD, reste lacunaire dans beaucoup de structures. Sans elle, impossible de prioriser correctement les efforts de sécurisation.
4. Préparer un plan de réponse à incident
Le ministère a mis trois mois à informer les familles concernées — un délai qui pose question au regard du RGPD, qui exige une notification sous 72h en cas de risque élevé. Avoir une procédure de réponse écrite, testée, et des contacts pré-identifiés (ANSSI, CNIL, prestataire de réponse à incident) fait la différence entre une crise gérée et une crise subie.
5. Sensibiliser les utilisateurs à privilèges
Personnels administratifs, enseignants référents, gestionnaires de comptes : ces profils sont les cibles prioritaires des attaquants. Une formation régulière au phishing et aux bonnes pratiques de mot de passe est aussi rentable qu’un investissement matériel.
Notre accompagnement
Chez AXALYS, nous accompagnons les établissements scolaires et les PME sur l’ensemble de ces sujets : audit de sécurité applicative, mise en place de la double authentification, supervision continue, sensibilisation des équipes et plans de réponse à incident. Contactez-nous pour faire le point sur votre exposition.
Crédit photo : Vitaly Gariev — Unsplash.
