L’année 2025 a été marquée par une recrudescence de failles de sécurité critiques touchant tous les niveaux du système d’information. Du front-end aux infrastructures cloud, en passant par les outils DevOps, aucune couche n’a été épargnée. Ces vulnérabilités – souvent notées d’un score CVSS supérieur à 7 (gravité élevée à critique) – ont permis des attaques retentissantes : vols de données sensibles, déploiements de ransomwares, compromission de chaînes CI/CD, etc. Pour les développeurs frontend, backend, les ingénieurs DevOps et même les CTO, le constat est alarmant : la surface d’attaque s’élargit et l’adversaire exploite la moindre faille en un temps record.
Un panorama inquiétant. En 2025, plus d’un tiers des failles publiées présentaient une sévérité élevée ou critique, un record absolu. Surtout, ce ne sont plus seulement les systèmes vieillissants qui sont ciblés : des technologies modernes et très répandues ont révélé des faiblesses insoupçonnées. De React à Kubernetes, en passant par des appliances réseau et des outils d’entreprise, la diversité des failles découvertes montre que chaque composant technologique peut devenir la porte d’entrée d’une cyberattaque majeure. Pour la communauté DevOps, cela signifie qu’il faut redoubler de vigilance à chaque étape : développement sécurisé, déploiement rapide des correctifs, et mise en place de défenses en profondeur.
Dans cet article, nous revenons sur les failles critiques les plus marquantes de 2025, en analysant comment elles peuvent être exploitées, quelles mesures correctives ont été déployées et comment éviter que de tels problèmes ne se reproduisent. L’objectif est d’en tirer des enseignements concrets pour renforcer vos pratiques DevOps et de développement logiciel.
React2Shell : exécution de code à distance via React Server Components
Une des premières failles à avoir défrayé la chronique fin 2025 est React2Shell, une vulnérabilité critique (CVSS 10.0) affectant React 19 et ses frameworks associés comme Next.js. Cette faille, discrète mais redoutable, se nichait au cœur des React Server Components (RSC) – une fonctionnalité récente permettant de rendre des composants côté serveur.
Exploitation : Concrètement, un attaquant non authentifié pouvait envoyer une requête HTTP spécialement conçue vers une application utilisant React 19/RSC (notamment une application Next.js) et parvenir à exécuter du code arbitraire sur le serveur. Le problème provenait d’un défaut de désérialisation dans le protocole interne « Flight » de RSC. En forgant une charge malveillante ayant une structure inattendue, l’attaquant trompait le mécanisme de rendu de React, qui finissait par exécuter du code JavaScript injecté. Ce scénario d’exploitation était d’autant plus critique qu’il ne nécessitait aucune authentification ni prérequis particulier – une simple requête web malveillante suffisait. De plus, de nombreuses applications étaient vulnérables par effet de bord : il suffisait d’utiliser un framework populaire (Next.js, Remix, etc.) intégrant RSC pour être exposé, même sans l’avoir activé explicitement.
Impact : Une fois la faille exploitée, l’attaquant obtenait les mêmes privilèges que l’application serveur. Cela signifie la possibilité de voler des données sensibles (contenu de la base de données, secrets d’API…), de défigurer le site web, d’installer une porte dérobée ou de pivoter vers d’autres systèmes de l’entreprise. En fin d’année, des rapports ont révélé que plusieurs groupes avancés (y compris des acteurs étatiques) ont activement exploité React2Shell pour compromettre des serveurs à travers le monde. L’incident a été tel que même des acteurs majeurs de l’infrastructure web ont dû réagir en urgence : par exemple, Cloudflare a publié des règles WAF spécifiques pour bloquer ces requêtes malveillantes, et a subi quelques perturbations en déployant ces contre-mesures en catastrophe.
Correctifs : L’équipe React a réagi rapidement en publiant un patch dès début décembre 2025. La mise à jour de React (et des frameworks comme Next.js) vers les versions corrigées est le seul moyen fiable d’éliminer la vulnérabilité. Dans l’urgence, certaines applications ont temporairement désactivé les RSC ou mis en place des filtres WAF pour détecter les patterns d’attaque connus. Toutefois, ces mesures de mitigation ne sont pas infaillibles sur le long terme. La seule vraie solution est de mettre à jour les dépendances front-end concernées. Pour les équipes de développement, cela a impliqué de redéployer rapidement leurs applications avec la nouvelle version de React/Next.js, en s’assurant bien sûr que rien ne casse suite à la mise à jour.
Prévention futur : Que faire pour éviter ce genre de problème à l’avenir ? Cette faille souligne que même les outils front-end modernes peuvent introduire des risques côté serveur. Premièrement, il est crucial d’intégrer la veille de sécurité dans le cycle DevOps : surveillez de près les bulletins des frameworks que vous utilisez et intégrez des scans de vulnérabilités des dépendances dans vos pipelines CI/CD. Deuxièmement, en cas d’annonce d’une faille critique, mobilisez toutes les parties prenantes – développeurs front et back, équipe Ops – pour appliquer le correctif sans délai. Enfin, encouragez la culture de la sécurité dès le développement : comprendre les mécanismes internes de frameworks comme React (par exemple via une formation dédiée à React/Next.js) peut aider à anticiper les comportements à risque et à écrire du code plus robuste face à des entrées non maîtrisées. Cette collaboration renforcée entre dev front, dev back et DevOps est essentielle pour réduire la fenêtre d’exposition entre la découverte d’une faille et son correctif effectif en production.
FortiWeb : contournement d’authentification par traversée de chemin
En octobre 2025, c’est du côté des appliances de sécurité réseau qu’une alerte majeure a retenti. FortiWeb, le pare-feu d’applications web (WAF) de Fortinet, s’est avéré vulnérable à une faille critique (CVE-2025-64446, CVSS 9.8) permettant à un attaquant non authentifié de contourner totalement l’authentification administrateur. Cette vulnérabilité a mis en lumière qu’un outil censé protéger vos applications web pouvait devenir la cible entraînant leur compromission.
Exploitation : L’attaque exploitait une faiblesse dans l’interface d’administration de FortiWeb. En envoyant des requêtes HTTP POST spécialement forgées vers l’URL du panneau admin, l’attaquant pouvait tirer parti d’une traversée de répertoires (path traversal) pour atteindre un script CGI interne non prévu pour être exposé. Ce script, en temps normal, traitait certaines actions d’administration en supposant (à tort) qu’il était invoqué par un utilisateur déjà authentifié. En abusant de chemins encodés mal vérifiés, l’attaquant parvenait à appeler ce script et à lui faire croire qu’il disposait d’une identité valide. Conséquence : le pirate pouvait alors exécuter des actions d’administration sans login ni mot de passe – par exemple, créer un nouvel utilisateur admin avec un mot de passe connu de lui. En quelques requêtes, le système de sécurité se retrouvait sous le contrôle complet de l’attaquant.
Impact : La compromission d’un WAF comme FortiWeb est extrêmement grave. Une fois administrateur de l’appliance, l’attaquant peut désactiver les protections, modifier les règles pour laisser passer des attaques web auparavant bloquées, ou encore exploiter l’appareil comme point d’ancrage dans le réseau interne. En effet, ces appliances sont souvent déployées en frontière de réseau : en prenant le contrôle de FortiWeb, un pirate peut potentiellement écouter le trafic des applications derrière (pour y dérober des données) ou rebondir vers d’autres systèmes internes non exposés initialement. De plus, comme l’attaque ne nécessite aucune crédential, elle peut être automatisée à grande échelle : des honeypots ont observé des balayages massifs d’Internet à la recherche de FortiWeb vulnérables dès la révélation de la faille, indiquant que des botnets se sont rapidement mis en chasse.
Correctifs : Fortinet a publié en urgence un correctif logiciel début octobre 2025, accompagné d’un avis de sécurité appelant les clients à mettre à jour avant le 21 novembre 2025 (deadline imposée notamment aux agences gouvernementales via le catalogue CISA). Il est impératif d’appliquer ce patch firmware sur tous les équipements FortiWeb déployés. En attendant la mise à jour, la mesure la plus efficace pour limiter le risque était de restreindre drastiquement l’accès à l’interface d’administration : idéalement, la rendre accessible uniquement depuis un réseau de management isolé, non joignable depuis Internet. Fortinet a également recommandé de vérifier les logs système pour détecter toute création d’utilisateur suspecte ou action administrative non reconnue – signe d’une éventuelle exploitation antérieure au patch.
Prévention futur : Cette affaire rappelle plusieurs bonnes pratiques essentielles. Premièrement, ne jamais exposer une console d’administration sur Internet si ce n’est pas strictement nécessaire. Les interfaces web des routeurs, pare-feux, WAF et autres appliances doivent être placées derrière un VPN ou au moins filtrées par adresse IP. Cela aurait empêché (ou fortement compliqué) l’exploitation directe de cette faille. Deuxièmement, intégrer les équipements d’infrastructure dans votre cycle de patch management DevOps : trop souvent, on met à jour les serveurs et applications, en oubliant les “boîtes noires” réseau. Ici, un correctif était disponible rapidement – encore faut-il l’installer à temps sur chaque appliance. Troisièmement, surveiller les comptes et configurations de vos systèmes de sécurité : la création inattendue d’un administrateur FortiWeb aurait dû être un drapeau rouge immédiat. Une supervision centralisée des événements (via un SIEM par exemple) peut permettre de détecter ce genre d’anomalie et réagir avant que l’attaquant n’exploite pleinement son accès. Enfin, d’un point de vue plus stratégique, cette faille illustre que la sécurité périmétrique seule ne suffit pas : même vos remparts peuvent tomber. Il faut donc adopter une posture Zero Trust en interne, où chaque composant compromis n’ouvre pas grand la porte aux autres – cloisonnez vos réseaux, segmentez les accès, y compris ceux passant par vos WAF et VPN.
Oracle E-Business Suite : RCE et contournement d’authentification en chaîne
Les systèmes d’entreprise n’ont pas été épargnés en 2025. Oracle E-Business Suite (EBS), la célèbre suite ERP/CRM utilisée par de grandes organisations, a souffert de plusieurs failles critiques exploitées en tandem par des cybercriminels. Deux vulnérabilités en particulier ont fait l’objet d’une exploitation active : une exécution de code à distance (RCE) dans le module Oracle BI Publisher (CVE-2025-61882, CVSS 9.8) et un contournement d’authentification via l’endpoint “UiServlet” d’EBS (CVE-2025-61884, CVSS 7.5). Bien que distinctes, ces deux failles ont souvent été utilisées l’une après l’autre dans des attaques ciblant les serveurs Oracle EBS.
Exploitation : Dans la pratique, les assaillants – notamment le groupe de ransomware Cl0p – ont mené de véritables campagnes d’extorsion en exploitant ces brèches. D’abord, le contournement d’authentification permettait d’accéder aux modules web d’EBS sans avoir besoin de compte valide. Cette porte dérobée ouvrait la voie à l’exploitation de la RCE sur BI Publisher, un composant de génération de rapports. En combinant les deux faiblesses, un attaquant pouvait dès son premier contact avec le serveur Oracle EBS exécuter du code arbitraire avec les privilèges de l’application. En clair, la base de données ERP et toutes les informations sensibles qu’elle contient (comptabilité, ressources humaines, données clients…) devenaient accessibles. Les attaquants ont su tirer parti de cette situation : après avoir obtenu un accès, ils réalisaient une reconnaissance interne (énumération des systèmes connectés, des configurations Oracle, etc.), exfiltraient des lots de données critiques, puis lançaient leur attaque finale – souvent un chiffrement de l’ensemble des données pour rançonner l’entreprise, ou la menace de divulguer publiquement les informations volées.
Impact : L’impact pour les entreprises touchées a été dévastateur. Oracle EBS étant souvent le cœur névralgique des opérations d’une entreprise, sa compromission signifie une paralysie quasi totale de l’activité (plus de facturation, plus de gestion des stocks ou des paies…) et un risque de fuites de données stratégiques. Plusieurs incidents publics en 2025 ont mis en lumière ces conséquences : des groupes internationaux ont dû interrompre leurs opérations pendant plusieurs jours, le temps d’éradiquer les intrus et de restaurer/patcher les systèmes Oracle. Financièrement et en termes d’image, le coût a été très élevé. Pour un CTO, une telle faille sur un ERP combine le pire de deux mondes : un risque opérationnel majeur et un risque de sécurité. Sans compter les possibles obligations réglementaires (notification aux autorités en cas de données personnelles compromises, etc.).
Correctifs : Oracle a publié des correctifs dans le cadre de son Critical Patch Update (CPU) de juillet 2025, colmatant ces brèches. Il était impératif pour les administrateurs d’EBS d’appliquer ces patches immédiatement. En pratique cependant, de nombreuses instances restaient vulnérables plusieurs semaines après la disponibilité des correctifs – ce délai entre le patch et son déploiement a été exploité sans pitié par Cl0p et consorts. Oracle a également communiqué sur des mesures de mitigation temporaires : par exemple, désactiver ou restreindre l’accès réseau à l’interface BI Publisher et à l’UiServlet tant que le patch n’est pas appliqué, afin de réduire la fenêtre d’attaque. Par ailleurs, les entreprises victimes ont dû suivre un processus de réponse à incident rigoureux : analyser les logs Oracle pour comprendre quelles données ont pu être consultées ou exfiltrées, réinitialiser tous les mots de passe et certificats associés à l’application (au cas où l’attaquant aurait implanté des portes dérobées), et dans certains cas reconstruire entièrement des serveurs compromis pour repartir sur une base saine.
Prévention futur : Que peut-on apprendre de ces attaques sur Oracle EBS ? D’abord, ne jamais sous-estimer l’attrait des systèmes métiers pour les attaquants. On pense souvent aux failles systèmes ou aux applications web exposées, mais un ERP est une cible tout aussi lucrative, voire plus. Ainsi, première priorité : inclure vos applications d’entreprise critiques dans le plan de gestion des vulnérabilités. Cela signifie appliquer scrupuleusement chaque mise à jour de sécurité dès sa sortie, malgré les contraintes de testing que cela implique sur des systèmes aussi complexes. Deuxième point, l’architecture : idéalement, un ERP ne devrait pas être directement exposé à Internet. Dans la mesure du possible, l’accès aux modules Oracle EBS devrait passer par un VPN ou une passerelle applicative sécurisée, limitant les possibilités pour un attaquant externe. Dans les cas où une exposition est requise (par exemple pour des accès partenaires ou télétravail), mettre en place une authentification forte, des filtres IP et un WAF en amont peut ajouter des couches de défense. Troisièmement, en interne, segmentez les droits : un contournement d’authentification est moins grave si, une fois dedans, l’attaquant tombe sur un compte à permissions limitées. Dans Oracle EBS, assurez-vous que les comptes par défaut ou génériques sont désactivés ou fortement restreints, pour compliquer la tâche au pirate. Enfin, entraînez-vous à l’exercice du pire : un plan de reprise d’activité et des sauvegardes hors-ligne à jour peuvent sauver votre entreprise si malgré tout un ransomware se déclenche sur l’ERP. Dans ces moments, chaque heure compte pour restaurer les fonctions vitales – et les équipes DevOps ainsi que les développeurs backend doivent être prêts à collaborer avec les équipes IT pour remettre sur pied les systèmes le plus rapidement et sûrement possible.
Azure DevOps Server : élévation de privilèges critique dans la chaîne CI/CD
La sphère DevOps a également eu son lot de sueurs froides en 2025. En mai, Microsoft a révélé et corrigé une vulnérabilité d’élévation de privilèges critique (CVE-2025-29813, CVSS 10.0) affectant Azure DevOps Server. Azure DevOps Server, l’outil de gestion de code source et de pipelines CI/CD déployé on-premise (anciennement connu sous TFS ou Azure DevOps self-hosted), présentait une faille permettant à un attaquant non authentifié d’obtenir des privilèges administrateur sur le serveur DevOps, simplement via le réseau. En clair, un individu mal intentionné pouvant atteindre l’URL du service pouvait potentiellement prendre le contrôle complet de l’infrastructure DevOps de l’entreprise.
Exploitation : Les détails techniques précis n’ont pas tous été rendus publics, mais on sait qu’il s’agissait d’une faiblesse dans les mécanismes d’authentification/autorisation d’Azure DevOps Server. Un attaquant distant, sans compte préalable, pouvait envoyer une requête spécialement construite pour se faire passer pour un utilisateur légitime ou obtenir des droits plus élevés qu’il ne devrait. Par exemple, il est possible que la faille ait permis de bypasser l’authentification sur l’API web ou d’injecter une charge malveillante dans un processus de communication interne, aboutissant à la création d’un compte administrateur ou à l’obtention de tokens d’accès privilégiés. Ce qui est certain, c’est qu’avec un score CVSS de 10, l’exploitation était jugée trivialement exploitable et aux conséquences extrêmes. Imaginez un instant : l’attaquant réussit à devenir admin de votre plateforme DevOps – il a alors accès à tous vos dépôts de code source (y compris potentiellement des secrets stockés dans le code ou la config), à vos pipelines d’intégration continue (qu’il pourrait modifier pour injecter du code malveillant dans vos builds), et aux agents de build et de déploiement liés au serveur (ouvrant la porte vers vos serveurs de prod). C’est littéralement le scénario cauchemar du supply chain attack : compromettre l’outil de développement pour propager l’attaque sur tous les logiciels produits par l’organisation.
Impact : Heureusement, aucune exploitation active à grande échelle n’a été confirmée au moment de l’annonce – Microsoft a découvert la faille en interne ou via un chercheur et a sorti un patch avant que des dégâts ne soient reportés. Néanmoins, la simple existence de cette faille signifie que toutes les instances on-premise d’Azure DevOps Server non patchées étaient des bombes à retardement. Pour les entreprises qui en dépendent, c’était la possibilité d’un effondrement de la confiance logicielle : comment garantir que vos applications déployées ne sont pas vérolées si votre serveur CI/CD a été compromis ? Au-delà du code, pensez aux packages et artefacts stockés, aux clés d’accès à d’autres services (que l’on configure souvent dans les pipelines), et même aux tickets/projets suivis dans l’outil – un intrus aurait pu les lire ou les modifier à sa guise. On peut dire sans exagérer que la compromission d’un serveur DevOps a des impacts en cascade sur l’ensemble du cycle de vie logiciel, et met en péril tant la sécurité de l’infrastructure (par ex. déploiement d’un malware en production via une release pipeline) que la propriété intellectuelle de l’entreprise (vol du code source propriétaire, etc.).
Correctifs : Microsoft a intégré le correctif dans les mises à jour de sécurité de mai 2025. Les clients utilisant Azure DevOps Server devaient installer ce correctif immédiatement. Microsoft a souligné qu’Azure DevOps Services (la version cloud hébergée par Microsoft) avait déjà été mise à jour côté serveur – les utilisateurs de la version cloud n’avaient donc aucune action à mener, la plateforme ayant été sécurisée en amont. Cela illustre d’ailleurs l’un des avantages (et inconvénients) du cloud : on délègue la gestion des patchs à l’éditeur. En l’occurrence, les organisations sur la version SaaS d’Azure DevOps n’ont pas été exposées, alors que celles sur la version on-premise devaient agir par elles-mêmes. Outre l’application du patch, il est conseillé aux admins d’Azure DevOps Server d’examiner les journaux d’accès à la période précédent le patch : toute connexion suspecte, création de compte inattendue ou modification non approuvée pourrait indiquer qu’un attaquant a déjà exploité la faille avant la correction (même si aucun cas massif n’est connu publiquement, la prudence s’impose). En cas de doute, il faut révoquer les tokens d’accès, changer les mots de passe de service, et réinitialiser les pipelines sensibles pour s’assurer qu’aucune commande malveillante n’y a été insérée furtivement.
Prévention futur : Cette vulnérabilité critique appelle les équipes DevOps à élever encore le niveau de sécurité autour de leurs outils de CI/CD. Premièrement, traitez votre serveur d’intégration continue comme une infrastructure critique. Cela implique de le segmenter sur le réseau (il ne devrait être accessible que par les collaborateurs autorisés, pas exposé sur internet sans VPN), de limiter les droits des comptes de service qu’il utilise (un compte compromise ne doit pas forcément donner accès à tout), et d’activer une authentification multi-facteur pour les utilisateurs administratifs. Deuxièmement, incluez-le dans vos exercices de pentest et d’audit. Bien souvent on audite les applications déployées, mais pas l’usine logicielle – or c’est une cible de choix. Des audits réguliers de la configuration (vérifier qu’aucun projet public non désiré n’est créé, que les permissions suivent le principe du moindre privilège, etc.) et des scans de vulnérabilités de l’outil lui-même (ici, scanner les versions d’Azure DevOps Server) sont indispensables. Troisièmement, restez informé via les bulletins Microsoft et la communauté : inscrivez-vous aux alertes de sécurité liées à Azure DevOps. En 2025, ceux qui l’ont fait ont pu appliquer le patch CVE-2025-29813 très rapidement. Quatrièmement, envisagez l’automatisation de vos mises à jour d’outils DevOps – par exemple, intégrer un job de pipeline qui, sur validation manuelle, puisse appliquer les updates sur un serveur de test. Beaucoup d’équipes hésitent à patcher vite ces outils de peur de casser la chaîne CI, mais il faut trouver un équilibre qui ne sacrifie pas la sécurité. Enfin, un dernier conseil plus général : diversifiez vos solutions de sécurité logicielle. Par exemple, mettre en place des contrôles indépendants dans les pipelines (scans de code pour détecter d’éventuelles modifications malveillantes, ou signatures du code/artifact final) peut permettre de détecter si un intrus aurait altéré votre processus. Ce sont des pratiques de DevSecOps avancées, mais qui deviendront sans doute la norme pour se prémunir de menaces supply chain. Pour monter en compétence sur ces sujets, il peut être judicieux de suivre une formation CI/CD et DevOps (par ex. se former sur GitLab CI/CD ou GitHub Actions) afin d’adopter toutes les meilleures pratiques de sécurisation des chaînes de développement.
GoAnywhere MFT : la porte dérobée des ransomwares
Les attaques de 2025 ont montré un intérêt marqué des cybercriminels pour les outils de transfert de fichiers. Après les incidents liés à Accellion en 2021 puis MOVEit en 2023, c’est GoAnywhere MFT (Managed File Transfer), édité par Fortra, qui a subi une attaque majeure. Une faille critique (CVE-2025-10035, CVSS 10.0) a été découverte en septembre 2025 dans ce produit, permettant une injection de commandes à distance et menant à une compromission totale du serveur. Signe particulier : cette vulnérabilité a été activement exploitée en zéro-day par un groupe de ransomware avant même que le correctif ne soit disponible, causant des brèches dans de nombreuses organisations.
Exploitation : La faille résidait dans le mécanisme de licence de GoAnywhere. Un composant du serveur (le License Response Servlet) traitait les réponses de licence renvoyées par l’éditeur pour activer/valider le produit. Les chercheurs ont découvert qu’en forgeant une fausse réponse de licence incluant une signature numérique valide (ce que les attaquants ont réussi à faire), il était possible de pousser le serveur à désérialiser un objet Java malveillant. En termes plus simples, un attaquant pouvait envoyer un fichier de licence falsifié qui contournait les vérifications et incitait l’application à charger du code injecté. Immédiatement, ce code s’exécutait avec les droits du service GoAnywhere, donnant à l’attaquant une voie royale vers le système. Cette technique d’attaque, complexe dans son élaboration, a été utilisée par le groupe connu sous le nom Storm-1175 (affilié au ransomware Medusa) dès le 11 septembre 2025, soit une semaine avant que Fortra ne divulgue l’existence de la faille. Les campagnes d’attaque observées ont exploité GoAnywhere MFT comme point d’entrée initial dans les réseaux d’entreprise : une fois le serveur MFT compromis, les assaillants déployaient des outils d’accès à distance (par ex. des agents Cobalt Strike ou des trojans), effectuaient une mouvance latérale (notamment via RDP) pour infecter d’autres machines, utilisaient des outils comme Rclone pour exfiltrer un maximum de données, puis déclenchaient le chiffrement des systèmes avec le ransomware Medusa.
Impact : Pour les entreprises utilisant GoAnywhere, le tableau a été sombre : cet outil étant souvent utilisé pour échanger des fichiers sensibles (par exemple des lots de données avec des partenaires ou des sauvegardes), son compromis signifie que ces fichiers ont pu être copiés par les attaquants. De plus, le serveur MFT a souvent des connexions vers divers dépôts de fichiers internes, voire vers des bases de données, ce qui a pu amplifier l’accès obtenu par les pirates. Dans les attaques constatées, les conséquences allaient de vols massifs de données confidentielles (fichiers clients, données RH, IP, etc.) jusqu’à la mise hors service complète du réseau à cause du ransomware final. Une particularité ici est la double peine : le groupe Medusa pratiquait le double extorsion, menaçant de publier les données volées en plus du chiffrement. Ainsi, même les entreprises disposant de sauvegardes ont fait face à la pression de payer pour éviter un déballage public. Des centaines d’organisations à travers le monde ont été sur la sellette, avec des pertes financières et opérationnelles significatives. Pour les équipes techniques, l’incident a souvent été épuisant : il fallait simultanément reconstruire les systèmes touchés (ou restaurer les backups), analyser l’étendue de l’exfiltration, et renforcer d’urgence la sécurité pour éviter une ré-intrusion.
Correctifs : Fortra a publié le 18 septembre 2025 un correctif pour GoAnywhere MFT, accompagné d’une notification de sécurité. Ce correctif corrige le mécanisme de désérialisation en question, empêchant l’attaque via la fausse licence. Toutes les instances de GoAnywhere devaient être mises à jour immédiatement. En complément, les autorités (comme la CISA) ont ajouté cette vulnérabilité à la liste des failles activement exploitées, en fixant une date butoir (20 octobre 2025) pour l’application du patch dans les agences fédérales américaines – signe de la criticité de l’enjeu. Pour les organisations déjà frappées, il ne suffisait pas de patcher : il fallait traquer la présence de l’attaquant. Étant donné que la faille a été exploitée en 0-day, de nombreux systèmes avaient pu être compromis bien avant la mise à jour. Les administrateurs ont dû inspecter les journaux de GoAnywhere (recherchant des traces d’exécution suspecte de commandes système via le processus de licence), rechercher des nouveaux comptes utilisateurs ou clés SSH déposées furtivement, et vérifier l’intégrité des fichiers de configuration. Souvent, une réinstallation complète du serveur MFT sur une version corrigée, suivie d’une restauration contrôlée des données, a été la manière la plus sûre de repartir.
Prévention futur : Le cas GoAnywhere MFT met en lumière plusieurs leçons cruciales. Primo, identifiez et surveillez étroitement les composants tiers exposés sur le web dans votre architecture. Un serveur de transfert de fichiers accessible par vos partenaires ou clients doit être traité avec le même niveau de vigilance qu’un serveur web public. Assurez-vous de connaître tous ces points d’exposition et d’être inscrit aux bulletins de sécurité de leurs éditeurs pour appliquer les patches immédiatement. Secundo, là où c’est possible, limitez la surface d’attaque : si votre MFT n’a pas besoin d’être accessible à tout Internet, restreignez son accès par adresse IP ou via un VPN. Pour les échanges B2B, envisagez d’établir des tunnels chiffrés dédiés ou d’utiliser des solutions cloud sécurisées plutôt qu’un serveur ouvert sur tous. Tertio, renforcez la défense en profondeur autour de ces outils. Par exemple, segmenter le serveur MFT dans un réseau isolé : même s’il est compromis, les attaquants ne devraient pas pouvoir rebondir facilement sur votre domaine Windows ou vos serveurs critiques sans franchir d’autres barrières. Une bonne pratique est de traiter les serveurs d’échange de fichiers comme des zones démilitarisées : strict minimum de connexions entrantes/sortantes, surveillées par des IDS/IPS. Quarto, préparez-vous aux attaques de type ransomware sur plusieurs fronts : cela implique d’avoir des sauvegardes hors ligne régulières de vos données importantes (y compris les fichiers échangés via MFT), un plan de réponse pour communiquer rapidement (surtout si des données client sont volées), et éventuellement un plan de continuité pour assurer les transferts critiques par un autre moyen temporaire. Enfin, sensibilisez vos équipes sur la récurrence de ce schéma d’attaque : en quelques années, plusieurs solutions de transfert de fichiers ont eu des failles exploitées massivement. Les attaquants adorent ces cibles car elles concentrent de l’information sensible. Un responsable DevOps/IT doit en être conscient et prioriser la cybersécurité autour de ces outils. Si besoin, formez vos équipes aux bonnes pratiques de sécurisation des serveurs et au durcissement des applications web – une montée en compétence qui peut passer par une formation spécialisée en sécurité des systèmes (initiation à la cybersécurité, compréhension des vulnérabilités fréquentes, etc.).
Sitecore : l’héritage d’une clé faible mène à une RCE
Parfois, les failles trouvent leur origine non dans un bug récent, mais dans des choix de configuration historiques malavisés. C’est le cas de la vulnérabilité qui a touché Sitecore en 2025. Sitecore, un puissant CMS/plateforme d’expérience client utilisé par de grandes entreprises, a été victime d’une exécution de code à distance (CVE-2025-53690, CVSS 9.0) exploitée activement. Fait intéressant, aucune nouvelle ligne de code n’était en cause : la faille provenait de l’utilisation d’une clé de chiffrement par défaut inchangée dans de nombreux déploiements, rendant possible l’exploitation du mécanisme ASP.NET ViewState.
Exploitation : ASP.NET ViewState est un système de sérialisation de l’état des pages web côté serveur, souvent protégé par une clé machine (MachineKey) pour empêcher la modification par un client non autorisé. Or, jusqu’en 2017, la documentation officielle de Sitecore (et d’autres produits .NET) fournissait un exemple de configuration avec une clé machine statique. De nombreuses instances Sitecore, installées à l’époque ou clonées d’après des exemples, ont conservé cette même clé de validation sur leurs serveurs de production. En 2025, des chercheurs et pirates s’en sont aperçus : toute installation Sitecore utilisant cette clé publique pouvait être piégée en lui envoyant un ViewState malicieusement forgé et signé avec cette clé (puisque l’attaquant la connaît). Résultat : le serveur acceptait le ViewState comme légitime et désérialisait le contenu qui, vous l’avez deviné, contenait du code dangereux. C’est la porte ouverte à de l’exec de code sur le serveur web, sans authentification préalable. Cette faille a été d’autant plus pernicieuse qu’elle touchait plusieurs produits de la gamme Sitecore – non seulement le CMS principal (Experience Manager), mais aussi d’autres modules (Experience Platform, Commerce, Managed Cloud…) qui partageaient ces configurations de clé par défaut. Les attaquants ont pu exploiter cela en zero-day, avant même que Sitecore n’émette un avis, car il ne s’agissait pas d’un bug logiciel à patcher mais d’un problème de configuration répandu.
Impact : Les entreprises utilisant Sitecore ont pu voir leurs sites web et portails compromis. Via cette RCE, un attaquant obtenait les droits de l’application IIS faisant tourner Sitecore. Immédiatement, il pouvait déployer un webshell sur le serveur (pour exécuter des commandes arbitraires à distance), fouiller les contenus gérés par le CMS (par exemple pour y collecter des données clients ou injecter des scripts malveillants dans les pages web), et potentiellement rebondir sur le réseau interne si ce serveur disposait d’autres accès (connexion à une base de données, ou compte de service Active Directory avec privilèges). Des campagnes d’attaque utilisant cette faille ont été observées : les assaillants déployaient un malware nommé WEEPSTEEL pour effectuer une reconnaissance approfondie du système (récupération de comptes, scan interne), puis créaient des comptes administrateurs fantômes sur la machine ou déployaient des outils d’accès persistant, assurant un contrôle à long terme de l’infrastructure Sitecore infectée. En somme, ce qui pouvait commencer par une simple page web vulnérable se transformait en compromission durable de toute la plateforme digitale de l’entreprise.
Correctifs : Sitecore, une fois alerté du problème courant de clés statiques, a publié un bulletin rappelant fermement aux clients de changer immédiatement la MachineKey de leur installation par une valeur unique et aléatoire. Techniquement, la « faille » se résolvait donc par une action de configuration plutôt que par un patch logiciel (même si dans les versions plus récentes, Sitecore s’est probablement assuré de ne plus utiliser du tout de valeur par défaut dans ses guides). Les administrateurs devaient éditer les fichiers de configuration (Web.config) pour y générer de nouvelles clés (ValidationKey et DecryptionKey) propres à leur instance. En parallèle, Microsoft a ajouté ces CVE liées aux ViewState aux alertes de sécurité (car ce problème a concerné aussi d’autres applications ASP.NET mal configurées, pas uniquement Sitecore). Côté remédiation post-incident, pour les serveurs déjà compromis, il fallait non seulement retirer les webshells et autres malware, mais aussi invalider tout l’historique de confiance basé sur la clé exposée. Autrement dit, après avoir changé la MachineKey, il fallait redémarrer les services pour invalider d’anciens ViewState éventuellement volés, et invalider d’autres jetons/cookies signés avec l’ancienne clé. Il était également recommandé d’examiner les comptes utilisateurs de l’application et de la machine, car les attaquants auraient pu en créer pour conserver l’accès.
Prévention futur : Le cas Sitecore nous enseigne une règle d’or : ne jamais laisser de secret par défaut en production. Que ce soit une clé de chiffrement, un mot de passe par défaut, un certificat d’exemple – ces valeurs doivent impérativement être personnalisées dès l’installation initiale. Dans une démarche DevOps, cela signifie intégrer cette configuration sécurisée dans vos scripts d’Infrastructure as Code : par exemple, si vous déployez une application ASP.NET via Ansible/Terraform, générez dynamiquement une clé MachineKey unique pour chaque nouvel environnement. Plus largement, tenir un inventaire des configurations sensibles (clés, secrets, comptes admin) et les renouveler périodiquement est une bonne pratique. Par ailleurs, cet incident rappelle l’importance de la veille sur la dette technique : ici, c’est un “héritage” d’avant 2017 qui a éclaté au grand jour en 2025. Les équipes doivent se poser régulièrement la question : “Avons-nous des composants en place avec des paramètres anciens potentiellement faibles ?”. Cela peut passer par des audits de configuration automatisés. Par exemple, des outils de scan de configuration IIS/ASP.NET auraient pu signaler l’utilisation de la clé de test bien connue. On peut aussi rapprocher cela des tests de pénétration : un pentester curieux qui remarque un site Sitecore aurait pu tenter de sérialiser un payload avec la clé publique par défaut pour voir si ça passe – une technique relativement simple une fois qu’on y pense. Enfin, niveau architecture, minimiser les privilèges et l’exposition réduira toujours l’impact : exécuter l’application web avec un compte non administrateur, cloisonner l’accès de ce serveur à d’autres ressources, et filtrer les entrées utilisateurs (le ViewState était un vecteur, mais d’autres champs pourraient l’être) via un WAF. A posteriori, un WAF correctement configuré aurait pu détecter un ViewState anormal (très long et binaire) reçu d’un client non authentifié et le bloquer – mais peu d’organisations avaient une règle aussi fine. C’est pourquoi l’approche préventive de la config reste la meilleure. En résumé, traquez et éliminez les configurations par défaut : c’est un message à diffuser à tous les développeurs et ops, par exemple au travers de formations sur les bonnes pratiques de durcissement et de sécurité dès la phase de développement.
Kubernetes Ingress “IngressNightmare” : faille RCE dans le contrôleur NGINX
Au cœur des architectures cloud-native, Kubernetes n’est pas exempt de vulnérabilités. En 2025, une faille critique a été découverte dans l’Ingress Controller NGINX (CVE-2025-1974), souvent surnommée IngressNightmare par la communauté. Elle permettait, dans certaines conditions, à un attaquant non authentifié présent sur le réseau de pods d’un cluster Kubernetes d’exécuter du code arbitraire au sein du contrôleur Ingress. Cette faille a mis en lumière l’importance de ne pas négliger la sécurité interne des clusters, et pas seulement l’accès externe.
Exploitation : Le contrôleur Ingress NGINX est un composant très répandu qui gère l’entrée du trafic HTTP vers les services dans un cluster Kubernetes. Il comprend notamment un webhook d’admission Kubernetes, c’est-à-dire un service qui valide ou modifie les objets Ingress lors de leur création. La faille résidait dans ce webhook : en temps normal, seules les API Kubernetes internes appellent ce webhook pour configuration, mais si un acteur malveillant pouvait lui envoyer directement des requêtes spécialement conçues, il pouvait exploiter une faiblesse de l’isolement d’exécution. Techniquement, un pod déjà déployé dans le cluster, s’il avait accès réseau vers le service du webhook d’admission Ingress (généralement exposé sur un port du contrôleur), pouvait lui soumettre une requête contrefaite contenant des expressions malicieuses. Le webhook traitait ces données dans un contexte insuffisamment sécurisé et pouvait finir par exécuter du code injecté. En clair, un attaquant ayant compromis n’importe quel pod basique dans le cluster pouvait potentiellement prendre le contrôle du contrôleur Ingress lui-même. Comme ce dernier tourne avec des privilèges élevés (il a accès à toutes les règles d’ingress, et souvent il peut communiquer avec l’API-server Kubernetes), c’est un formidable levier d’escalade.
Impact : L’impact direct est la compromission du contrôleur Ingress, ce qui signifie que l’attaquant peut désormais manipuler tout le trafic entrant du cluster (redirection, interception, injection de réponses malveillantes aux clients), et aussi accéder aux secrets que le contrôleur gère (par exemple les certificats TLS pour les sites web de l’entreprise). De plus, comme souvent sur Kubernetes, la compromission d’un composant central permet d’envisager une escalade dans le cluster : avec du code s’exécutant dans le pod du contrôleur, l’attaquant peut essayer d’accéder au serveur d’API Kubernetes (via le compte de service du contrôleur qui peut avoir des permissions étendues) et potentiellement obtenir un contrôle plus global du cluster (jusqu’à devenir administrateur Kubernetes lui-même). On se retrouve alors avec tout le cluster orchestré à la merci de l’attaquant : il pourrait déployer des conteneurs malveillants, extraire toutes les données stockées dans les volumes persistants, ou utiliser l’infrastructure pour d’autres méfaits (crypto-minage, attaques rebondissantes, etc.). Bref, c’est la porte ouverte aux pires scénarios Cloud. Ce qui rend cette faille sournoise, c’est qu’elle nécessite une présence initiale dans le cluster – par exemple via un autre service web vulnérable ou des identifiants de développeur compromis. Ce n’est donc pas un one-shot depuis Internet. Mais elle transforme une compromission mineure (un conteneur isolé piraté) en désastre majeur (le cluster entier compromis).
Correctifs : L’équipe Kubernetes a rapidement communiqué sur le sujet en mars 2025, fournissant une mise à jour de l’Ingress NGINX Controller corrigeant la vulnérabilité. La mise à jour renforce l’isolation des évaluations d’expressions dans le webhook d’admission, empêchant l’exécution de code arbitraire. Toutes les plateformes managed Kubernetes (AKS, EKS, GKE…) ont poussé des correctifs ou guides pour les utilisateurs concernés, et les clusters on-premises devaient mettre à jour l’image de leur ingress-controller vers la version corrigée. En plus du patch, des mesures de mitigation ont été fortement recommandées : 1/ Vérifier que le webhook d’admission du contrôleur n’est pas exposé hors du cluster (en théorie, il ne doit écouter que sur localhost ou sur une adresse interne et être appelé par l’API server uniquement). 2/ Appliquer des Network Policies Kubernetes pour que seuls les composants légitimes (API server) puissent communiquer avec le pod du contrôleur sur ce port webhook. 3/ Dans l’urgence, si on suspecte une compromission ou qu’on ne peut patcher tout de suite, il était possible de désactiver temporairement le webhook d’admission du contrôleur Ingress (avec l’inconvénient de perdre de l’automatisation sur la config, mais un contrôleur ingress fonctionne encore sans cela, en mode plus permissif). Ces actions réduisaient la possibilité pour un pod malicieux de contacter le service vulnérable.
Prévention futur : Cette vulnérabilité dans Kubernetes souligne un point souvent négligé : la sécurité interne du cluster est tout aussi cruciale que la sécurité périmétrique. Pour l’avenir, voici les enseignements pour les équipes DevOps/infra : d’une part, toujours segmenter les droits et accès réseau à l’intérieur du cluster. Même si vos microservices communiquent librement par défaut, des Network Policies bien conçues peuvent empêcher qu’un pod compromis commence à scanner et contacter tous les services internes au hasard. Ici, si chaque application n’avait accès qu’à ses dépendances nécessaires, l’attaquant n’aurait peut-être pas pu atteindre l’endpoint du contrôleur Ingress. D’autre part, suivez de près les annonces de sécurité spécifiques à Kubernetes et ses composants (Ingress controllers, CSI drivers, etc.). Par nature, Kubernetes est un assemblage de nombreuses pièces open-source, il faut donc une veille multi-sources (liste de diffusion K8s, blogs de sécurité cloud, etc.). Intégrez les mises à jour Kubernetes dans votre roadmap régulière ; ne restez pas sur des versions obsolètes de ces composants. Automatiser les déploiements (infrastructure as code) peut aider à re-créer rapidement un cluster avec les nouvelles versions en cas de failles critiques. Ensuite, pensez détection : implémenter de l’audit logging sur les actions sensibles dans le cluster (par exemple, les appels au serveur d’API via des tokens de service, ou les modifications d’Ingress inhabituelles) peut vous alerter qu’un comportement anormal se produit, possiblement dû à une compromission interne. Couplé à des solutions EDR sur les nœuds (certaines solutions se déploient dans les clusters), cela permet de ne pas découvrir l’attaque trop tard. Enfin, pour renforcer vos compétences et celles de vos équipes, la formation à l’administration sécurisée de Kubernetes est un vrai plus. Apprendre à maîtriser les contrôleurs, les politiques de sécurité, la configuration du réseau dans K8s (comme proposé dans les formations Kubernetes DevOps) vous permettra de déployer des clusters par défaut plus sûrs et d’être prêt à réagir vite en cas de faille comme IngressNightmare.
“MadeYouReset” : le déni de service HTTP/2 évolué
Toutes les failles ne visent pas à exécuter du code ou à voler des données. 2025 a également vu l’apparition de techniques avancées de déni de service (DoS) exploitant les subtilités des protocoles. MadeYouReset est le nom donné à une nouvelle attaque affectant le protocole HTTP/2 (regroupée sous l’identifiant CVE-2025-8671 et des CVE spécifiques pour chaque vendor), présentée comme une évolution du tristement célèbre HTTP/2 Rapid Reset de 2023. Bien que ce ne soit pas une vulnérabilité au sens d’un bug de code classique, c’est une faiblesse conceptuelle qui a impacté de multiples serveurs web (Apache, NGINX, Tomcat), librairies (Netty, Jetty) et appliances (F5 BIG-IP, etc.), forçant des mises à jour de la part de ces éditeurs en 2025.
Exploitation : L’attaque HTTP/2 Rapid Reset originelle utilisait le fait qu’un client pouvait inonder le serveur de requêtes RST_STREAM (réinitialisation de flux) de façon asynchrone, amenant le serveur à gaspiller des ressources à les traiter et engendrant un déni de service. Après les révélations de 2023, des mitigations avaient été déployées (limiter le nombre de resets par client, etc.). Cependant, MadeYouReset a démontré que l’on pouvait atteindre le même effet de saturation serveur en utilisant d’autres messages du protocole HTTP/2 de manière malicieuse, mais beaucoup plus subtilement. Par exemple, en envoyant des frames HTTP/2 légèrement malformées ou illégales (comme des valeurs improbables dans WINDOW_UPDATE, des frames PRIORITY incohérentes, ou des données sur des flux dans un état inattendu), l’attaquant force le serveur à émettre lui-même des reset ou des signaux d’erreur interne. Ces resets ne coupent pas net l’utilisation de ressources, au contraire : le serveur entre dans un cycle où il crée et détruit des contextes de manière frénétique, épuisant CPU et mémoire. En orchestrant un envoi savamment dosé de ces frames depuis de nombreux clients, un attaquant peut ainsi reproduire un déni de service distribué de grande ampleur, tout en contournant les limites mises en place contre l’attaque précédente. Puisque chaque frame semble a priori valide ou presque (et exploite différentes branches du code serveur), les systèmes de détection traditionnels ont du mal à distinguer l’attaque du trafic normal jusqu’à ce qu’il soit trop tard.
Impact : Si elle est menée, une telle attaque pourrait paralyser des sites web et services en ligne majeurs. HTTP/2 est très répandu dans les navigateurs modernes et les API, donc pratiquement tous les serveurs publics y sont vulnérables si non patchés. En 2025, aucune attaque massive MadeYouReset n’a été confirmée publiquement, ce qui laisse penser que les chercheurs ont coordonné une divulgation responsable avec les éditeurs pour corriger avant qu’un acteur malveillant ne s’en empare à grande échelle. Cependant, le simple fait que cette technique existe a poussé les grandes entreprises et hébergeurs à prendre les devants : imaginer un DDoS mondial exploitant MadeYouReset est un scénario cauchemardesque où même de gros serveurs cloud ou CDN pourraient vaciller, car l’attaque consomme peu de bande passante pour l’attaquant mais beaucoup de ressources côté serveur. Fin 2025, plusieurs proofs of concept ont été publiés après patch, démontrant la faisabilité de l’attaque. Cela a incité toutes sortes d’organisations (banques, opérateurs, e-commerçants…) à vérifier d’urgence leurs systèmes HTTP/2.
Correctifs : En coordination, les mainteneurs de serveurs web et de librairies ont publié des mises à jour pour renforcer les contrôles sur les frames HTTP/2. Par exemple, Apache httpd, NGINX, Tomcat, Jetty, etc. ont modifié leur implémentation pour mieux valider la cohérence des frames (et fermer la connexion en cas d’anomalie répétée, au lieu de se fatiguer à renvoyer des resets à l’infini). Des limites plus strictes sur certaines valeurs de fenêtre, sur l’enchaînement des PRIORITY, etc., ont été introduites. Certaines appliances réseau (F5, Citrix…) ont livré des patchs pour détecter ce pattern d’attaque et le bloquer plus tôt. La meilleure mitigation est donc la mise à jour de tous vos composants acceptant du HTTP/2. En attendant un patch, une mesure radicale était possible : désactiver HTTP/2 et revenir à HTTP/1.1, éliminant le vecteur d’attaque. C’est évidemment une régression en performances, mais quelques entreprises l’ont fait temporairement pour leurs services les plus critiques jusqu’à application des correctifs, par précaution. Par ailleurs, les grands fournisseurs de CDN et de protection DDoS (Cloudflare, Akamai…) ont affiné leurs systèmes pour repérer des séquences de frames anormales et les filtrer, même si c’est un défi car cela frôle parfois l’analyse comportementale très poussée.
Prévention futur : MadeYouReset nous rappelle que la sécurité ne se limite pas aux failles de développement classiques – les protocoles standards eux-mêmes peuvent receler des angles morts. Pour un responsable technique ou DevOps, cela signifie : 1/ ne pas négliger les mises à jour “de routine” des serveurs web et load balancers. Même sans CVE retentissante au moment T, rester sur la dernière version stable offre souvent en avance des améliorations de robustesse. 2/ Mettre en place un monitoring de capacité et de performance très granulaire. Dans un cas d’attaque DoS comme HTTP/2 reset, ce qui alerte c’est souvent une hausse subite de threads, de conso CPU ou d’ouvertures de sessions. Avoir des tableaux de bord qui tracent ces métriques et des alertes sur dépassement de seuil peut permettre de réagir dès les premières secondes d’une attaque avant qu’elle n’achève vos serveurs. 3/ Élaborer un plan de réponse DDoS : savoir à l’avance quelle mesure vous prendrez en cas de saturation (par ex., basculer sur un CDN de secours, ou activer un mode “dégradé” de votre appli qui consomme moins de ressources). Cela peut inclure la désactivation de certaines fonctionnalités non essentielles pour soulager la charge. Dans le cas de HTTP/2, il faut être prêt éventuellement à rétrograder en HTTP/1. 4/ Collaborer avec vos fournisseurs cloud / CDN : souvent ils en savent plus sur ces attaques émergentes. S’abonner à leurs flux d’alerte et participer à leurs programmes (par exemple certains proposent des fire drills de DDoS où ils testent votre config) vous aidera à rester résilient. 5/ Enfin, une leçon presque philosophique : encourageons dans la mesure du possible l’audit des protocoles. HTTP/2 a été un gros progrès, mais on découvre ses limites bien après sa standardisation. Les équipes d’architecture et de développement backend doivent suivre ces évolutions et comprendre les mécanismes pour les utiliser de façon éclairée. Par exemple, si votre appli n’a pas impérativement besoin de HTTP/2 push ou de très nombreux streams concurrents, vous pourriez configurer des limites plus conservatrices pour réduire la surface à attaquer. Ce sont des décisions à prendre en connaissance de cause. En résumé, MadeYouReset renforce l’idée qu’une posture de sécurité robuste inclut la capacité d’encaisser les chocs (grâce à l’élasticité, aux systèmes de défense en amont) et de s’adapter rapidement (grâce à des équipes formées et réactives) face à des menaces inédites.
SharePoint “ToolShell” : la faille zero-day persistante
Microsoft a eu fort à faire en 2025, non seulement avec Azure DevOps ou les failles Windows, mais aussi avec ses solutions collaboratives on-premise. SharePoint Server – déployé localement par de nombreuses entreprises – a subi une attaque zero-day majeure nommée ToolShell. La vulnérabilité CVE-2025-53770 (CVSS 9.8) permettait une exécution de code à distance non authentifiée sur les serveurs SharePoint, et ce n’était que la partie émergée de l’iceberg : l’exploitation de ToolShell donnait aux attaquants un accès durable, même après l’application des premiers correctifs, grâce à l’extraction de clés de sécurité. Cette affaire a été l’une des crises de sécurité les plus sérieuses pour les environnements Microsoft on-prem en 2025.
Exploitation : La faille ToolShell prenait racine dans une désérialisation non sécurisée au sein de SharePoint. En envoyant une requête spécialement formée vers un composant de SharePoint (probablement lié aux fonctionnalités d’administration ou d’import de données), un attaquant distant pouvait provoquer l’instantiation d’objets non prévus, menant à l’exécution de commandes sur le serveur. Ce qui rend ToolShell distinct, c’est qu’il a perduré malgré un patch initial : Microsoft a corrigé certaines faiblesses en juillet 2025, mais les attaquants ont trouvé moyen de contourner ces premières corrections, forçant Microsoft à émettre un second patch urgent plus solide. Durant cet intervalle, la vulnérabilité a été largement discutée sur les forums de sécurité (vers le 18-19 juillet), et très rapidement exploitée. Des scans Internet ont révélé qu’au 23 juillet, il y avait encore des centaines de serveurs SharePoint exposés vulnérables – plus de 400 détectés par Shadowserver, et potentiellement jusqu’à 16 000 instances repérables sur Shodan à l’échelle mondiale. Plusieurs groupes de menace liés à la Chine (d’après Microsoft, des groupes baptisés Linen Typhoon, Violet Typhoon, Storm-2603, etc.) se sont rués sur l’occasion, voyant là un accès privilégié aux réseaux internes d’entreprises occidentales via leurs serveurs SharePoint non patchés.
Impact : Une fois le serveur SharePoint compromis, l’attaquant disposait d’un accès système équivalent à l’identité sous laquelle tourne SharePoint (souvent un compte service avec privilèges élevés sur la machine Windows et accès aux bases de données de contenu). Immédiatement, les assaillants ont extrait les clés machine de SharePoint – à savoir les clés de validation et de déchiffrement (MachineKey) utilisées par ASP.NET sur ce serveur. Pourquoi ? Parce qu’avec ces clés, même si l’entreprise patchait la faille RCE ensuite, l’attaquant pouvait garder un accès en utilisant les clés volées pour signer des payloads (par exemple des ViewState malveillants similaires au cas Sitecore, ou des cookies d’authentification forgés) et ainsi revenir sur le serveur quand bon lui semble. C’est là que réside le côté “persistant” de ToolShell : c’est plus qu’une simple exécution de code one-shot, c’est un moyen pour l’attaquant de planter un drapeau sur le serveur. En plus de cela, les campagnes ont vu l’installation de webshells (scripts ASPX malveillants permettant l’exécution de commandes à distance sur le serveur via une simple requête HTTP) pour encore faciliter l’accès. Certaines intrusions se sont rapidement transformées en attaques de ransomware : par exemple, le ransomware Warlock a été déployé dans certains cas suite à ToolShell, cryptant les données accessibles depuis le serveur SharePoint (et bien sûr, potentiellement les partages réseau auxquels ce serveur a accès). Dans d’autres cas, ToolShell a servi pour de l’espionnage pur : l’attaquant est resté discret après compromission, se servant de l’accès SharePoint pour siphonner des documents confidentiels et possiblement utiliser le serveur comme pivot vers le reste du domaine Windows (car un serveur SharePoint est souvent membre du domaine AD, possédant des jetons Kerberos réutilisables ou ayant des interactions avec un contrôleur de domaine). Bref, l’impact allait de la fuite de données sensibles au sabotage interne, en passant par la persistance d’une menace qui peut resurgir plus tard.
Correctifs : Microsoft a adressé ToolShell en deux temps. Un premier correctif partiel dans le “Patch Tuesday” de juillet 2025 a comblé certaines failles de désérialisation, mais s’est avéré insuffisant. Devant l’ampleur des attaques, un patch hors bande a été déployé peu après, ciblant spécifiquement CVE-2025-53770 et une variante CVE-2025-53771. Microsoft a fortement insisté pour que les administrateurs appliquent ce correctif additionnel même s’ils avaient déjà patché en début de mois. En outre, Microsoft a fourni des scripts et instructions pour changer les clés de machine ASP.NET sur les serveurs SharePoint compromis, car sans cela, un serveur patché pouvait rester “ouvert” via les clés que l’attaquant détenait. Il fallait régénérer ces clés (ce qui impose de redémarrer IIS/SharePoint, mais c’est nécessaire), et invalider tous les tokens d’auth en circulation (les utilisateurs SharePoint ont dû se reconnecter). Les admins ont aussi été invités à scruter les répertoires virtuels de SharePoint (par ex. /_layouts/ etc.) à la recherche de fichiers non reconnus (signe d’un webshell implanté), ainsi qu’à passer un antivirus/EDR sur le serveur pour détecter d’éventuels outils déposés (backdoors, keyloggers, etc.). Enfin, Microsoft a collaboré avec des entités gouvernementales du renseignement pour alerter certaines entreprises ciblées, ce qui témoigne de la gravité nationale/internationale perçue autour de cette faille.
Prévention futur : Plusieurs enseignements stratégiques se dégagent de ToolShell. Premièrement, si vous maintenez en interne des applications critiques comme SharePoint, Exchange, etc., vous devez être prêts à agir très vite en cas de zero-day. Cela implique d’avoir un processus de veille et de déploiement de patch d’urgence. Par exemple, établir qu’en cas d’alerte MSRC hors cycle sur un produit critique, on mobilise immédiatement une maintenance exceptionnelle (nuits/week-end s’il le faut) pour appliquer le patch. L’époque où l’on attendait le prochain créneau de mise à jour est révolue face aux exploits qui circulent en quelques heures. Deuxièmement, après avoir patché, pensez à assainir complètement le système. ToolShell a montré que patcher la faille ne suffit pas si l’ennemi a déjà pris pied – il faut invalider les moyens qu’il a de revenir. Cela vaut pour tout : si un compte admin a pu être compromis, changez-le; si des tokens API ont pu être volés, régénérez-les. Ici, les clés machine ASP.NET étaient ce qu’il fallait absolument tourner. C’est un réflexe à avoir : identifier ce que l’attaquant a pu subtiliser pendant son temps de présence et le rendre caduc. Troisièmement, envisagez la migration vers des services cloud managés pour les outils collaboratifs, si cela est viable pour votre organisation. Par exemple, SharePoint Online (dans Microsoft 365) n’a pas été affecté par ToolShell – Microsoft gère l’architecture différemment et patche en coulisse. Bien sûr, le cloud apporte d’autres défis, mais externaliser certaines applications très complexes peut réduire votre surface d’attaque directe. Si vous restez on-premise, renforcez l’environnement : par exemple, mettre les serveurs SharePoint derrière un proxy authentifiant ou un VPN limite l’exposition aux seuls acteurs déjà authentifiés (ça n’aurait pas empêché totalement ToolShell puisque c’est une attaque sans auth, mais ça réduit drastiquement qui peut la tenter). Quatrièmement, investissez dans la détection des activités post-exploitation. Dans le cas de SharePoint, voir soudain l’extraction de clés machine (ce qui peut se repérer via des logs système ou un EDR surveillant les API LSASS, etc.), ou la création de nouveaux fichiers ASPX inhabituel dans les chemins de l’appli, ce sont des choses détectables. Un SIEM bien alimenté (intégrant les logs Windows, les logs applicatifs de SharePoint, etc.) aurait pu alerter sur, par exemple, l’utilisation de la cmdlet PowerShell Add-SPShellAdmin hors contexte ou d’autres signes de manipulation. Tout cela pour dire : ayez une approche pro-active, ne comptez pas uniquement sur le patching pour être sécure, comptez aussi sur la surveillance pour savoir si vous avez été touché. Enfin, rappellez-vous que la sécurité est l’affaire de tous les rôles : dans cette faille, les équipes infra doivent patcher, les dev SharePoint doivent éventuellement réviser des customisations qui pourraient aussi introduire des failles, les Ops doivent surveiller, et la direction (CTO/CISO) doit coordonner la réponse. Cette transversalité est typique du DevSecOps moderne : chacun doit connaître un minimum les enjeux (une formation sécurité pour développeurs et une pour administrateurs par exemple, peut aligner les connaissances de base). ToolShell a été une sonnette d’alarme et, espérons-le, a poussé de nombreuses organisations à améliorer leurs processus de gestion des vulnérabilités critiques.
CitrixBleed 2 : fuite de mémoire sur les passerelles Citrix
Les appliances d’accès distant de Citrix ont de nouveau fait parler d’elles en 2025. Citrix NetScaler ADC et Gateway, largement déployés pour fournir des accès VPN et des services de load-balancing, ont subi une vulnérabilité critique surnommée CitrixBleed 2 (CVE-2025-5777, CVSS 9.3). Rappelant le tristement célèbre Heartbleed de 2014 (d’où son nom) et faisant écho à une première CitrixBleed en 2023, cette faille permettait à un attaquant de lire des portions de mémoire sensibles des appliances à distance, sans authentification. En termes d’impact, cela signifiait notamment la possibilité de voler des jetons de session et contourner l’authentification multifacteur des utilisateurs.
Exploitation : L’attaque consistait à envoyer des requêtes spécialement conçues aux interfaces de login des passerelles Citrix, de manière à provoquer des lectures hors-limites en mémoire (out-of-bounds read). En gros, au lieu de recevoir un message d’erreur standard, l’attaquant parvenait à soutirer au serveur des fragments de mémoire, un peu comme tirer sur le fil d’une pelote. En répétant de nombreuses requêtes habiles, il était possible de reconstituer des morceaux conséquents de la mémoire du processus – mémoire qui pouvait contenir des informations ultra-sensibles comme des tokens de session VPN actifs, des secrets de chiffrement, voire des identifiants en clair s’ils y transitaient. L’aspect redoutable, c’est que le tout se faisait de façon silencieuse : du point de vue de l’appliance, la requête pouvait sembler anodine et elle ne plantait pas le système (contrairement à une attaque qui crashe le service, ici on reste furtif en lecture). Des chercheurs ont démontré que via un simple script, on pouvait récolter de multiples sessions utilisateurs valides. Concrètement, cela veut dire qu’un attaquant, sans connaître le mot de passe ni la carte MFA de sa victime, pouvait usurper son accès VPN en réutilisant le cookie/token de session volé.
Impact : Citrix NetScaler étant souvent le point d’entrée au réseau interne d’une entreprise (fournissant accès VPN SSL, accès aux applications publiées, etc.), cette faille était extrêmement critique. Des preuves de concept publiées début juillet 2025 ont montré qu’en quelques minutes, un attaquant pouvait récupérer suffisamment de données pour accéder comme un utilisateur légitime. La compromission ne s’arrête pas là : si un admin Citrix était connecté récemment, le token administrateur pouvait aussi fuiter, permettant à l’attaquant de se connecter à l’interface d’administration du NetScaler et d’en prendre le contrôle (modification de config, insertion de backdoor). De plus, comme le trafic VPN passe par l’appliance, l’attaquant pourrait potentiellement déchiffrer certaines données de session s’il récupère les clés correspondantes en mémoire. Le fait de pouvoir bypasser la MFA est particulièrement problématique car beaucoup d’entreprises pensaient leur VPN “sûr” grâce à l’authentification forte – CitrixBleed 2 a prouvé que si l’appliance en elle-même est faillible, la MFA ne protège pas contre un vol de session en cours. Après l’annonce de la faille, des services de veille ont noté un scanning intensif d’Internet : GreyNoise, par exemple, a détecté des sondes ciblant les services Citrix dès le 23 juin, soit deux semaines avant la publication officielle du PoC le 4 juillet – indice que certains acteurs malveillants se préparaient en avance ou avaient eu vent officieusement de la vulnérabilité. Avec plus de 50 000 appliances NetScaler exposées sur le Net à cette période, le risque d’une vague d’attaques à grande échelle était très élevé.
Correctifs : Citrix a publié des mises à jour de sécurité fin juin 2025 pour colmater cette fuite de mémoire. Le correctif assure que les requêtes malformées ne puissent plus lire au-delà des limites prévues (en renforçant la validation des entrées et la gestion mémoire). Il était impératif pour les administrateurs de mettre à jour tous les appliances Citrix ADC/Gateway sans tarder. En attendant le patch, Citrix avait initialement déclaré n’avoir vu aucune exploitation, mais l’apparition rapide de scans et d’un exploit public a accéléré la communication : certains admins ont pris des mesures temporaires comme invalider toutes les sessions actives (forçant les utilisateurs à se reconnecter, pour rendre caducs d’éventuels tokens déjà volés) et augmenter la vigilance sur les logs. Citrix a conseillé de regarder si des tentatives de connexion inhabituelles avaient eu lieu (ex : un même compte se connectant depuis des adresses IP différentes sur un court laps de temps, ce qui pourrait signifier qu’un token a été volé et réutilisé ailleurs). En cas de doute sur une compromission admin, il fallait immédiatement changer les mots de passe administrateur et vérifier l’intégrité de la configuration (car un admin malveillant pourrait avoir ajouté des comptes cachés ou modifié les règles du firewall).
Prévention futur : Pour éviter ce genre de déconvenue à l’avenir, plusieurs axes se dégagent : 1/ Minimaliser l’exposition : si possible, ne rendez pas votre portail Citrix accessible à tout Internet. Restreignez par géographie (si votre workforce est locale, filtrez par IP), ou imposez une connexion VPN préalable avant d’atteindre le portail (c’est paradoxal d’avoir un VPN derrière un VPN, mais certaines entreprises font un pré-filtrage via un VPN “bastion” par exemple). Moins d’acteurs pouvant toucher l’interface, c’est moins de risques. 2/ Surveillez activement les appliances : mettre en place du threat hunting sur les logs de VPN, c’est essentiel. Par exemple, repérer un utilisateur connecté deux fois simultanément (une fois légitime, une fois potentiellement l’attaquant), ou des erreurs inhabituelles dans les journaux qui pourraient correspondre à des requêtes malicieuses testant la faille. 3/ Raccourcissez la durée de vie des sessions et imposez des reconnexions régulières. Si un token de session ne reste valide qu’une courte période, il limite l’exploitation possible. C’est contraignant pour l’utilisateur, mais on peut trouver un juste milieu. 4/ Pensez à isoler les rôles : l’interface d’administration de l’appliance ne devrait pas être accessible via la même URL que le portail utilisateur. Beaucoup de bonnes pratiques recommandent d’avoir l’admin sur un port ou sous-domaine distinct, idéalement non résolu publiquement. Ainsi, même si un token utilisateur est volé, l’attaquant ne pourra pas directement accéder à l’admin sans d’autres efforts. 5/ Enfin, plus globalement, patch, patch, patch. Les produits Citrix ont eu plusieurs alertes critiques ces dernières années (CVE-2019-19781 par ex., ou CitrixBleed 1 en 2023), donc les administrateurs doivent être à l’affût. Intégrez les appliances dans votre politique de gestion de correctifs, en prévoyant par exemple des maintenances planifiées très rapprochées après chaque bulletin de sécurité Citrix. Cela demande de la rigueur, car on parle d’appliances réseau et non de simples VM : il faut tester la mise à jour, éviter l’interruption de service, etc. – mais on voit bien que ne pas patcher présente un risque bien pire (une interruption forcée par l’attaquant, en somme). 6/ Une dernière mesure de défense en profondeur : activer des solutions d’authentification post-session pour les actions critiques. Par exemple, certaines entreprises utilisent un second facteur pour valider les accès à certaines applications internes même après le VPN. Ainsi, si un attaquant vole un token VPN et se connecte, il sera peut-être bloqué plus loin lorsqu’il voudra accéder à une application sensible qui redemande une MFA. Ce n’est pas infaillible mais ça peut limiter la casse. Au final, CitrixBleed 2 renforce le constat que nos points d’entrée distants (VPN, gateways) sont parmi les cibles favorites des attaquants. C’est une priorité absolue de les protéger et de réagir vite à leur moindre faille.
Ivanti Connect Secure : le VPN en zéro-day, cible des espions
Dès le tout début de 2025, une alerte a concerné un autre équipement d’accès distant : Ivanti Connect Secure, solution VPN très répandue (connue auparavant sous le nom Pulse Secure VPN, rachetée par Ivanti). La vulnérabilité CVE-2025-0282 (CVSS 9.0) a été utilisée dans le cadre d’une attaque réelle de haut niveau, faisant d’elle un véritable zero-day en condition réelle. Cette faille est un débordement de mémoire (buffer overflow) exploitable à distance, sans authentification, permettant l’exécution de code sur l’appliance VPN. Elle a été découverte suite à un incident chez Nominet – l’organisme gérant le registre des noms de domaine .UK – qui a subi une intrusion en lien avec cette faille la dernière semaine de décembre 2024.
Exploitation : Le scénario suivi par les attaquants a été finement reconstitué : profitant de la faille, l’assaillant a envoyé des paquets spécialement craftés au serveur VPN (probablement à l’interface web de la passerelle Ivanti), déclenchant un dépassement de pile (stack overflow) aboutissant à l’exécution d’un shell distant sur l’appliance. En pratique, cela a donné au pirate un accès administratif non autorisé sur le boîtier VPN, comme s’il en avait le contrôle total. Cette position lui a permis plusieurs actions post-exploitation : tout d’abord, un reconnaissance approfondie de l’appliance et de son environnement (ils ont effectué de multiples requêtes HTTP internes via l’appliance pour cartographier ce à quoi elle avait accès, et examiné les configurations réseau). Ensuite, ils ont abusé de la fonctionnalité Host Checker du VPN (un outil normalement utilisé pour vérifier la conformité du poste client) pour exécuter des commandes sur les postes connectés ou sur l’appliance elle-même. Ils ont aussi désactivé des mécanismes de sécurité locaux : les logs (syslog forwarding) ont été stoppés, et même SELinux – la couche de sécurité Linux – a été mis en permissive/inactif, sans doute pour ne pas gêner leurs manipulations. Enfin, ils ont installé des webshells persistants, notamment un nommé PHASEJAM, qui leur donnait un accès continu via HTTP à l’interface de management sans avoir à ré-exploiter la faille à chaque fois. Tout cela, en restant sous le radar pendant plusieurs jours.
Impact : Dans le cas de Nominet, il semble que les attaquants (soupçonnés d’être liés à un état-nation, vu la cible) cherchaient l’espionnage plutôt que la destruction. Aucune exfiltration de données n’a été confirmée, mais le fait qu’ils aient pu rester sur le système une semaine montre combien il était difficile de les détecter une fois à l’intérieur. Une compromission de VPN est l’une des plus dangereuses : le VPN est littéralement le tunnel vers tous vos systèmes internes. En le contrôlant, l’attaquant peut s’y faire passer pour n’importe quel employé, accéder aux mêmes ressources, voire intercepter/modifier le trafic de ceux qui l’utilisent (attaque de type homme du milieu). De plus, une appliance VPN compromise peut servir de relais pour attaquer d’autres machines internes, le tout en profitant de la confiance qu’on a envers le trafic VPN. Dans un cadre sensible comme Nominet, on imagine aisément qu’ils auraient pu altérer le registre des domaines, espionner les communications internes, etc. Cette attaque a tiré la sonnette d’alarme auprès de nombreux gouvernements, car de multiples agences et grandes entreprises utilisent les solutions Ivanti/Pulse, et une telle backdoor aurait pu être utilisée pour des opérations d’espionnage à grande échelle.
Correctifs : Ivanti a réagi début janvier 2025 en publiant un patch le 8 janvier, corrigeant le débordement de mémoire. La diffusion a été rapide, mais malheureusement l’attaque ayant précédé de peu la correction, c’était déjà “après la bataille” pour Nominet. La CISA (agence de cybersécurité américaine) a lancé une alerte demandant à toutes les agences fédérales de patcher cette vulnérabilité avant le 15 janvier 2025, et beaucoup d’organisations privées se sont alignées pour appliquer le correctif dans la foulée. Quelques jours plus tard, le 17 janvier, un code d’exploitation a été publié publiquement, ce qui a mis encore plus la pression pour s’assurer que personne ne restait à la traîne. Pour ceux qui ne pouvaient pas patcher immédiatement (par exemple, absence de maintenance possible), Ivanti a recommandé de déconnecter temporairement l’appliance ou de restreindre drastiquement l’accès (par exemple en filtrant par IP connue), mais bien sûr ce sont des mesures difficiles car elles impactent la continuité d’activité (les employés ne pouvant plus se connecter). Après correction, il était primordial de mener une chasse aux intrusions : vérifier tous les comptes d’administration du VPN (les attaquants auraient pu en créer de nouveaux), analyser les fichiers sur l’appliance à la recherche de webshells comme PHASEJAM (généralement du code dans les répertoires web du produit), et regarder dans les journaux d’authentification si des connexions anormales avaient eu lieu (bien que si les logs étaient désactivés par l’attaquant, il fallait remonter à des journaux externes ou des sauvegardes de logs). Certains ont même choisi, par précaution, de remplacer complètement l’appliance (nouvelle VM ou boîtier, config propre) pour être certains qu’aucune porte dérobée ne persistait dans un coin non détecté.
Prévention futur : Ce cas de figure renforce l’importance d’une approche globale de la sécurité pour les accès distants : anticipation, détection, réaction. Anticipation : Assurez-vous d’être abonné aux bulletins de sécurité de tous vos fournisseurs clés et d’avoir un plan d’urgence pour les appliquer. Dans le cas d’Ivanti, peut-être que si l’on avait su plus tôt la compromission, on aurait pu isoler le système avant qu’il ne soit trop tard – d’où l’intérêt aussi de partager rapidement les informations sur les attaques en cours via les canaux CERT, ISAC, etc. Détection : Mettez en place des systèmes de surveillance des appliances. Par exemple, exporter les logs VPN vers un SIEM central (et s’assurer qu’ils arrivent – dans l’attaque l’assaillant a coupé le forwarding, une alerte “plus de logs reçus” aurait pu déclencher une enquête). Surveillez aussi le comportement du trafic : une appliance VPN qui soudain envoie du trafic inhabituel vers l’interne (comme scanner des ports ou accéder à des serveurs auxquels elle ne parle pas d’ordinaire) devrait alerter. Des solutions existent pour superviser le trafic réseau est-ouest, et elles auraient pu remarquer qu’un équipement censé juste relayer du VPN se mettait à exécuter des choses étranges. Réaction : Entraînez vos équipes à isoler rapidement une machine suspecte. Dans le cas d’un VPN, avoir un nœud de secours est utile : par exemple un serveur VPN de backup sur un autre site ou cloud, qui peut prendre le relais si on doit éteindre le principal. Ainsi, si une alerte critique survient, vous pouvez faire basculer les utilisateurs sur la solution de secours et examiner l’appliance potentiellement compromise sans pression. Toutes les entreprises n’ont pas ce luxe, mais pour des accès critiques c’est à envisager. Segmentation et Zero Trust : Repenser l’accès distant en utilisant des modèles Zero Trust pourrait atténuer l’impact : par exemple, même via VPN, continuer à exiger une authentification supplémentaire pour les applications sensibles, et ne pas considérer le réseau VPN comme totalement “de confiance”. Des solutions de type ZTNA (Zero Trust Network Access), proposées par Zscaler, Cloudflare, etc., visent justement à remplacer les VPN traditionnels par des accès applicatifs contrôlés et micro-segmentés. Elles ne sont pas invulnérables non plus, mais l’idée est de réduire la portée d’une compromission d’une gateway unique. Formation et sensibilisation : Enfin, ce genre de faille requiert aussi une vigilance humaine : l’équipe sécurité de Nominet a finalement repéré l’intrusion via des indices subtils. Il faut encourager une culture où l’on enquête sur le moindre signe bizarre (une alerte d’intégrité, un changement de configuration imprévu, etc.). Former les admins à penser “et si mon équipement est hacké, que verrais-je ?” peut les aider à détecter plus vite ces situations. Par exemple, savoir que désactiver les logs est un signe courant de piratage aurait pu pousser à vérifier dès ce moment-là pourquoi les logs s’étaient arrêtés. En résumé, préparez-vous au pire pour vos accès VPN : ce n’est pas paranoïa, c’est du réalisme en 2025. Et tirez profit des retours d’expérience de ce type d’attaque pour renforcer vos propres défenses en conséquence.
Autres failles notables de 2025
Outre les cas détaillés ci-dessus, l’année 2025 a connu une multitude d’autres vulnérabilités de sécurité – certaines moins critiques, d’autres très spécifiques, mais méritant tout de même d’être mentionnées pour dresser un tableau complet :
- Vulnérabilités Linux locales (Sudo) : Deux failles ont été découvertes dans l’outil Sudo (CVE-2025-32462 et CVE-2025-32463), permettant à un utilisateur local d’obtenir des privilèges root. Bien que leur exploitation nécessite déjà un accès sur la machine, elles rappellent l’importance de tenir à jour même les composants système de base sur les serveurs. Dans un contexte DevOps, un conteneur ou un serveur compromis via une autre faille pourrait s’en servir pour escalader ses privilèges.
- Flaws dans des outils Dev self-hosted : Par exemple, Gogs, une plateforme Git auto-hébergeable très utilisée par les petites équipes, a subi une faille critique (CVE-2025-8110, CVSS ~8.7) permettant l’écriture de fichiers arbitraires via l’API, menant à une potentielle exécution de code. Cette faille a été exploitée sur plus de 700 instances Gogs dans le monde avant correctif. Cela souligne que même des outils de développement moins mainstream peuvent être la cible d’attaques automatisées. De même, n8n (outil de workflows low-code) a eu un bug RCE (CVE-2025-68613, CVSS 9.9) exploitable par un utilisateur authentifié malveillant, impactant potentiellement des milliers d’instances ouvertes en ligne. Pour les équipes techniques, c’est un rappel que la surface de menace s’étend à tous les services exposés, y compris ceux destinés aux développeurs ou à l’automatisation interne.
- Vulnérabilités cloud et mobiles : Chaque mois, les grands éditeurs cloud (AWS, Azure, Google) ont corrigé des failles dans leurs services – souvent moins médiatisées car elles sont patchées côté serveur de manière transparente. Par exemple, Azure a patché discrètement des failles dans ses services réseau (voir CVE-2025-54914, sur Azure Networking). Côté mobile, Android et iOS ont continué à recevoir des correctifs mensuels pour des failles critiques, notamment des RCE via MMS ou Bluetooth. Bien que ces vulnérabilités n’affectent pas directement les serveurs, un DevOps averti sait que la sécurité du poste client compte aussi : un développeur dont le smartphone ou laptop est compromis via une faille mobile pourrait être une brèche vers les comptes cloud ou les dépôts de code de l’entreprise.
- Failles dans les bibliothèques et frameworks open-source : On peut citer par exemple une faille dans MongoDB (CVE-2025-14847 - MongoBleed) qui a nécessité une mise à jour urgente car activement exploitée pour des attaques, ou encore une vulnérabilité critique dans le populaire framework d’IA LangChain (injection via sérialisation) qui a exposé des secrets de configuration. Ces exemples rappellent l’importance de surveiller l’écosystème open-source utilisé dans vos applications. Un composant non mis à jour peut devenir le maillon faible, d’où l’utilité de scanners de dépendances intégrés aux pipelines CI.
- Poursuite des attaques supply chain : Bien qu’aucun incident de l’ampleur de SolarWinds n’ait été révélé en 2025, la menace demeure. Des packages npm malveillants imitant des librairies légitimes ont encore fait des victimes (ex: un faux package WhatsApp API a volé des tokens de session des développeurs). On a aussi vu des attaques plus ciblées : par exemple, une extension malveillante de navigateur a frappé des millions d’utilisateurs (DarkSpectre), ce qui concerne indirectement les entreprises si des identifiants professionnels sont stockés dans le navigateur. Pour un responsable sécurité, cela signifie qu’il faut continuer d’appliquer les principes du Least Privilege et du cloisonnement : même si un dev ou un outil tierce est compromis, cela ne doit pas donner accès à toute la prod.
En résumé, 2025 a été riche en enseignements, chaque faille – même moindre – apportant son lot de leçons pour renforcer la posture de sécurité globale.
Conclusion : renforcer la culture DevSecOps face à la vague de failles
L’analyse de ces failles critiques de 2025 met en évidence une tendance claire : les attaquants innovent et exploitent de plus en plus vite la moindre faiblesse, qu’elle soit logicielle, matérielle ou humaine. Dans de nombreux cas, quelques jours – voire quelques heures – ont suffi entre la divulgation d’une vulnérabilité et son exploitation massive dans la nature. Parfois même, comme on l’a vu avec Ivanti ou GoAnywhere, les assaillants étaient à l’œuvre avant toute annonce publique, utilisant des 0-days de façon redoutablement efficace. Pour les équipes de développement et opérations, mais aussi pour les décideurs (CTO, RSSI), cela impose une remise en question permanente de nos pratiques.
Tout d’abord, la gestion des correctifs doit devenir ultra-réactive. Il ne suffit plus de patcher une fois par trimestre lors des cycles de release planifiés. Il faut embrasser une approche “fast patching” : intégrer les mises à jour de sécurité en continu, dès qu’elles sont disponibles, avec des processus d’urgence. L’infrastructure as code et l’automatisation peuvent aider : par exemple, si vos applications et infrastructures sont reconstruites fréquemment via des templates à jour, vous réduisez la fenêtre d’exposition. Un bon référentiel de bases d’images/container constamment mises à jour avec les derniers correctifs est essentiel. Et il faut tester en amont pour que l’application du patch en production se fasse en confiance. Le concept de “Shift-Left” en sécurité s’applique ici : impliquer la sécurité dès la conception et le développement permet d’attraper des problèmes plus tôt et de prévoir comment réagir rapidement.
Ensuite, la visibilité et la détection sont vitales. Comme l’a souligné l’étude des failles, ce ne sont pas toujours les scores CVSS les plus hauts qui causent les plus gros dégâts, mais souvent celles qui sont effectivement exploitées. Suivre de près les listes de vulnérabilités connues comme exploitées (par exemple via les bulletins CISA KEV) permet de prioriser les efforts sur ce qui compte vraiment “sur le terrain”. Adoptez des outils de threat intelligence pour être alerté lorsque de nouvelles attaques ciblant une techno que vous utilisez émergent. En interne, investissez dans des capacités de monitoring/alerting robustes : logs centralisés, SIEM avec use cases pertinents, EDR sur les endpoints critiques, surveillance réseau anormale, etc. Il vaut mieux attraper un attaquant pendant qu’il est encore en train d’exploiter une faille (et avant qu’il n’atteigne son objectif final), plutôt que de découvrir le désastre après coup.
Par ailleurs, l’approche “DevSecOps” doit être embrassée à l’échelle organisationnelle. Cela signifie casser les silos entre dev, ops et sécu. Les développeurs front-end et back-end doivent être conscients des implications sécurité de leurs choix (ex : ne pas ignorer un warning de librairie vulnérable, faire de la revue de code orientée sécurité). Les équipes Ops/DevOps doivent intégrer la sécurité dans la chaîne CI/CD (ex : tests de sécurité automatisés, linting de configurations, scanning containers). Et l’équipe sécurité doit jouer un rôle de facilitateur, fournir des outils et formations aux autres pour qu’ils montent en compétence. Par exemple, organiser des sessions de formation sur la sécurisation des pipelines CI/CD pour les DevOps, ou sur les vulnérabilités web courantes pour les développeurs, permet de créer une culture commune. Des plateformes de e-learning et de certification (telles que Dyma avec ses formations DevOps, cloud, sécurité, etc.) peuvent accompagner cette montée en compétence transversale. Plus chaque acteur comprendra les enjeux de sécurité des autres, plus les solutions mises en place seront robustes et adoptées.
Une autre leçon globale de 2025 est l’importance d’une architecture résiliente. Puisqu’on ne peut pas garantir l’absence totale de failles, il faut concevoir les systèmes en assumant qu’une compromission peut arriver. C’est l’esprit du Zero Trust et de la défense en profondeur : multiplier les couches de sécurité, limiter les privilèges octroyés par défaut, segmenter les réseaux, chiffrer les données en transit et au repos, sauvegarder régulièrement et de manière isolée… Ainsi, même si un attaquant perce une couche, il se heurte à la suivante. Par exemple, une faille RCE dans un microservice aura moins d’impact si ce service tourne avec un compte limité, stocke peu de données localement et ne peut pas librement atteindre vos bases de données sans authentification. De même, un poste développeur compromis ne devrait pas suffire à compromettre l’intégralité de vos dépôts de code s’il y a une 2FA, une gestion fine des droits, etc. C’est à la direction technique d’impulser ces principes d’architecture sécurisée dès la conception des projets.
Enfin, gardons en tête que la sécurité est un processus continu, pas une destination. Les failles de 2025 laissent entrevoir celles de 2026 : de nouvelles technologies (IA, Web3, 5G…) gagneront en popularité et avec elles de nouvelles surfaces d’attaque émergeront. Il est crucial de rester humble et vigilant. Chaque incident doit servir de retour d’expérience : faites des post-mortems après chaque vulnérabilité gérée, pour identifier ce qui a bien fonctionné (ou pas) dans la réponse apportée. Participez à la communauté, partagez vos trouvailles (sans exposer votre entreprise, mais pour faire avancer la connaissance commune). Et surtout, encouragez un climat où remonter une faille interne n’est pas perçu comme un échec, mais comme une contribution positive à l’amélioration continue.
En conclusion, l’année 2025 aura été éprouvante pour les professionnels de l’IT et du DevOps, mais elle aura aussi poussé à évoluer vers des pratiques plus matures. Les développeurs, les équipes DevOps, les spécialistes sécurité et les décideurs doivent travailler main dans la main pour intégrer la sécurité à chaque étape : c’est le cœur du DevSecOps. Face à des adversaires toujours plus rapides et sophistiqués, c’est cette agilité collective qui fera la différence entre une entreprise qui subit une attaque catastrophique et celle qui en sort indemne, voire renforcée. Prenons donc acte des enseignements de ces failles critiques, et faisons de la sécurité un réflexe, une seconde nature dans tous nos projets technologiques. C’est à ce prix que nos applications et infrastructures resteront dignes de confiance, et que nous pourrons innover sereinement en 2026 et au-delà.
