CVE-2026-18066 is a High severity server-side request forgery flaw in IBM Financial Transaction Manager (FTM) for Red Hat OpenShift. A local attacker could obtain sensitive information and trigger unauthorized actions. It scores 7.9 with changed scope. IBM's fix is FTM 4.0.11.0 and it lists no workaround.
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 server-side request forgery item.
The record scores it 7.9 (High) with vector CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:N. The vector is local, low complexity, high privileges required and changed scope, with high confidentiality and integrity impact. IBM's bulletin gives the same 7.9.
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 review network egress from FTM pods. Server-side request forgery uses the server's own network position, so egress rules are your main control.
What to do now
- Find every FTM deployment and its version.
- Upgrade to FTM 4.0.11.0.
- Apply OpenShift egress and network policies so FTM pods can reach only the hosts they need, and cannot reach cloud metadata addresses or internal admin services.
- Restrict who can sign in locally with high privileges, since the vector requires them.
- 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-918, Server-Side Request Forgery. In a server-side request forgery, the attacker makes the server send a request on their behalf. The server sits inside a trusted network and may reach internal services the attacker cannot. The record classes the weakness as CWE-918. IBM says the effect is that a local attacker could obtain sensitive information and trigger unauthorized actions.
The vector asks for high privileges and local access, so this is not a flaw an outsider uses to get a foothold. It is a way for someone already inside with strong rights to extend their reach. Changed scope in the vector reflects that the requests land on systems beyond FTM itself.
The main defence is also the cheapest: do not let application pods reach what they have no reason to reach. Egress policies in OpenShift, blocking of link-local metadata addresses and an allow list for outbound hosts shrink what an SSRF can touch. The same bulletin holds many other issues, so one upgrade covers them. The record does not report exploitation and CISA does not list the CVE.
Quick check
Why do egress rules help with SSRF?
The attack makes the server send requests. If the server cannot reach sensitive internal addresses, the request goes nowhere useful.
Is this exploitable from the internet?
The vector is local and needs high privileges, so an outsider would first need a foothold inside.
Sources
- IBM Security Bulletin 7288641: IBM Financial Transaction Manager, fetched 18 October 2026
Last reviewed: 18 October 2026.
