IBM's Payment Agent Accepted Unauthenticated Runbook Writes — CVE-2026-18875

IBM disclosed a flaw in the AI agent server of its payments platform, IBM Financial Transaction Manager: a caller with no credentials could write a runbook of their choosing into the vector database the agent retrieves from, and the agent's own Model Context Protocol tool calls could then be steered by what it read. IBM's security bulletin, published on 21 September 2026, says the flaw could lead to "unauthorized payment actions or exfiltrating payment data." The CVE, CVE-2026-18875, was published on 23 September 2026 with a CVSS 3.1 base score of 7.3, mapped to CWE-74, and located at api.vectordb.runbooks.js:51. No exploitation in the wild has been recorded, and no customer, payment or data loss has been attributed to it. This account is drawn from a single entry in the Orca AI Incident Archive, which records CVE-2026-18875 as a medium-severity vulnerability with no harm recorded and places it beside the other documented agent incidents.

One CVE inside a forty-seven-CVE bulletin

IBM's advisory for this flaw is not a standalone notice. It is a single entry in Security Bulletin: IBM Financial Transaction Manager (FTM) is Impacted by Multiple Vulnerabilities, document UID ibm17288641, whose affected-product and remediation tables cover every CVE in the batch. The page carries 47 distinct CVE identifiers, scored by IBM from 3.7 to 9.9, and its change history holds exactly one line: "21 Sep 2026: Initial Publication." The bulletin was not revised after it appeared, and its Acknowledgement section is empty — IBM credits no researcher, reporter or customer for any of the 47 findings.

The RAG entry is the outlier in that list. Most of the neighbouring CVE descriptions read like ordinary middleware hygiene: hard-coded cryptographic keys, path traversal, XML external entity handling, unsafe deserialization, a missing authorization check that IBM says "could allow a remote attacker to execute unauthorized payment actions." CVE-2026-18875 is the only one that describes a defect in how the product's AI agent acquires the material it reasons over. IBM's description, quoted in full from the advisory:

"IBM Financial Transaction Manager (FTM) 4.x is vulnerable to RAG poisoning via unauthenticated runbook upsert (CWE-74) in the FTM AI agent server (api.vectordb.runbooks.js:51). An unauthenticated attacker can insert malicious runbook content into the agent's vector database to steer AI-driven MCP tool calls, potentially triggering unauthorized payment actions or exfiltrating payment data."

The dates are worth separating, because the record and the bulletin do not use the same one. IBM's bulletin carries an initial publish date of 21 September 2026. The CVE identifier was reserved on 4 August 2026 and the CVE record itself was published on 23 September 2026 at 15:47 UTC; NVD's entry followed at 16:16 UTC the same day. The archive files the incident on 23 September 2026, the day the CVE became public, with day precision.

The mechanism: writing into the store the agent trusts

A retrieval-augmented generation system works by fetching passages from a store and putting them in front of the model as context. IBM's advisory places a "runbook upsert" function in that layer — an operation that writes a runbook entry into the agent's vector database — and says the operation accepted the write without authentication. The path in the advisory, api.vectordb.runbooks.js:51, points at a JavaScript service, which is as much architecture as IBM discloses.

That makes this a different proposition from the indirect prompt injection most agent incidents turn on. In the ordinary case an attacker has to get content in front of a browsing or file-reading agent: poison a page the agent will fetch, a document it will open, an email it will summarise. Here nothing has to be fetched from outside. The attacker writes the poisoned knowledge directly into the store the agent already trusts, and the store hands it back as vetted operational guidance during a payment workflow. Redbot Security, a threat-intelligence firm that wrote the flaw up as RBT-TI-0099 and frames it as indirect prompt injection with zero-click data exfiltration, puts the distinction in one line: "Retrieved content can become an operational influence." The archive tags the record IPI and INFRA for the same reason — the injection path is the agent's instruction layer, and the vulnerability is in infrastructure.

What IBM does not say matters as much as what it does. The advisory does not name the MCP tools the agent can call, does not say which payment operations they reach, does not say whether the upsert route is exposed in a default FTM deployment or only in particular configurations, and does not describe the authentication model that was supposed to guard it. It says "potentially," and it stops there.

Reading a 7.3

The CVSS 3.1 vector is AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L. Unpacked: reachable over the network, low attack complexity, no privileges required, no user interaction — which is what makes it serious — and then low confidentiality, low integrity and low availability impact, scope unchanged. IBM's own numbers put exploitability at 3.9 and impact at 3.4. Every impact dimension IBM assessed is Low. The 7.3 is carried almost entirely by how easy the flaw is to reach, not by how much damage IBM believes it does.

IBM is the only party that has scored it. NVD marks CVE-2026-18875 as "Analyzed" as of 7 October 2026, but the only CVSS metric on its record is IBM's, tagged Secondary; NVD supplied no primary score of its own. GitHub's Advisory Database carries the same description and the same 7.3, published 23 September 2026 at 18:31 UTC.

The nearest thing to an assessment IBM did not write comes from CISA's ADP Vulnrichment block on the CVE record, an SSVC 2.0.3 decision recorded on 23 September 2026 at 18:48 UTC: Exploitation: none. Automatable: yes. Technical impact: partial. That verdict says two things at once, and both belong in the same sentence: CISA's coordinator saw no exploitation at the time of publication, and considered the flaw automatable — the kind of thing a scanner or a script could work through rather than a one-off manual attack.

