Fixes released for SAML signature verification flaw in Siemens Mendix SAML module

What happened

CISA published an ICS advisory covering a vulnerability in the Siemens Mendix SAML module, the component Mendix applications use to act as a SAML service provider for single sign-on [1]. Affected versions do not properly validate the signature on a SAML response. According to the advisory, this could allow an unauthenticated remote attacker to hijack an account session in specific SSO configurations [1].

The issue is tracked as CVE-2026-80465 and classified as improper verification of a cryptographic signature [1]. The advisory states that Mendix has provided fix releases for the module and recommends updating to the latest version [1]. CISA lists Siemens as the vendor; Mendix is a Siemens company [1].

There is no indication in the advisory that the flaw has been exploited, and it is not listed in CISA’s Known Exploited Vulnerabilities catalogue. Signature-validation bugs in SAML implementations are well understood as a class, and the remedy here is a module update rather than an architectural change.

Who is affected

Per the advisory, the affected products and versions are [1]:

• Mendix SAML (Mendix 10 compatible) — all versions below 4.2.3
• Mendix SAML (Mendix 11 compatible) — all versions below 4.2.3
• Mendix SAML (Mendix 9.24 compatible) — all versions below 3.6.27

CISA lists the deployment footprint as worldwide, with Critical Manufacturing and Information Technology named as the relevant critical infrastructure sectors [1]. Siemens is headquartered in Germany [1].

The important scoping detail is that exploitation depends on the SSO configuration. The advisory refers to specific SSO configurations but does not enumerate which ones [1]. If you run Mendix applications with SAML login, treat yourself as in scope until you have confirmed otherwise against Siemens’ own advisory, because nothing in the public CISA text lets you rule a configuration out.

The advisory does not describe how the module is distributed or how the update reaches deployed applications, so we cannot say from the sources whether patching is a platform-level or per-application task. Confirm that against Siemens’ and Mendix’s own documentation before planning the rollout.

How it works

The sources support only a narrow description. In a SAML single sign-on flow, the identity provider returns an assertion about the user, and the service provider is responsible for verifying the cryptographic signature on that response before trusting its contents. In the affected module versions, that validation is not performed properly [1]. An attacker able to present a crafted or modified SAML response to the application may therefore be able to have it accepted and obtain a session belonging to another account, in the configurations the advisory describes [1].

The advisory does not describe the specific validation gap — whether the flaw involves an unsigned response, a wrapped assertion, a mismatched reference, or another mechanism — and no proof-of-concept detail is published in the source. We are not going to speculate beyond what is stated.

On scoring, the sources differ. The CISA advisory page presents a CVSS v3 figure of 8.7 for the affected equipment [1], while the CVE record carries a CVSS v4 score of 8.8 with vector CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:P/VC:H/VI:H/VA:N/SC:H/SI:H/SA:N. Both land in the same band. Our computed severity for this issue is high.

The v4 vector is worth reading closely: network attack vector with no privileges required, but high attack complexity, an attack requirement, and passive user interaction. On its face that describes something more conditional than a point-and-shoot remote takeover, though no source describes the attack path, so the operational preconditions remain unstated. The vector also indicates subsequent-system impact, which is consistent with an account-hijack outcome where the session grants access downstream of the application.

What to do

• Inventory every Mendix application in your estate that uses the Mendix SAML module, including internally built apps and anything delivered by a partner or contractor, and record the module version in each.
• Update the module to 4.2.3 or later for Mendix 10 and Mendix 11 compatible builds, and to 3.6.27 or later for Mendix 9.24 compatible builds [1].
• Check Siemens’ and Mendix’s own documentation for how the updated module is applied to already-deployed applications; the CISA advisory does not say.
• Read Siemens’ advisory (linked from the CISA page) for configuration specifics before you conclude that a given app is unaffected. The public CISA text does not enumerate the vulnerable SSO configurations [1].
• Review authentication logs for the affected applications for sessions established without a corresponding, expected identity provider event, and for logins from unusual sources. Retain the logs before they roll off.
• For applications you cannot patch immediately, restrict network reachability of the SSO endpoints to known networks and treat any externally exposed instance as the priority.
• Once patched, force a session reset on the affected applications so that any pre-existing hijacked session is invalidated.
• Confirm your identity provider enforces short assertion lifetimes and audience restrictions. These do not fix the bug, but they reduce the value of a replayed or crafted response.