CVE-2022-43916 is a medium severity (CVSS 6.8) flaw in IBM App Connect Enterprise Certified Container: some pods used for internal infrastructure do not restrict network egress. IBM says to upgrade the operator to 12.8.0 or higher, or to 12.0.8 or higher on the 12.0 LTS stream, and to update all components.
What's affected
IBM App Connect Enterprise Certified Container versions 7.1, 7.2, 8.0, 8.1, 8.2, 9.0, 9.1, 9.2, 10.0, 10.1, 11.0, 11.1, 11.2, 11.3, 11.4, 11.5, 11.6, 12.0, 12.1, 12.2, 12.3, 12.4, 12.5, 12.6 and 12.7. The record also lists Red Hat OpenShift as an affected product, because the containers run there.
IBM's bulletin describes the issue as pods used for internal infrastructure that have unnecessary external network access. IBM also lists the weakness as CWE-264 where the NVD record uses CWE-923, and scores it 6.8 in its bulletin.
Fixes per IBM:
- Continuous Delivery up to 12.7.0: upgrade the App Connect Enterprise Certified Container Operator to version 12.8.0 or higher, and ensure all components are at 13.0.2.1-r1 or higher.
- 12.0 LTS: upgrade the operator to 12.0.8 or higher, and ensure all components are at 12.0.12-r8 or higher.
IBM lists no workarounds or mitigations.
Two points about the version list. First, it is long because the flaw is in how the operator lays out pods and policies, so it has been present across every release stream IBM names. Second, IBM splits the fix by stream, so a team on Continuous Delivery and a team on 12.0 LTS need different target versions. Mixing them up is the most likely way to leave a gap.
If you run App Connect on a platform other than the OpenShift setup the record names, read the bulletin for how it applies to your deployment.
How to check if you're exposed
Find the operator and component versions in your cluster. In the OpenShift console, open the installed operators view and read the App Connect operator version. From the command line:
oc get csv -n <operator-namespace>
Then list the images used by your integration server and other App Connect pods so you can compare them with IBM's fixed component levels:
oc get pods -n <namespace> -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.containers[*].image}{"\n"}{end}'
Follow IBM's upgrade documentation for the operator, and check the bulletin for the exact component version for your stream.
Also review network policies in the namespace. A pod with no egress policy can reach anywhere the cluster network allows.
For a fleet view, export the list of clusters and operator versions from your platform tooling, and compare each against the two fixed streams listed earlier in this post. Keep the output with your change record so that you can show which clusters were upgraded and when.
What to do now
- Identify which App Connect operator version and release stream you run: Continuous Delivery or 12.0 LTS.
- Plan the operator upgrade IBM specifies: 12.8.0 or higher for Continuous Delivery, or 12.0.8 or higher for 12.0 LTS.
- After upgrading the operator, make sure all components reach the fixed levels in the bulletin: 13.0.2.1-r1 or higher, or 12.0.12-r8 or higher.
- Add your own Kubernetes network policies that deny egress by default and allow only the destinations that each workload needs. IBM lists no workaround, but a deny by default policy limits impact in general.
- Scan your container images for known issues, and include the infrastructure pods in your review.
Why it matters
The record uses CWE-923 (Improper Restriction of Communication Channel to Intended Endpoints). In plain terms, pods that exist for internal plumbing can open connections to the outside when they have no need to. Network egress is easy to ignore, because blocked inbound traffic gets all the attention. But outbound access is how a compromised workload sends data out or pulls tools in.
The CVSS vector shows high attack complexity and low privileges needed, which is why the score is medium. Still, the gap compounds with other issues. A container with a small flaw and free outbound access is more dangerous than the same container confined by policy.
The lasting fix is a habit rather than a patch: define what each pod may talk to, and deny the rest. Kubernetes network policies and service mesh rules exist for this. The record does not mark this CVE as CISA KEV and makes no claim of exploitation in the wild.
IBM's version matrix is detailed because operators and components upgrade separately, and it is easy to upgrade one and forget the other. Check both.
Try it yourself
Image scanning shows what is inside the containers you run, and which components have known issues. This demo walks through it.
Click through it at your own pace, or open it full screen.
Quick check
Which versions fix this?
Per IBM: operator 12.8.0 or higher with components at 13.0.2.1-r1 or higher on Continuous Delivery, or operator 12.0.8 or higher with components at 12.0.12-r8 or higher on 12.0 LTS.
Is there a workaround?
IBM lists none. A deny by default egress network policy still reduces risk, but it is not an IBM supplied fix.
Sources
Last reviewed: 19 October 2026.
