Who is affected

Only the outgoing connections an app makes over HTTPS, for example REST or web service calls, or other integrations with external systems are affected. Traffic coming in to an app, such as users opening it in a browser, is not affected.

What Mendix has done

Mendix has an automated pipeline that automatically scans the Mendix on Kubernetes base images for CVEs and rebuilds the latest release. On 23 Oct 2026, this pipeline rebuilt Mendix on Kubernetes 2.28.1 and the hi-1-jre{{.JavaVersion}}-entrypoint base image.

As of 23 Oct 2026, there's no officially available CVE patch for Red Hat UBI8 and UBI9 images. Once Red Hat provides an official patch, the automated pipeline will also rebuild ubi8-1-jre{{.JavaVersion}}-entrypoint and ubi9-1-jre{{.JavaVersion}}-entrypoint base Runtime base images.

Actions Required To Apply Fix

Upgrade to Mendix Operator 2.28.1 (or a later version) to ensure that all internal containers are running a patched version. If you use an air-gapped copy of Mendix Operator (including version 2.28.1) or Private Mendix Platform, make sure it's updated (downloaded on 23 October 2026 or later), and run a CVE scan on all images to confirm that the air-gapped images are not affected by this CVE.

Switching to hi-1-jre{{.JavaVersion}}-entrypoint is highly recommended:

• For namespaces configured with mxpc-cli, update OperatorConfiguration directly. 

• For namespaces configured with the Helm chart, set the Base OS Image Template to hi on the Operator Configutation tab.

As of 23 October 2026, staying on ubi8-1-jre{{.JavaVersion}}-entrypoint or ubi9-1-jre{{.JavaVersion}}-entrypoint  would mean that the official Red Hat CVE patch is not yet available and cannot be applied. Mendix on Azure environments are using ubi9-1-jre{{.JavaVersion}}-entrypoint and are affected, until an official patch becomes available.

After switching the base image, Mendix apps will need to be rebuilt and redeployed. The fix is added when the app is rebuilt, so apps that are already running only pick it up on a redeploy. A restart is not enough.

If an app makes outgoing calls to other systems, please redeploy it. Do this in the usual order for releasing changes (Test, Acceptance, then Production) and check that integrations still work before redeploying Production.

If an app does not make outgoing calls, no action is needed. It will receive the update at its next regular deployment.

A redeploy causes a short downtime while the app restarts, so plan it in a convenient window.

What to expect after redeploying

If one of the systems an app calls uses a certificate issued by one of the affected eMudhra authorities, the connection will now fail.

In that case, ask the owner of that system to replace its certificate.