CVE-2026-18154 is a high severity (CVSS 8.0) flaw in IBM Financial Transaction Manager for Red Hat OpenShift. A hard-coded or predictable cryptographic key can expose sensitive information to a remote attacker. IBM's bulletin lists no workaround and names FTM 4.0.11.0 as the fixed release.
What's affected
The IBM bulletin lists these releases as affected:
- 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 and 4.0.10.0
The fix is FTM 4.0.11.0. IBM scores the issue 8.0 with the vector AV:A/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:N, which matches the record: an adjacent network attacker, high attack complexity, and a changed scope. Related issues in the same bulletin are CVE-2026-18152 and CVE-2026-18153.
How to check if you're exposed
Confirm the FTM version on each OpenShift cluster:
oc get csv -A | grep -i transaction
Compare the result with the affected list. Anything below 4.0.11.0 in the 4.0.6 to 4.0.10 line is in scope.
Next, map which network segments can reach FTM. The attack vector is adjacent, so the exposure depends on who shares a segment with the service. Check network policies and any flat networks where FTM pods sit next to less trusted workloads.
What to do now
- Inventory FTM for OpenShift deployments and their versions.
- Upgrade to FTM 4.0.11.0 following IBM's upgrade notes.
- Tighten network policies so only the systems that need FTM can reach it.
- Assess data protected under the old keys, such as stored or in transit messages, and decide whether it needs re-protection under your policy.
- Track the three related CVEs together so none is left open.
- Document the upgrade in your change records, including the version before and after, so audits can confirm the fix later.
Why it matters
The weakness class is CWE-321, use of a hard-coded cryptographic key. The key is part of the product, so it is the same everywhere the product is installed. A person who can recover it once can decrypt or tamper with protected data on every deployment they can reach. Good key management means keys are generated per installation and kept out of the code.
The attack complexity is high and the attacker must be on an adjacent network, which tempers the score, but the impact on confidentiality and integrity is rated high. IBM does not state that the flaw is exploited, and the record's KEV flag is false.
Quick check
What does adjacent network mean here?
The attacker needs to be on the same shared segment as the target, not anywhere on the internet. Network segmentation therefore reduces exposure.
Is the fix the same as for the other two CVEs?
Yes. IBM names FTM 4.0.11.0 for all three.
Sources
Last reviewed: 18 October 2026.
