CVE-2026-17644 is a High severity flaw in IBM Financial Transaction Manager (FTM) for Red Hat OpenShift. The product uses hard-coded credentials, so a local attacker could gain unauthorized access to sensitive information and modify transaction data. It scores 8.8. IBM's fix is FTM 4.0.11.0, with 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 hard-coded credentials item.
The record scores it 8.8 (High) with vector CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H. The vector is local, low complexity, low privileges, with changed scope and high impact on all three properties. IBM's bulletin gives the same 8.8.
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. Also find out which accounts and services in your cluster can reach FTM components from inside, since the attacker is local.
What to do now
- Find every FTM deployment and its version.
- Upgrade to FTM 4.0.11.0.
- Limit who and what can run inside the FTM namespaces, and review service accounts that can reach FTM services.
- Ask IBM how to confirm that built-in credentials were replaced after the upgrade, because the bulletin does not describe that step.
- 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-798, Use of Hard-coded Credentials. A hard-coded credential is a username and password, or a key, written into the product itself. Every installation shares it, and anyone who can read the software, or work out its value, holds a working login. The record classes the weakness as CWE-798. It cannot be rotated by the customer, which is the core of the problem and why the fix has to come from the vendor.
IBM says the consequences are unauthorized access to sensitive information and modification of transaction data. For software that handles payments, changing data is the more worrying half. The attacker still has to be local, in the sense described above, which narrows the practical audience to people or workloads already inside the cluster.
It is a recurring bug class and a good candidate for automated detection. Secret scanning of source and container images catches many cases before release, and scanning what you deploy catches some after. For customers, the practical steps are the same as for any vendor credential flaw: take the fixed release and reduce who is inside. The record does not report exploitation, and CISA does not list the CVE.
Quick check
Can I change the hard-coded credential myself?
The record does not say so. A hard-coded value is built into the product, which is why IBM's remedy is a new release.
Does the attacker need to be remote?
No. The vector is local, which on OpenShift means access to run code or commands inside the environment.
Sources
- IBM Security Bulletin 7288641: IBM Financial Transaction Manager, fetched 18 October 2026
Last reviewed: 18 October 2026.
