Siemens has fixed CVE-2026-89209 in the Mendix SAML module. With a copy of a valid SAML response, a remote attacker holding no credentials could get into an app. The exposure centers on IdP-initiated SSO, so the first question for any Mendix app is whether that option is turned on.
What happened
Siemens ProductCERT published SSA-137528 on October 26, 2026, and CISA republished it as ICS advisory ICSA-26-302-01 on October 29. The advisory describes the flaw this way:
"Affected versions of the module do not properly protect against SAML assertion replay in IdP-initiated authentication flows."
The weakness is classed as CWE-294, authentication bypass by capture-replay. CISA lists a CVSS v3.1 score of 6.8 (medium), with high attack complexity and required user interaction. Siemens also lists a CVSS v4.0 score of 7.6. Neither advisory says the flaw is being exploited.
| Product | Affected | Fixed |
|---|---|---|
| Mendix SAML (Mendix 9 compatible) | Before V3.6.29 | V3.6.29 or later |
| Mendix SAML (Mendix 10 compatible) | Before V4.2.4 | V4.2.4 or later |
| Mendix SAML (Mendix 11 compatible) | Before V4.2.4 | V4.2.4 or later |
Siemens recommends updating. Its one specific mitigation for teams that can't update yet is to disable IdP-initiated SSO.
Why it matters
A SAML response is a bearer artifact for the login it represents. If a service provider will accept the same one twice, anyone who gets a copy can use it to sign in as that user, without the password or MFA the IdP originally checked.
IdP-initiated flows are where this tends to go wrong. In an SP-initiated login, the request ID comes back as InResponseTo, which ties the response to a request the application actually made. An unsolicited response has no such request to match. The OWASP SAML Security Cheat Sheet calls this flow inherently less secure and says implementations that keep it should do explicit replay detection at the response or assertion level. This advisory describes that control being inadequate.
Mendix's documentation shows the contrast. Out of the box, the module rejects unsolicited requests: the app itself starts the login, and RequestID and RelayState stay consistent across the exchange. Its troubleshooting guide describes an error for messages that don't match a generated ID or were already answered. That default suggests the apps most at risk are those where someone enabled IdP-initiated login, for example to support an IdP that can't pass RelayState. The advisories don't spell that out, though, so verify each app and update regardless.
The advisory doesn't say how an attacker would obtain a valid response. The high complexity and user interaction ratings help explain the medium score, but a successful replay still means access to the app as that user.
What to check in your environment
- Inventory the apps. Ask Mendix developers and business app owners which apps include the SAML module and which version, then compare against V3.6.29 for Mendix 9 and V4.2.4 for Mendix 10 and 11. Low-code apps can sit outside the normal patch process, so don't rely on infrastructure scans alone.
- Update from the Mendix Marketplace. Plan the update per app, starting with internet-reachable apps and those handling sensitive data.
- Check the IdP-initiated setting. In each app's IdP configuration, review
Allow IdP-Initiated Authentication. For deploy-time configuration, check theAllowIdpInitiatedAuthenticationvalue, which Mendix documents as false by default. - Make the mitigation stick. Mendix warns that constant values overwrite runtime screen changes when the app restarts. If an app uses constants, change it there, or the setting can return.
- Test before disabling. Find out who relies on IdP-launched access, such as portal or app launcher tiles, and move them to start from the app URL. Mendix documents "Unable to complete the request" as the error to expect when a message has no matching RequestID or RelayState.
- Tighten the IdP side. For these app integrations, review response lifetime and assertion validity. OWASP recommends short response lifetimes to limit how long a captured message stays useful.
- Look for retained SAML messages. OWASP warns that cached protocol messages can be replayed. Check whether proxies, debug tooling or support captures store SAML responses.
- Review login records. The module's
Log SAML Requestssetting stores requests and login attempts. If it's on, review recent activity for sign-ins that don't fit the user's pattern. The advisory publishes no indicators, so treat this as a lead rather than proof either way.
References
- CISA: ICS Advisory ICSA-26-302-01, Siemens Mendix SAML Module
- Siemens ProductCERT: SSA-137528, Authentication Bypass in Mendix SAML Module
- Mendix Marketplace: SAML module
- Mendix: Reference Guide for SAML IdP Configuration
- Mendix: SAML Installation and Configuration
- Mendix: Advanced SAML Configuration and Troubleshooting
- OWASP: SAML Security Cheat Sheet