CVE-2026-18095 is a High severity buffer overflow in IBM Financial Transaction Manager (FTM) for Red Hat OpenShift. A remote authenticated attacker could execute arbitrary code. It scores 8.5 with changed scope and high attack complexity. IBM's fix is FTM 4.0.11.0, with no workaround or mitigation offered.
What's affected
IBM Financial Transaction Manager (FTM) for Red Hat OpenShift, per IBM's bulletin 7288641 (published 21 September 2026):
- 4.0.6.0 through 4.0.6.0 iFix6
- 4.0.6.0 iFix6 Refresh (Operator 4.4.6+20260807.081800)
- 4.0.7.0
- 4.0.8.0
- 4.0.9.0
- 4.0.10.0
IBM's fix is FTM 4.0.11.0, and it lists no workarounds or mitigations. The bulletin is large: it lists more than 45 CVEs for FTM, and 4.0.11.0 is the remediation for all of them. This CVE is the buffer overflow item.
The record scores it 8.5 (High) with vector CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H. The vector is network, high attack complexity, low privileges and changed scope, with high impact on all three properties. IBM's bulletin gives the same 8.5.
How to check if you're exposed
Find the FTM version you have deployed. On OpenShift the operator is installed through Operator Lifecycle Manager, so list the installed operator versions and read the FTM entry.
oc get csv -A
oc get pods -A | grep -i ftm
The first command lists installed operator versions in every namespace. The second shows FTM pods, so you can confirm which namespaces hold FTM. If your deployment is below 4.0.11.0 it is in scope. Then count the accounts that can log in to FTM remotely, because the attack needs one.
What to do now
- Find every FTM deployment and its version.
- Upgrade to FTM 4.0.11.0.
- Limit remote FTM accounts to those needed, and remove shared or stale ones.
- Run FTM pods with the least privileges OpenShift allows, so that code execution in one pod reaches as little as possible.
- Read IBM's bulletin for the other CVEs that 4.0.11.0 fixes, and plan one upgrade, not many.
Why it matters
The record classes the weakness as CWE-787, Out-of-bounds Write. The record classes this as CWE-787, out-of-bounds write, and IBM calls it a buffer overflow. The program writes more data into a memory region than the region can hold, and the extra data lands in neighbouring memory. When an attacker controls that data, the outcome can be arbitrary code execution. IBM states that outcome here.
Two parts of the vector slow the attack. A valid account is needed, and attack complexity is high, which usually means conditions outside the attacker's control, such as timing or memory layout. Those are why it is rated 8.5 and not 9 or more. They are not guarantees. Memory corruption bugs have a long record of becoming reliable over time once people study them.
For defenders the sound response is to treat code execution on a payments platform as a priority and patch on a short timeline. Least privilege for pods is the secondary control: if code runs, it should find little to work with. The same bulletin holds other code execution items, so one upgrade covers all of them. The record does not report exploitation and CISA does not list the CVE.
Quick check
Why is attack complexity high?
The vector marks it so, which usually means the attack depends on conditions the attacker does not control. IBM does not list the conditions.
Does pod hardening help?
It limits what code execution can reach, but the real fix is upgrading to 4.0.11.0.
Sources
- IBM Security Bulletin 7288641: IBM Financial Transaction Manager, fetched 18 October 2026
Last reviewed: 18 October 2026.
