Notée 9,8 sur 10 en gravité, la faille pourrait permettre à un attaquant distant d’obtenir un accès non autorisé aux applications.
IBM exhorte ses clients à corriger rapidement une vulnérabilité critique dans sa plateforme API Connect qui pourrait permettre à des attaquants distants de contourner l’authentification.
La société décrit API Connect comme une passerelle d’interface de programmation d’applications (API) à cycle de vie complet utilisée « pour créer, tester, gérer, sécuriser, analyser et socialiser des API ».
Il le présente notamment comme un moyen de « libérer le potentiel de l’IA agentique » en fournissant un point central de contrôle pour l’accès aux services d’IA via des API. La plateforme comprend également API Agent, qui automatise les tâches tout au long du cycle de vie de l’API à l’aide de l’IA.
Un composant clé est un portail en libre-service personnalisable qui permet aux développeurs de s’intégrer facilement et de découvrir et d’utiliser plusieurs types d’API, notamment SOAP, REST, les événements, les ASyncAPI, GraphQL et autres.
La faille, identifiée comme CVE-2025-13915, affecte les versions 10.0.8.0 à 10.0.8.5 d’IBM API Connect et la version 10.0.11.0, et pourrait donner un accès non autorisé aux applications exposées, sans aucune interaction de l’utilisateur requise.
Une hypothèse architecturale est brisée
« CVE-2025-13915 ne doit pas être compris comme un bug de sécurité », a déclaré Sanchit Vir Gogia, analyste en chef chez Greyhound Research. « Cela est mieux compris comme un moment où une hypothèse architecturale de longue date éclate enfin au grand jour. L’hypothèse est simple et profondément ancrée dans la conception de l’entreprise : si le trafic passe par la passerelle API, l’identité a été renforcée et la confiance a été établie. Cette vulnérabilité prouve que cette hypothèse peut échouer complètement. »
Il a noté que la classification de la faiblesse, qui correspond à CWE-305, est importante car elle exclut toute une classe d’explications qu’il appelle réconfortantes. « Il ne s’agit pas d’informations d’identification volées. Ce n’est pas une mauvaise configuration de rôle. Ce n’est pas une erreur d’autorisation », a-t-il déclaré. « L’application de l’authentification elle-même peut être contournée. »
Lorsque cela se produit, a-t-il expliqué, les services en aval ne sont pas simplement confrontés à un risque élevé, ils perdent les fondements sur lesquels leurs décisions d’accès ont été fondées, car ils ne revalident pas l’identité. Ils n’ont jamais été conçus pour cela ; ils héritent de la confiance.
« Une fois que l’application de la loi échoue en amont, la confiance héritée se transforme en confiance non méritée, et la révélation se propage silencieusement », a-t-il déclaré. « Cette classe de vulnérabilité s’aligne sur l’automatisation, une analyse à grande échelle et des sondages opportunistes plutôt que sur un ciblage minutieux. »
Correctifs provisoires fournis
IBM a déclaré que le problème avait été découvert lors de tests internes et avait fourni des correctifs provisoires pour chaque version concernée du logiciel, avec des détails de mise à jour individuels pour VMware, OCP/CP4I et Kubernetes.
La seule atténuation suggérée pour la faille, selon le bulletin de sécurité d’IBM, est la suivante : « Les clients incapables d’installer le correctif temporaire doivent désactiver l’inscription en libre-service sur leur portail de développeur si elle est activée, ce qui contribuera à minimiser leur exposition à cette vulnérabilité. »
La société indique également dans ses instructions d’installation pour les correctifs que les remplacements d’image décrits dans le document doivent être supprimés lors de la mise à niveau vers la version ou le groupe de correctifs suivant.
Selon Gogia, cela augmente encore le risque. « Ce n’est pas un détail esthétique », a-t-il souligné. « Les plans de gestion définissent la vérité de la configuration, le contrôle du cycle de vie et l’autorité opérationnelle sur l’ensemble de la plateforme. Lorsque la correction touche cette couche, la vulnérabilité se situe à proximité du noyau de contrôle, et non à la périphérie d’une passerelle isolée. Cela augmente à la fois le rayon d’explosion et le risque de correction. »
En effet, des erreurs dans ces domaines peuvent se transformer en une exposition prolongée ou une instabilité du service. « (Les remplacements d’images) introduisent également un risque de gouvernance : les remplacements d’images créent un état fantôme ; s’ils ne sont pas explicitement supprimés par la suite, ils persistent discrètement », a-t-il souligné. « Au fil du temps, ils échappent à la visibilité, à la propriété et à la portée de l’audit. C’est ainsi que les correctifs temporaires se transforment en risque à long terme. »
Résultat le plus précieux : apprentissage
Il a ajouté que les défis opérationnels liés à la remédiation ne consistent pas tant à savoir ce qui doit être fait, mais plutôt à le faire assez rapidement sans perturber l’activité. Et, a-t-il ajouté, la gouvernance des API doit désormais inclure des inventaires à jour des API, de leurs versions, dépendances et points d’exposition, ainsi qu’une surveillance du comportement.
« Le résultat le plus précieux ici n’est pas la clôture », a observé Gogia. « C’est un apprentissage. Les entreprises devraient se demander ce qui se serait passé si cette faille avait été exploitée en silence pendant des semaines. Quels services auraient implicitement fait confiance à la passerelle ? Quels journaux auraient montré un comportement anormal ? Quelles équipes l’auraient remarqué en premier ? Ces réponses révèlent si les hypothèses de confiance sont visibles ou invisibles. Les organisations qui s’arrêtent à l’application de correctifs manqueront une rare opportunité de renforcer leur résilience avant l’arrivée de la prochaine défaillance du plan de contrôle. »
