IBM presse ses clients à corriger rapidement une vulnérabilité critique dans sa plateforme API Connect donnant la capacité à des pirates distants de contourner son processus d'authentification. Cette solution est utilisée pour créer, tester, gérer, sécuriser, et analyser les interfaces de programmation. Identifiée en tant que CVE-2025-13915, cette faille s'est vue attribuée un score CVSS de 9.8 sur 10 et affecte les versions 10.0.8.0 à 10.0.8.5 et la version 10.0.11.0 d'IBM API Connect. Elle pourrait permettre un accès non autorisé aux applications exposées, sans aucune interaction de la part de l'utilisateur.

API Connect est présenté par IBM comme un moyen de « libérer le potentiel de l'IA agentique » en fournissant un point de contrôle centralisé pour l'accès aux services IA via des API. La plateforme comprend également API Agent, qui automatise les tâches tout au long du cycle de vie des API à l'aide de l'IA. Un de ses éléments clés est un portail en libre-service personnalisable donnant la capacité aux développeurs de s'inscrire facilement, de découvrir et d'utiliser plusieurs types d'API, notamment SOAP, REST, events, ASyncAPIs, GraphQL et autres.

Une hypothèse fausse mais bien ancrée

« La CVE-2025-13915 ne doit pas être considérée comme un bug de sécurité », prévient Sanchit Vir Gogia, analyste en chef chez Greyhound Research. « Il s'agit plutôt d'un problème remettant finalement en cause une hypothèse architecturale de longue date, simple et profondément ancrée dans la conception des entreprises : si le trafic passe par la passerelle API, l'identité a été vérifiée et la confiance établie. Cette vulnérabilité prouve que cette hypothèse peut être complètement erronée. »  L'anlyste a souligné que la classification de cette faiblesse, de type CWE-305 (contournement d'authentification par faiblesse primaire), est importante car elle exclut toute une série d'explications rassurantes. « Il ne s'agit pas d'un vol d'identifiants. Il ne s'agit pas d'une mauvaise configuration des rôles. Il ne s'agit pas d'une erreur d'autorisation », a-t-il déclaré. « Le processus d'authentification lui-même peut être contourné. »

Lorsque cela se produit, explique-t-il, les services en aval ne sont pas seulement exposés à un risque accru, ils perdent également le fondement sur lequel reposaient leurs décisions d'accès, car ils ne revérifient pas l'identité. Ils n'ont jamais été conçus pour cela ; ils héritent de la confiance. « Une fois que l'application échoue en amont, la confiance héritée devient une confiance imméritée, et l'exposition se propage silencieusement », explique-t-il. « Ce type de vulnérabilité s'aligne davantage sur l'automatisation, l'analyse à grande échelle et les sondages opportunistes que sur un ciblage minutieux. »

Des correctifs provisoires fournis

IBM a déclaré que le problème avait été découvert lors de tests internes et a fourni des correctifs provisoires pour chaque version concernée du logiciel, avec des détails individuels sur les mises à jour pour VMware, OCP/CP4I et Kubernetes. Selon le bulletin de sécurité d'IBM, la seule mesure d'atténuation suggérée pour cette faille est la suivante : « Les clients qui ne peuvent pas installer le correctif provisoire doivent désactiver l'inscription en libre-service sur leur portail développeur si celle-ci est activée, ce qui permettra de minimiser leur exposition à cette vulnérabilité. » La société précise également dans ses instructions que les remplacements d'images décrits dans le document doivent être supprimés lors de la mise à niveau vers la version ou le correctif suivant.

Selon M. Gogia, cela augmente encore davantage le risque. « Ce n'est pas un détail insignifiant », a-t-il souligné. « Les plans de gestion définissent la configuration réelle, 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 trouve à proximité du noyau de contrôle, et non à la périphérie d'une passerelle isolée. Cela augmente à la fois le rayon d'action et le risque lié à la correction. » En effet, les erreurs dans ces domaines peuvent se traduire par une exposition prolongée ou une instabilité des services. « [Les remplacements d'images] introduisent également un risque de gouvernance : ils créent un état fantôme ; s'ils ne sont pas explicitement supprimés par la suite, ils persistent discrètement », souligne-t-il. « Au fil du temps, ils échappent à la visibilité, à la propriété et au champ d'application des audits. C'est ainsi que des corrections temporaires se transforment en risques à long terme. »

Apprendre à anticiper les conséquences des exploitations de failles

Sanchit Vir Gogia 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, selon lui, la gouvernance des API doit désormais inclure des inventaires à jour des API, de leurs versions, de leurs dépendances et de leurs points d'exposition, ainsi que la surveillance de leur comportement. « Le résultat le plus précieux ici n'est pas la résolution du problème, c'est l'apprentissage », a observé M. Gogia. « Les entreprises devraient se demander ce qui se serait passé si cette faille avait été exploitée discrètement pendant des semaines. Quels services auraient fait implicitement confiance à la passerelle ? Quels logs 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 entreprises qui se contentent d'appliquer des correctifs manqueront une occasion rare de renforcer leur résilience avant la prochaine défaillance de leur plan de contrôle. »