Siemens Mendix SAML Module Replay Flaw: Are Your Apps Affected?

At a glance (as of 3 November 2026, UK time)

Siemens ProductCERT published advisory SSA-137528 on 26 October 2026 for CVE-2026-89209, a weakness in the Mendix SAML module. CISA republished it on 29 October 2026 as ICS advisory ICSA-26-302-01. The module lets a Mendix application accept sign-ins from a company identity provider using SAML, the standard behind many single sign-on setups. The flaw: in one specific sign-in flow, a captured sign-in message can be used a second time.

The practical answer is short. Find out whether you run this module and which version. If it is below the fixed release, update it. If you cannot update straight away and your users do not need to start sign-in from the identity provider's own portal, switch off IdP-initiated sign-in in the meantime.

This page covers CVE-2026-89209 only. It concerns applications that have imported the SAML module, not the Mendix platform as a whole.

• Vendor and product: Siemens, Mendix SAML module (Mendix 9, 10 and 11 compatible releases)
• Affected: Mendix 10 and 11 compatible releases before V4.2.4; Mendix 9 compatible releases before V3.6.29
• Fixed: V4.2.4 or later (Mendix 10 and 11); V3.6.29 or later (Mendix 9)
• Severity: CVSS 3.1 base score 6.8 (Medium); CVSS 4.0 base score 7.6 (High), as scored by Siemens
• Exploitation: none reported in the sources we checked (see below)
• Immediate action: identify module versions, update, or disable IdP-initiated SSO as a stopgap

Who should check

You are in scope if you run, or pay someone to run, a Mendix application that signs users in through the Mendix SAML module. That includes internal tools, customer portals and supplier-facing apps. If your Mendix apps use a different sign-in method, this advisory does not apply to them. Siemens lists every module version below the fixed releases as affected, so there is no partial list of 'safe' older builds.

The module is a Marketplace component that gets imported into each app, so the version is a property of each app and each branch, not of your Mendix licence or hosting. An app that has not had its Marketplace modules updated in a while is the likely candidate. Whoever builds or maintains the app can confirm which release was imported. If the app was built by a supplier, ask them directly and ask for the answer per app.

The exposure also depends on configuration. Mendix documents that the module does not allow IdP-initiated sign-in by default; it is a deliberate option an administrator ticks. Siemens' workaround is to disable that mode, which strongly suggests that apps with it off are not exposed through this route. That is our inference from the vendor's wording rather than a statement in the advisory, so do not treat it as a reason to skip the update.

What the flaw allows and how serious it is

With SAML there are two ways to start. In the normal flow the user opens your app, which sends them to the identity provider and then accepts the reply it was expecting. In IdP-initiated sign-in the user starts at the identity provider (for example a tile in a staff portal) and the identity provider sends a response to the app unprompted. Because the app did not ask for that response, it has less to compare it against.

Siemens says affected versions do not properly protect against replay in this flow. An unauthenticated attacker who obtains a valid SAML response could submit it again and gain access to the application as the user it was issued for. That is assertion replay.

The scores reflect a real but conditional problem. Both Siemens vectors give high attack complexity and no privileges needed, and the CVSS 3.1 vector requires user interaction. Impact on confidentiality and integrity is rated high. In plain terms: the attacker needs a genuine, captured sign-in message first, which is not trivial, but if they get one the result is access as that user. How bad that is depends on what the account can do in your app.

Severity is not likelihood. The CVE record we checked showed an EPSS score under 1% and a CISA SSVC assessment of exploitation 'none', and it was not in CISA's Known Exploited Vulnerabilities catalogue. These are context, not guarantees.

Stopgap: disable IdP-initiated sign-in

Do this only if you cannot update promptly. It is Siemens' only listed mitigation, and it is a configuration change to a live sign-in path, so treat it as one.