FIRST's Exploit Prediction Scoring System put CVE-2026-18875 at 0.00369, or roughly 0.37%, in the 30th percentile, in the model run dated 25 October 2026. EPSS estimates the probability of observed exploitation in the next 30 days; a 30th-percentile score is a quiet number, and it is a forecast rather than a report of anything that happened.

What is established, and what is not

Established. The vulnerability exists and is documented in primary sources that agree with each other: IBM's bulletin of 21 September 2026, the CVE record published 23 September 2026, NVD's analyzed entry, and GitHub's advisory. The affected version range, the fix version, the CVSS score and vector, the CWE mapping and the code location are identical across them. The write path was reachable without credentials — that is in IBM's own description, not an inference from the score. CISA's coordinator recorded no exploitation. The archive grades the record confidence A, not disputed, with real harm recorded as false.

• The flaw. An unauthenticated runbook upsert in the FTM AI agent server, at api.vectordb.runbooks.js:51, which let an attacker insert content into the vector database the agent retrieves from. IBM's wording, not a reconstruction.

• The consequence IBM claims. That poisoned content could steer MCP tool calls toward unauthorized payment actions or payment-data exfiltration. IBM states this as a potential outcome; it does not claim to have demonstrated it in a customer environment.

• The fix. FTM 4.0.11.0, referenced from IBM support node 7285661. The bulletin's Workarounds and Mitigations field reads "None."

• The exploitation record. None. CISA's SSVC record of 23 September 2026 carries Exploitation: none; the EPSS figure of 0.37% as of 25 October 2026 is a forecast, not an observation; no victim, transaction or loss appears in any source reviewed.

Not established. Who found the flaw and how — the bulletin credits nobody, and there is no public write-up from a named researcher. Whether the vulnerable route is exposed in a default deployment or only under specific configuration. What 4.0.11.0 actually changes: whether the upsert route now requires authentication, or was removed, or was narrowed in some other way. Whether any FTM deployment ever exposed the endpoint to an untrusted network, and for how long between the 4 August reservation and the 23 September publication. And whether the payment actions IBM warns about were ever attempted anywhere.

The version ranges in secondary trackers do not all agree. Some render the affected range as "4.0.6.0 and earlier," which is not what IBM published; others give 4.0.7.0 up to but not including 4.0.11.0, which matches NVD's machine-readable configuration but omits the 4.0.6.0 interim-fix line. IBM's bulletin is the authority here and lists the six version lines reproduced in the card above.

One more thing that is not established, because nobody has tried to establish it: no mainstream news organisation or independent research lab appears to have published its own analysis of CVE-2026-18875. The only assessment on the public record that IBM did not write is CISA's three-field SSVC block. As of 26 October 2026 the coverage consists of IBM's bulletin, the CVE record, NVD, GitHub's advisory and a set of vulnerability trackers that reproduce IBM's text. Several search results on the CVE are blog posts of unclear provenance that read as machine-generated, some of them on sites that also publish cryptocurrency price widgets; none of them was used as a source here. There is no second, independent account of this bug.

The fix, and the gap after it

IBM's remediation is a version upgrade and nothing else: update FTM for Red Hat OpenShift deployments to 4.0.11.0, first fix at support node 7285661, with no interim workaround offered. That last point is the practically important one. When a vendor publishes "None" under workarounds, an operator who cannot move to 4.0.11.0 on a payments schedule is left with only the measures the vendor did not write down — restricting who can reach the agent server's runbook interfaces, which Redbot Security recommends and IBM does not.

The stakes are set by what FTM is. IBM describes it as "a unified payments hub that securely processes, monitors and manages all payment types including batch and real-time models," with ISO 20022 support for processing and routing transactions, and a companion SWIFT product for certified SWIFT connectivity. IBM's product page also markets an FTM AI Assistant, an "agentic, gen AI-powered conversational interface" covering payments, approvals, system performance and documentation. The advisory names an "FTM AI agent server" as the location of the flaw and says nothing about how that server relates to the assistant on the marketing page. Anyone drawing an architecture diagram from the two documents together is guessing.

The design lesson Redbot draws from the case is the one that survives the patch: keep retrieved content out of the authority path. Its recommendations are that runbook creation, replacement and deletion require authentication, approval and attribution; that retrieved runbooks never be allowed to authorise payments, widen transaction scope or permit external data transfer on their own; and that the connected payment services enforce their own permissions regardless of how the agent interprets what it retrieved. Those are a threat-intelligence firm's recommendations, not IBM's commitments, and IBM's bulletin makes none of them.

Why the archive calls it medium

The record and the CVSS score are answering different questions, and the gap between them is the honest summary of this case. IBM's 7.3 is a HIGH-band score for a flaw that is trivially reachable. The archive records the entry as a vulnerability rather than an incident, with severity medium, real harm false, confidence A and no dispute flag, dated 23 September 2026 to the day and filed with a global region field. Those fields describe what happened, and what happened is nothing.

That combination is the point of the entry. A payment agent that read from a store anyone could write to is a serious piece of engineering, and it was fixed in a version upgrade before anyone is known to have used it. Both halves are true, and the record keeps them apart rather than letting the score or the silence do the talking alone.