L'agent de paiement d'IBM acceptait des écritures de runbook non authentifiées — CVE-2026-18875

IBM a divulgué une faille dans le serveur d'agent IA de sa plateforme de paiements, IBM Financial Transaction Manager : un appelant sans aucun identifiant pouvait écrire le runbook de son choix dans la base de données vectorielle à partir de laquelle l'agent récupère des données, et les appels d'outils Model Context Protocol de l'agent pouvaient ensuite être orientés par ce qu'il lisait. Le bulletin de sécurité d'IBM, publié le 21 septembre 2026, indique que la faille pouvait conduire à « des actions de paiement non autorisées ou l'exfiltration de données de paiement ». La CVE, CVE-2026-18875, a été publiée le 23 septembre 2026 avec un score de base CVSS 3.1 de 7.3, associée à CWE-74, et située à api.vectordb.runbooks.js:51. Aucune exploitation en conditions réelles n'a été enregistrée, et aucune perte de client, de paiement ou de données ne lui a été attribuée. Ce compte rendu est tiré d'une seule entrée de the Orca AI Incident Archive, qui recense CVE-2026-18875 comme une vulnérabilité de gravité moyenne sans préjudice enregistré et la place aux côtés des autres incidents d'agents documentés.

Une CVE dans un bulletin de quarante-sept CVE

L'avis d'IBM concernant cette faille n'est pas une notification autonome. Il s'agit d'une seule entrée dans Bulletin de sécurité : IBM Financial Transaction Manager (FTM) est affecté par de multiples vulnérabilités, document UID ibm17288641, dont les tableaux des produits affectés et des mesures correctives couvrent chaque CVE du lot. La page contient 47 identifiants CVE distincts, notés par IBM de 3,7 à 9,9, et son historique des modifications comporte exactement une ligne : « 21 Sep 2026 : Publication initiale. » Le bulletin n'a pas été révisé après sa publication, et sa section Remerciements est vide — IBM ne crédite aucun chercheur, rapporteur ni client pour l'une des 47 constatations.

L'entrée RAG est l'exception dans cette liste. La plupart des descriptions de CVE voisines ressemblent à de l'hygiène logicielle ordinaire pour les intergiciels : clés cryptographiques codées en dur, traversée de répertoires, gestion des entités externes XML, désérialisation non sécurisée, un contrôle d'autorisation manquant dont IBM affirme qu'il « pourrait permettre à un attaquant distant d'exécuter des actions de paiement non autorisées ». CVE-2026-18875 est la seule qui décrive un défaut dans la manière dont l'agent d'IA du produit acquiert les éléments sur lesquels il raisonne. La description d'IBM, citée dans son intégralité depuis l'avis :

IBM Financial Transaction Manager (FTM) 4.x est vulnérable à l’empoisonnement RAG via un upsert de runbook non authentifié (CWE-74) dans le serveur d’agent IA FTM (api.vectordb.runbooks.js:51). Un attaquant non authentifié peut insérer du contenu de runbook malveillant dans la base de données vectorielle de l’agent afin d’orienter les appels d’outils MCP pilotés par l’IA, ce qui peut déclencher des actions de paiement non autorisées ou exfiltrer des données de paiement.

Les dates méritent d'être distinguées, car l'enregistrement et le bulletin n'utilisent pas la même. Le bulletin d'IBM porte une date de publication initiale au 21 septembre 2026. L'identifiant CVE a été réservé le 4 août 2026 et l'enregistrement CVE lui-même a été publié le 23 septembre 2026 à 15:47 UTC ; l'entrée du NVD a suivi à 16:16 UTC le même jour. L'archive classe l'incident au 23 septembre 2026, jour où la CVE est devenue publique, avec une précision au jour.

Le mécanisme : écrire dans le stockage auquel l’agent fait confiance

Un système de génération augmentée par récupération fonctionne en récupérant des passages dans un stock et en les présentant au modèle comme contexte. L'avis d'IBM situe une fonction « runbook upsert » dans cette couche — une opération qui écrit une entrée de runbook dans la base de données vectorielle de l'agent — et indique que l'opération a accepté l'écriture sans authentification. Le chemin indiqué dans l'avis, api.vectordb.runbooks.js:51, pointe vers un service JavaScript, ce qui représente tout ce qu'IBM divulgue en matière d'architecture.

Cela en fait un cas de figure différent de l’injection de prompt indirecte sur laquelle reposent la plupart des incidents liés aux agents. Dans le cas ordinaire, un attaquant doit placer du contenu devant un agent qui navigue sur le Web ou lit des fichiers : empoisonner une page que l’agent va récupérer, un document qu’il va ouvrir, un e-mail qu’il va résumer. Ici, rien ne doit être récupéré de l’extérieur. L’attaquant écrit directement la connaissance empoisonnée dans le référentiel auquel l’agent fait déjà confiance, et le référentiel la lui renvoie comme des consignes opérationnelles validées pendant un workflow de paiement. Redbot Security, une société de renseignement sur les menaces qui a documenté la faille sous la référence RBT-TI-0099 et la présente comme une injection de prompt indirecte avec exfiltration de données sans clic, résume la distinction en une phrase : « Le contenu récupéré peut devenir une influence opérationnelle. » L’archive classe l’enregistrement avec les étiquettes IPI et INFRA pour la même raison : le chemin d’injection est la couche d’instructions de l’agent, et la vulnérabilité se situe dans l’infrastructure.

