Siemens on August 14, 2025, disclosed a critical vulnerability in its Mendix SAML module that could allow unauthenticated attackers to bypass cryptographic signature verification and hijack user accounts. Tracked as CVE-2025-40758 and assigned a CVSS v3.1 base score of 8.7, the flaw affects multiple versions of the widely used single sign-on component. The U.S. Cybersecurity and Infrastructure Security Agency (CISA) republished the advisory as ICSA-25-231-02 on August 19, underscoring the urgency for industrial and enterprise Windows shops.

What is Mendix SAML and Who is Affected?

Mendix is a low-code application development platform used to build enterprise web applications, many of which rely on single sign-on via the Security Assertion Markup Language (SAML) protocol. The Mendix SAML module bridges these apps to identity providers like Active Directory Federation Services (AD FS), Okta, or Azure AD. This vulnerability, however, puts that trust at risk.

Three distinct module tracks are impacted, each tied to a specific Mendix runtime generation:
- Mendix 9.24 compatible: all versions before 3.6.21
- Mendix 10.12 compatible: all versions before 4.0.3
- Mendix 10.21 compatible: all versions before 4.1.2

The fixed versions are 3.6.21, 4.0.3, and 4.1.2 respectively. Any Mendix application using an earlier release of these SAML modules is vulnerable in SSO configurations that lack encryption or otherwise fail to enforce signature binding checks. Third-party vulnerability trackers, including Tenable and Security Vulnerability, corroborate this version list and severity rating.

Technical Breakdown: How the Signature Bypass Works

At its core, CVE-2025-40758 stems from improper verification of cryptographic signatures, classified under CWE-347. Normally, when a user logs in via SAML, the identity provider (IdP) sends a digitally signed assertion to the service provider (SP). The SP—here, the Mendix application—must verify that signature and validate the message’s binding, audience, destination, and relay state to prevent tampering.

The affected Mendix SAML module, according to Siemens, does not “sufficiently enforce signature validation and binding checks.” This omission means an attacker can craft a SAML message that appears legitimate but lacks a valid signature, or otherwise violates the protocol’s trust model. If the SP accepts such a message, it could authenticate the attacker as a chosen user—effectively hijacking the account without ever knowing a password.

The CVSS vector reveals important details: the attack requires no authentication and can be launched remotely (network vector), but attack complexity is rated high. That high complexity reflects the need for specific SSO topologies (for example, IdP-initiated flows where the SP skips revalidation), possible misconfigurations, and the attacker’s ability to deliver a forged SAML response to the SP endpoint. Nonetheless, the potential impact—complete account takeover—merits the 8.7 score and urgent response.

Why Windows and Enterprise Administrators Must Act Now

Mendix applications frequently run on Windows Server infrastructure, often integrated with domain authentication and accessing sensitive internal resources. A SAML-based account compromise can open the door to lateral movement, privilege escalation, and data exfiltration across Windows networks.

CISA specifically calls out Critical Manufacturing as a sector at risk. In an industrial or manufacturing context, a hijacked Mendix session could grant attackers access to control panels, engineering dashboards, or backend services that operate critical processes. Even in corporate environments, the breach could expose file shares, databases, and administrative consoles tied to the compromised identity.

Windows administrators should treat this as a high-priority alert. The flaw’s remote exploitability, combined with the growing tendency to expose SSO endpoints to the internet (sometimes unintentionally via application gateways), raises the stakes for any organization running unpatched Mendix instances.

Immediate Mitigation: Inventory, Encrypt, Restrict

Before patching, operators can lower their risk with these same-day actions:

  • Identify all Mendix applications and check their SAML module version. Use Mendix Studio Pro or runtime logs to locate the exact version. Pay special attention to applications exposed to the internet or critical operations.
  • Enable UseEncryption on SAML configurations. Siemens notes that encryption of assertions or responses serves as a temporary barrier against the attack, even before upgrading the module. This is not a substitute for patching, but it raises the bar for exploitation.
  • Restrict network access to SAML endpoints. Place Mendix hosts behind firewalls, web application firewalls, and VPC security groups. Block direct internet access to management interfaces and SAML consumer URLs.
  • Increase monitoring of authentication logs. Look for unusual Issuer fields, missing signatures, unexpected relay state values, or multiple SSO failures from unfamiliar IP ranges.

