La CISA ajoute au KEV deux failles WSO2 et Adobe Commerce activement exploitées
Le 24 septembre 2026, la CISA a inscrit au catalogue KEV la faille de traversal de chemin CVE-2026-5430 chez WSO2 et l’autorisation défaillante CVE-2026-71362 chez Adobe Commerce et Magento, toutes deux exploitées en conditions réelles. Les agences fédérales américaines doivent corriger avant le 27 septembre, et toute organisation qui expose ces produits doit faire de même sans attendre.
24 septembre 2026. La CISA inscrit au catalogue KEV (Known Exploited Vulnerabilities) deux failles critiques, la CVE-2026-5430 chez WSO2 et la CVE-2026-71362 chez Adobe Commerce/Magento. 13 septembre 2026. watchTowr observe les premières tentatives d’exploitation en conditions réelles contre la faille WSO2 sur ses honeypots. 27 septembre 2026. C’est la date limite imposée aux agences fédérales américaines (FCEB) pour appliquer les correctifs. Pourquoi c’est important : la KEV ne recense que les failles dont l’exploitation est prouvée — ces deux-là ne sont pas des hypothèses de laboratoire, mais des brèches que des attaquants utilisent déjà.
Deux failles, deux classes de risque différentes
Les deux vulnérabilités ne se ressemblent pas, et c’est justement ce qui rend le lot intéressant.
La CVE-2026-5430 est une traversal de chemin notée CVSS 9.8 dans la plateforme WSO2. Elle touche quatre composants — API Control Plane, API Manager, Traffic Manager et Universal Gateway — et permet un téléversement de fichier sans restriction qui débouche sur une exécution de code à distance. Concrètement, un attaquant qui atteint l’une de ces interfaces peut déposer un fichier là où il ne devrait pas, puis le faire exécuter. Sur une passerelle d’API ou un plan de contrôle IAM, c’est la pire catégorie de faille possible : la machine compromise est précisément celle qui arbitre l’accès au reste du système.
La CVE-2026-71362 est une autorisation incorrecte notée CVSS 9.1 dans Adobe Commerce et Magento. Elle permet à un attaquant d’obtenir un accès élevé à des ressources sensibles sans aucune interaction utilisateur. Selon Sansec, la société néerlandaise spécialisée dans la sécurité e-commerce, la faille « permet aux attaquants de basculer la session d’un client vers le compte d’un autre client », ce qui leur ouvre l’accès au compte de la victime et à ses données privées.
Deux vecteurs, un même enseignement : WSO2 est la porte d’entrée d’une infrastructure, Adobe Commerce est la caisse d’un marchand. Les deux attirent le même type d’acteur — celui qui veut de l’accès et des données, pas du bruit.
Une exploitation documentée depuis l’été
La KEV ne se remplit pas sur un score CVSS, mais sur des preuves. Ici, elles datent de plusieurs semaines.
watchTowr indique avoir observé des efforts d’exploitation in the wild contre la CVE-2026-5430 depuis au moins le 13 septembre 2026, sur ses capteurs. L’inscription au KEV intervient donc à peine plus d’une semaine après les premiers signaux — un délai court, qui traduit la confiance de la CISA dans la réalité de la menace.
Pour la CVE-2026-71362, la chronologie est plus ancienne. Sansec dit avoir détecté et bloqué des tentatives d’exploitation dès août 2026. La télémétrie de Previdian précise qu’une adresse IP unique australienne a tenté d’exploiter la faille contre ses honeypots le 10 septembre 2026. Adobe n’a pas encore mis à jour son avis pour confirmer le statut d’exploitation — un silence fréquent, mais qui n’a pas empêché la CISA de trancher.
Ce décalage entre les deux failles a une conséquence pratique. Pour WSO2, l’exploitation est récente et probablement encore ciblée. Pour Adobe Commerce, elle court depuis des semaines : les attaquants ont eu le temps d’industrialiser leurs tentatives, et chaque jour de retard augmente la probabilité qu’un compte client ait déjà été basculé.
Deux chaînes d’attaque, deux traces différentes
Pour bien défendre, il faut comprendre comment chaque faille se déroule concrètement, car les deux ne laissent pas les mêmes indices.
Côté WSO2, la traversal de chemin ouvre une porte simple : l’attaquant manipule un chemin de fichier pour échapper au répertoire prévu. Sur une plateforme d’API, le point sensible est le téléversement — fichiers de configuration, politiques, certificats. Une fois le fichier malveillant déposé au bon endroit, l’exécution de code transforme la passerelle en point d’ancrage : l’attaquant voit le trafic API transiter et peut pivoter vers les services en amont. La trace à chercher est double — des fichiers récents dans les répertoires d’upload, et des processus enfants inhabituels lancés par le service WSO2.
Côté Adobe Commerce, la chaîne est plus discrète. L’autorisation incorrecte ne dépose rien, elle change d’identité : l’attaquant bascule sa session vers celle d’un client légitime. La victime ne voit rien — son panier, son historique et ses données sont consultés, voire modifiés, par quelqu’un d’autre. La trace se lit dans les journaux d’accès : des connexions au même compte depuis des adresses ou des empreintes de navigateur différentes, ou un changement d’adresse d’expédition juste après une connexion anormale.
La leçon vaut pour toute faille activement exploitée : le correctif ferme la porte, mais il ne nettoie pas la maison. Si la faille a pu être utilisée, l’investigation forensique fait partie intégrante du correctif — et c’est elle, plus que le patch, qui dira si un client a déjà été détourné.
Ce qu’il faut corriger, et dans quel ordre
La première action est de localiser les instances exposées. La faille WSO2 touche quatre produits qui ne sont pas toujours inventoriés : une passerelle API oubliée derrière un reverse proxy, ou un plan de contrôle API Manager hérité d’un projet mort, suffit à rouvrir la brèche.
Une fois l’inventaire fait, l’ordre de priorité est simple :
- WSO2 d’abord, parce que la faille donne l’exécution de code. Appliquez le correctif, mais ne vous arrêtez pas là : un path traversal exploité peut avoir laissé des webshells ou des fichiers téléversés. Recherchez les artefacts récents dans les répertoires d’upload et les journaux de l’application.
- Adobe Commerce/Magento ensuite. Appliquez le patch de sécurité, puis auditez les connexions administratives et les changements de compte anormaux — une bascule de session ne laisse pas toujours une trace évidente dans les logs applicatifs, mais elle en laisse dans les journaux d’accès.
Pour les agences FCEB, la date butoir du 27 septembre 2026 est contraignante au sens propre : elle est écrite dans la BOD 22-01. Pour tout le monde, elle a valeur de signal. Si la CISA donne trois jours, c’est que la menace est jugée immédiate.
Verdict
Le lot est un rappel que les plateformes « de confiance » — une passerelle d’API, une boutique en ligne — sont des cibles de premier choix, pas des angles morts. Si vous opérez WSO2, corrigez dès aujourd’hui et traitez toute instance exposée comme potentiellement compromise, parce que l’exécution de code à distance ne laisse pas le bénéfice du doute. Si vous exploitez Adobe Commerce ou Magento, appliquez le patch de sécurité et cherchez activement des signes de bascule de session : des semaines d’exploitation documentée, c’est une fenêtre dans laquelle un compte client a pu être détourné. Si vous ne faites que suivre la KEV, retenez le rythme : deux failles confirmées en un lot, avec une échéance à trois jours, c’est le genre de signal qui justifie de reclasser ces correctifs au-dessus de votre cycle habituel. Les deux failles, ensemble, montrent aussi que la KEV n’est pas un classement de gravité, mais un calendrier de rattrapage : chaque ligne est une course contre des attaquants déjà en mouvement.