Decoding the world of cybersecurity

Siemens fixes Mendix SAML assertion replay weakness

Siemens has published corrected Mendix SAML modules after identifying inadequate replay protection in certain identity-provider-initiated sign-in flows, exposing applications that accept captured authentication assertions.

Siemens fixes Mendix SAML assertion replay weakness
Summary
  • CVE-2026-89209 requires an attacker to possess a suitable valid SAML assertion.
  • Mendix 9-compatible modules require version 3.6.29; Mendix 10 and 11 require 4.2.4.
  • The vulnerability does not establish unrestricted anonymous access or confirmed attacks.

Siemens has disclosed an authentication weakness in the Mendix SAML module that could allow an attacker to reuse a captured sign-in assertion and obtain access to a business application without completing a fresh authentication process.

The flaw, CVE-2026-89209, affects specified versions of the module used to connect Mendix applications to corporate identity providers. Siemens published ProductCERT advisory SSA-137528 on 26 October 2026 and identified corrected module releases.

Mendix is a low-code development platform used to build business applications and interfaces linking organisational systems. Companies frequently connect these applications to existing identity infrastructure so employees and partners can sign in through centrally managed accounts.

Security Assertion Markup Language, or SAML, is one of the standards used to support that integration. After authenticating a user, an identity provider creates a signed assertion that the application can check before granting access.

The arrangement reduces the need for separate application passwords, but it still depends on the receiving application enforcing the proper rules for the assertion. Those include checking its integrity, intended use and whether the authentication response can legitimately be accepted again.

Siemens found that affected versions of the Mendix module did not adequately prevent replay during identity-provider-initiated authentication. In this type of flow, the sign-in begins at the identity provider, which directs the authenticated user towards the target application.

If an attacker obtains a suitable valid assertion, the vulnerable application may accept it again, allowing unauthorised access. This is different from a defect that allows an arbitrary person to invent an identity without first obtaining authentication material.

The attack therefore requires access to a relevant response and depends on the application using the affected module and sign-in configuration. It does not imply that every application using SAML is exposed or that a compromised identity provider is a prerequisite.

Siemens rates the issue at 6.8 under CVSS v3.1 and 7.6 under CVSS v4.0. Those values use different scoring methodologies; they do not describe a change in the vulnerability's behaviour since publication.

For Mendix 9-compatible SAML modules, releases earlier than 3.6.29 are affected and version 3.6.29 provides the fix. For Mendix 10 and Mendix 11-compatible modules, versions earlier than 4.2.4 are affected, with 4.2.4 providing the correction.

The versions refer to the SAML module rather than the core Mendix application platform. Updating an application's runtime does not necessarily update every component packaged within the application, particularly where independently selected marketplace modules remain installed.

This can complicate inventory work in organisations where different business units maintain separate low-code applications. Several deployments may share one identity provider while using different versions of the authentication module.

The correct remediation assessment consequently requires identifying the modules contained in the deployed applications and determining which authentication flows they actually permit. A module version listed as vulnerable is not proof that the relevant attack path is externally reachable in a particular installation.

The incident highlights that cryptographic signing alone does not guarantee the secure handling of authentication. A genuine signed assertion can still be abused if an application does not establish whether it is fresh, intended for the right recipient and acceptable within the current session.

Corporate identity systems also spread responsibility across teams. A central identity administrator can secure the provider while an individual application owner retains a vulnerable integration. Preventing replay therefore depends on enforcement at the consuming application as well as the authentication service.

Identity-provider-initiated SAML is one of several patterns available when integrating enterprise sign-in. Its use may reflect decisions made when an application was originally deployed and remain unchanged during subsequent upgrades. Checking only the configuration of the central identity provider may therefore miss a vulnerable application module that handles an incoming assertion differently from other services.

Siemens has not reported confirmed exploitation of this vulnerability in production customer environments. Its advisory provides fixed module versions and a defined authentication scenario, rather than evidence of an ongoing attack campaign.

×