Patching: Test, Deploy, Verify

Patching is the definitive fix. Siemens has made the updated modules available, and operators should follow this path:

  1. Download the correct fixed version from the Mendix Marketplace: 3.6.21, 4.0.3, or 4.1.2, depending on your Mendix runtime track.
  2. Test in a staging environment against all identity provider configurations. Verify both HTTP-POST and HTTP-Redirect bindings, single logout, and forced re-authentication workflows. Negative tests should confirm that tampered signatures and mismatched destinations are rejected.
  3. Roll out progressively from development to production. If multiple application environments share the same IdP, coordinate the upgrade to avoid authentication disruptions.
  4. Post-patch validation should include synthetic logins, checking that signature enforcement and binding checks are active, and that encryption configurations persist as intended.

Hardening SAML for the Long Term

Beyond this specific CVE, SAML implementations have a history of similar flaws across vendors. A disciplined security posture around federated authentication can prevent future incidents:

  • Require signed assertions and/or signed responses, depending on your IdP’s capabilities.
  • Pin IdP metadata or validate it through a signed source. Do not accept dynamic metadata updates without a controlled pipeline.
  • Enforce strict destination and audience checks on incoming assertions.
  • Validate RelayState length and semantics; reject unexpected or arbitrary values.
  • Use short-lived assertions (tight NotOnOrAfter windows) and validate them rigorously.
  • Rotate certificates on a schedule and monitor expirations.
  • Prefer OIDC where possible. Mendix documentation itself notes that OIDC is a more modern, simpler alternative to SAML. Migrating to OIDC can reduce the attack surface and avoid recurring SAML pitfalls.

Detection and Incident Response Playbook

If a breach is suspected, the following steps can help contain and investigate:

  • Search logs for anomalous SAML flows: unsigned assertions, unexpected Issuer URIs, unusual RelayState patterns, or assertions with mismatched audiences.
  • Correlate with network and VPN logs to identify potential source IPs and lateral movement attempts.
  • Immediate isolation of the affected Mendix application instances.
  • Revoke sessions and force re-authentication for potentially compromised accounts. Rotate SP keypairs and inform IdP operators of the need to invalidate any related trust.
  • Preserve forensic evidence for legal or regulatory follow-up.
  • Report exploitation to national CERTs or CISA, per the advisory guidance, to aid broader threat intelligence.

What’s Next for the Mendix Ecosystem?

Siemens has not reported any active exploitation of CVE-2025-40758 at the time of disclosure, but the combination of publicly known techniques and high-value targets makes it a prime candidate for future weaponization. History shows that attackers frequently target SSO components; SAML-related CVEs in products like VMware, Atlassian, and Microsoft ADFS have led to widespread attacks within weeks of disclosure.

Mendix administrators should not wait for a proof-of-concept to appear. The mitigation and patching steps are straightforward and have been validated by both the vendor and third-party security organizations. The advisory also serves as a reminder that federated authentication components are mission-critical assets that deserve the same level of attention as any core operating system patch.

Prioritized Action List

  1. Inventory: Catalog all Mendix applications and their SAML module versions immediately.
  2. Mitigate: Enable UseEncryption and lock down network access to SAML endpoints.
  3. Patch: Upgrade to fixed versions as soon as testing permits, prioritizing public-facing and critical applications.
  4. Monitor: Boost authentication logging and watch for anomalous SAML activity for at least 30 days post-patch.
  5. Harden: Reevaluate SAML configurations, implement the hardening checklist, and plan an OIDC migration where feasible.

The Siemens ProductCERT advisory (SSA-395458) and CISA’s republication (ICSA-25-231-02) provide all the version specifics and configuration guidance needed. By acting on these recommendations, Windows and enterprise teams can close this high-severity SAML hole before it becomes an incident.