Ce qu’IBM ne dit pas compte autant que ce qu’IBM dit. L’avis ne nomme pas les outils MCP que l’agent peut appeler, ne précise pas à quelles opérations de paiement ils donnent accès, ne dit pas si la route upsert est exposée dans un déploiement FTM par défaut ou seulement dans certaines configurations, et ne décrit pas le modèle d’authentification censé la protéger. Il dit « potentiellement », et il s’arrête là.

Lecture d'un 7,3

Le vecteur CVSS 3.1 est AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L. Décomposé : joignable via le réseau, faible complexité d’attaque, aucun privilège requis, aucune interaction utilisateur — ce qui en fait la gravité — puis un faible impact sur la confidentialité, l’intégrité et la disponibilité, portée inchangée. Les chiffres d’IBM eux-mêmes situent l’exploitabilité à 3,9 et l’impact à 3,4. Toutes les dimensions d’impact évaluées par IBM sont Faibles. Le 7,3 repose presque entièrement sur la facilité d’accès à la faille, et non sur l’ampleur des dommages qu’IBM estime qu’elle occasionne.

IBM est la seule partie à lui avoir attribué un score. NVD marque CVE-2026-18875 comme « Analyzed » au 7 octobre 2026, mais la seule métrique CVSS figurant dans son dossier est celle d’IBM, étiquetée Secondary ; NVD n’a fourni aucun score primaire de son propre chef. La GitHub Advisory Database contient la même description et le même 7.3, publiés le 23 septembre 2026 à 18:31 UTC.

Ce qui se rapproche le plus d'une évaluation qu'IBM n'a pas rédigée vient du bloc ADP Vulnrichment de la CISA sur l'enregistrement CVE, une décision SSVC 2.0.3 consignée le 23 septembre 2026 à 18:48 UTC : Exploitation : aucune. Automatisable : oui. Impact technique : partiel. Ce verdict dit deux choses à la fois, et les deux appartiennent à la même phrase : le coordinateur de la CISA n'a constaté aucune exploitation au moment de la publication et a considéré la faille comme automatisable — le genre de chose qu'un scanner ou un script pourrait traiter plutôt qu'une attaque manuelle ponctuelle.

Le système de notation des prédictions d'exploitation (EPSS) de FIRST a attribué à CVE-2026-18875 un score de 0,00369, soit environ 0,37 %, au 30e centile, dans l'exécution du modèle datée du 25 octobre 2026. L'EPSS estime la probabilité d'une exploitation observée au cours des 30 prochains jours ; un score au 30e centile est une valeur discrète, et il s'agit d'une prévision plutôt que du compte rendu d'un événement survenu.

Ce qui est établi, et ce qui ne l’est pas

Établi. La vulnérabilité existe et est documentée dans des sources primaires concordantes : le bulletin d’IBM du 21 septembre 2026, l’enregistrement CVE publié le 23 septembre 2026, l’entrée analysée de la NVD et l’avis GitHub. La plage de versions affectées, la version de correctif, le score et le vecteur CVSS, le mappage CWE et l’emplacement du code sont identiques d’une source à l’autre. Le chemin d’écriture était accessible sans identifiants — cela figure dans la description d’IBM elle-même, et non dans une inférence à partir du score. Le coordinateur de la CISA n’a consigné aucune exploitation. L’archive attribue à l’enregistrement une confiance de niveau A, non contesté, avec un préjudice réel consigné comme faux.

• La faille. Un upsert de runbook non authentifié dans le serveur de l'agent IA FTM, à l'adresse api.vectordb.runbooks.js:51, qui permettait à un attaquant d'insérer du contenu dans la base de données vectorielle à partir de laquelle l'agent récupère des informations. Formulation d'IBM, pas une reconstitution.

• La conséquence qu’IBM avance. Ce contenu empoisonné pourrait orienter les appels d’outils MCP vers des actions de paiement non autorisées ou vers l’exfiltration de données de paiement. IBM présente cela comme un résultat potentiel ; elle ne prétend pas l’avoir démontré dans l’environnement d’un client.

• Le correctif. FTM 4.0.11.0, référencé depuis le nœud de support IBM 7285661. Le champ Contournements et mesures d’atténuation du bulletin indique « Aucun ».

• Le registre d’exploitation. Aucun. Le registre SSVC de la CISA du 23 septembre 2026 indique Exploitation : aucune ; le chiffre EPSS de 0,37 % au 25 octobre 2026 est une prévision, et non une observation ; aucune victime, transaction ou perte n’apparaît dans aucune des sources examinées.