You need administrator access to the app's SAML configuration. Mendix's documentation describes the option as 'Allow IdP-Initiated Authentication' within the identity provider configuration (on the Request Authn Context tab in the module's admin screen), unticked by default. Labels can differ between module versions, so go by what your installed version shows.

The impact: anyone who currently signs in by clicking a tile or link in the identity provider portal will stop being able to do so. They must start from your application's address instead. Mendix notes this option is sometimes needed because some identity providers cannot pass the information the app-initiated flow relies on, so test with a real account before assuming everyone can still get in.

1. Make a note of the current setting for each identity provider entry in the app, so you can restore it if sign-in breaks.
2. Open the app's SAML administration screen as an administrator, edit the identity provider configuration and untick Allow IdP-Initiated Authentication. Save the change. Mendix documents that releases before 4.1.0 needed an app restart for configuration changes, so allow for that on older versions.
3. Sign in as a normal user by opening the application's own address. This should still work and take you through your identity provider.
4. Try signing in from the identity provider portal tile. It should now be refused or fail. That confirms the mode is off and tells you whom to warn about the change in how they sign in.

Update the module to the fixed release

The proper fix is a new module release, imported into the app, then rebuilt and redeployed. Siemens gives the Marketplace component as the download location. The change is a code update to your application, so it goes through whatever test and release process the app already has. If you have a non-production environment, use it first.

Pick the line that matches the Mendix version of the app. For Mendix 9 compatible apps the fix is V3.6.29 or later; do not jump to 4.x just to be current, because Mendix documents that moving from 3.x to 4.x changes the admin screen and user provisioning. For Mendix 10 and 11 compatible apps it is V4.2.4 or later. Mendix also warns not to upgrade the UserCommons module to V3.0.0 for the SAML module, so avoid updating dependencies blindly alongside it.

1. Have the app developer open the app in Studio Pro and update the SAML module from the Marketplace to the fixed release for your Mendix version, following Mendix's guidance for using Marketplace content. Check the release's compatibility notes first.
2. Rebuild and test locally or in a non-production environment. Check that app-initiated sign-in works, that user provisioning behaves as before and that any custom sign-in microflows still run.
3. Deploy to production through your normal release route. The application restarts as part of deployment, so choose a time that suits your users.
4. Once deployed, if you turned off IdP-initiated sign-in as a stopgap and your users need it, decide deliberately whether to re-enable it. The updated module is the vendor's fix for the replay problem, but the advisory does not say it was otherwise redesigned, and app-initiated sign-in remains the more conservative route.

Check it worked and look back

Confirm with the developer or supplier that each affected app now runs V4.2.4 or later (Mendix 10 and 11) or V3.6.29 or later (Mendix 9), and that the production deployment really contains that build. A patch available from the vendor is not the same as a patch running in your estate, so ask for the version per application and environment.

Updating does not undo anything that already happened. The weakness existed in earlier releases before the advisory, so if an app holds sensitive data, ask your identity provider administrator and app owner to review sign-in activity for unexpected sessions, especially IdP-initiated sign-ins that cannot be matched to a user's own activity. We cannot give a specific log signature for this flaw because Siemens does not publish one, so a broad review against what users actually did is the realistic approach. If something looks wrong, treat it as a security incident for that app and involve whoever handles incident response.

Exploitation and real-world reporting

The Siemens advisory and CISA's republication do not state that this vulnerability is being exploited, and neither mentions public exploit code. The CVE record data we checked did not list it in CISA's Known Exploited Vulnerabilities catalogue. We found no credible public report naming any organisation affected by it. Absence from those sources does not prove it has never been abused, so patch on the basis of exposure, not on the absence of headlines.

The National Vulnerability Database entry was marked Deferred when we checked, meaning NVD had not completed its own analysis. Siemens is the authoritative source for the version ranges. CISA says it republished the Siemens advisory as received and directs questions to Siemens ProductCERT.

This is a separate issue from the earlier Mendix SAML module account hijacking vulnerability CVE-2026-80465 (SSA-887643). If your module is older than the versions above, you may be affected by both, and updating to the fixed releases here is the sensible move.