Non établi. Qui a découvert la faille et comment — le bulletin ne crédite personne, et il n’existe aucune analyse publique émanant d’un chercheur nommé. Si la route vulnérable est exposée dans un déploiement par défaut ou uniquement dans une configuration spécifique. Ce que 4.0.11.0 change réellement : si la route upsert exige désormais une authentification, ou a été supprimée, ou a été restreinte d’une autre manière. Si un déploiement FTM a déjà exposé le point de terminaison à un réseau non fiable, et pendant combien de temps entre la réservation du 4 août et la publication du 23 septembre. Et si les actions de paiement contre lesquelles IBM met en garde ont déjà été tentées quelque part.

Les plages de versions indiquées dans les trackers secondaires ne concordent pas toutes. Certains présentent la plage affectée comme « 4.0.6.0 et antérieures », ce qui ne correspond pas à ce qu’IBM a publié ; d’autres indiquent de 4.0.7.0 jusqu’à 4.0.11.0 exclu, ce qui correspond à la configuration lisible par machine de la NVD mais omet la ligne de correctifs intermédiaires 4.0.6.0. Le bulletin d’IBM fait autorité ici et répertorie les six lignes de versions reproduites dans la fiche ci-dessus.

Un autre point qui n’est pas établi, parce que personne n’a tenté de l’établir : aucun média grand public ni laboratoire de recherche indépendant ne semble avoir publié sa propre analyse de CVE-2026-18875. La seule évaluation consignée publiquement que IBM n’a pas rédigée est le bloc SSVC à trois champs de la CISA. Au 26 octobre 2026, la couverture se compose du bulletin d’IBM, de l’enregistrement CVE, de la NVD, de l’avis de GitHub et d’un ensemble d’outils de suivi des vulnérabilités qui reproduisent le texte d’IBM. Plusieurs résultats de recherche sur la CVE sont des articles de blog d’origine incertaine qui semblent générés par machine, certains sur des sites qui publient aussi des widgets de prix de cryptomonnaies ; aucun n’a été utilisé comme source ici. Il n’existe pas de second compte rendu indépendant de ce bug.

Le correctif, et l'écart qui suit

La remédiation d'IBM se limite à une mise à niveau de version, rien de plus : mettre à jour FTM pour les déploiements Red Hat OpenShift vers 4.0.11.0, premier correctif au niveau du nœud de support 7285661, sans solution de contournement intermédiaire proposée. Ce dernier point est celui qui compte en pratique. Lorsqu'un fournisseur publie « None » au titre des solutions de contournement, un opérateur qui ne peut pas passer à 4.0.11.0 selon le calendrier des paiements ne dispose plus que des mesures que le fournisseur n'a pas documentées — restreindre les personnes autorisées à accéder aux interfaces de runbook du serveur d'agent, ce que Redbot Security recommande et qu'IBM ne fait pas.

L'enjeu est déterminé par ce qu'est FTM. IBM le décrit comme « un hub de paiements unifié qui traite, surveille et gère en toute sécurité tous les types de paiement, y compris les modèles par lots et en temps réel, » avec la prise en charge d'ISO 20022 pour le traitement et le routage des transactions, ainsi qu'un produit SWIFT complémentaire pour une connectivité SWIFT certifiée. La page produit d'IBM fait également la promotion d'un FTM AI Assistant, une « interface conversationnelle agentique alimentée par l'IA générative » couvrant les paiements, les approbations, les performances du système et la documentation. L'avis nomme un « FTM AI agent server » comme emplacement de la faille et ne dit rien sur la façon dont ce serveur est lié à l'assistant présenté sur la page marketing. Quiconque dessine un diagramme d'architecture à partir des deux documents ensemble ne fait que deviner.

La leçon de conception que Redbot tire de ce cas est celle qui survit au correctif : garder le contenu récupéré hors du chemin d’autorité. Ses recommandations sont que la création, le remplacement et la suppression de runbooks exigent une authentification, une approbation et une attribution ; que les runbooks récupérés ne puissent jamais autoriser des paiements, élargir le périmètre des transactions ou permettre un transfert de données externes de leur propre chef ; et que les services de paiement connectés appliquent leurs propres autorisations, quelle que soit la façon dont l’agent interprète ce qu’il a récupéré. Ce sont les recommandations d’une société de renseignement sur les menaces, et non des engagements d’IBM, et le bulletin d’IBM n’en formule aucune.

Pourquoi l'archive l'appelle medium

La fiche et le score CVSS répondent à des questions différentes, et l’écart entre les deux constitue le résumé honnête de ce cas. Le 7,3 d’IBM est un score de la bande HIGH pour une faille trivialement atteignable. L’archive consigne l’entrée comme une vulnérabilité plutôt qu’un incident, avec une gravité moyenne, un préjudice réel faux, une confiance A et aucun indicateur de contestation, datée du 23 septembre 2026 au jour près et déposée avec un champ de région globale. Ces champs décrivent ce qui s’est passé, et ce qui s’est passé n’est rien.

Cette combinaison est tout l’intérêt de la fiche. Un agent de paiement qui lisait dans un stockage où n’importe qui pouvait écrire constitue un sacré morceau d’ingénierie, et il a été corrigé lors d’une mise à niveau de version avant que quiconque soit connu pour l’avoir utilisé. Les deux moitiés sont vraies, et le dossier les garde distinctes plutôt que de laisser le score ou le silence parler seuls.