CVE-2026-89209: Siemens Mendix SAML Authentication Bypass — Detection and Remediation Guide

On October 28, 2025, CISA published ICS Advisory ICSA-26-302-01 disclosing a high-severity authentication bypass vulnerability in the Siemens Mendix SAML Module. Tracked as CVE-2026-89209 and assigned a CVSS v3 score of 6.8, the flaw is an Authentication Bypass by Capture-replay (CWE-294) that could allow an unauthenticated remote attacker to gain unauthorized access to Mendix applications by replaying a valid SAML assertion during Identity Provider (IdP)-initiated authentication flows.

Mendix is Siemens' low-code application development platform. It is widely deployed across enterprises—and critically, within Critical Infrastructure sectors—to rapidly build and host business applications. The SAML Module is the standard component used to integrate these applications with corporate Single Sign-On (SSO). A vulnerability in this trust boundary is a direct threat to every application that relies on it for authentication.

Siemens has released patched versions and urges immediate updates. For defenders, this is not a drill: an authentication bypass in an SSO module undermines the foundational security model of your application stack. If your organization uses Mendix with SAML-based SSO, you must assume that any assertion captured—via logs, proxies, or a compromised endpoint—could be replayed to impersonate a legitimate user until you patch.

Technical Analysis

Affected Products and Versions

The vulnerability affects the Mendix SAML Module across three supported Mendix platform versions. The following versions are vulnerable:

Vulnerability Mechanics (Defender's View)

The flaw is classified as CWE-294: Authentication Bypass by Capture-replay. In a properly implemented SAML flow, an assertion issued by the IdP contains elements designed to prevent reuse, such as:

• NotOnOrAfter conditions (timestamps)
• A unique ID attribute
• An AudienceRestriction specifying the intended Service Provider (SP)
• A Recipient attribute matching the SP's assertion consumer service URL
• A OneTimeUse policy or an assertion SubjectConfirmationData with InResponseTo for SP-initiated flows

In IdP-initiated flows, the authentication process begins at the IdP, which then pushes an unsolicited SAML assertion to the SP (the Mendix application). The Mendix SAML Module, in vulnerable versions, fails to properly validate the uniqueness and freshness of these incoming assertions. This means an attacker who obtains a valid assertion—either through interception (e.g., in a log, a proxy, a compromised endpoint, or a misconfigured SAML tracer) or by phishing a user—can replay that assertion directly to the Mendix application's SAML endpoint. The module will accept it as legitimate, creating an authenticated session for the attacker without requiring any credentials.

Exploitation Requirements:

• The attacker must possess a valid, unexpired SAML assertion for the target Mendix application.
• The application must be configured for IdP-initiated SSO (the module's vulnerable path).
• Network access to the Mendix application's SAML assertion consumer service (typically a URL like /saml/assertion or similar).

Exploitation Status

As of the publication of this advisory (October 28, 2025), there are no public reports of in-the-wild exploitation and no known public Proof-of-Concept (PoC) code. The vulnerability was discovered and reported by Siemens' internal ProductCERT. However, the tactic of SAML assertion replay is a well-understood attack vector. The absence of a public PoC does not equate to safety; it simply means the barrier to entry is obtaining a valid assertion, which can be accomplished through various means (e.g., browser developer tools, SAML-tracer extensions, compromised endpoints, or logging misconfigurations). Given the critical nature of Mendix in industrial and enterprise settings, proactive patching is essential.

Detection & Response

SIGMA Rules

The following rules are designed to detect suspicious authentication patterns in web server and application logs that may indicate SAML assertion replay or related probing. They are tuned to minimize false positives by focusing on specific URI patterns and anomalous source behavior.

---
title: Potential SAML Assertion Replay Targeting Mendix Application
id: 8f7a3b2c-4e5d-4c6b-9a8f-1e2d3c4b5a6f
status: experimental
description: Detects multiple successful SAML SSO logins from a single source IP to a Mendix application using different user accounts within a short timeframe, which may indicate assertion replay.
references:
  - https://www.cisa.gov/news-events/ics-advisories/icsa-26-302-01
  - https://attack.mitre.org/techniques/T1078/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.initial_access
  - attack.t1078
logsource:
  category: webserver
  product: iis # Adjust for your web server (e.g., apache, nginx)
detection:
  selection:
    cs-uri-stem|contains:
      - '/saml/'
      - '/sso/'
      - '/login'
    sc-status: 200
    cs-method: POST
  condition: selection
  timeframe: 5m
  aggregation:
    - field: c-ip
      condition: count() by cs-username > 3
falsepositives:
  - Legitimate load balancer health checks
  - Automated testing scripts
level: high
---
title: Unusual SAML Response Size from Single Source
id: 9a8b7c6d-5e4f-3d2c-1b0a-9f8e7d6c5b4a
status: experimental
description: Detects abnormally large or repetitive SAML responses from a single source IP, which may indicate an attacker manipulating or replaying captured assertions.
references:
  - https://www.cisa.gov/news-events/ics-advisories/icsa-26-302-01
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.initial_access
  - attack.t1078
logsource:
  category: webserver
  product: iis # Adjust for your web server
detection:
  selection:
    cs-uri-stem|contains: '/saml/'
    cs-method: POST
    sc-status: 200
  filter_known_good_size:
    sc-bytes: '>10000' # Adjust based on baseline; SAML responses are typically large
  condition: selection and filter_known_good_size
  timeframe: 10m
  aggregation:
    - field: c-ip
      condition: count() > 10
falsepositives:
  - Large group memberships in SAML assertions
  - IdP-initiated SSO with extensive attribute release
level: medium

KQL (Microsoft Sentinel / Defender)

This query hunts for patterns in web server logs (ingested via Syslog/CEF or Azure App Service logs) that could indicate SAML assertion replay. It looks for multiple distinct users authenticating from the same source IP via SAML within a short window.

// Hunt for potential SAML assertion replay in web server logs
let timeframe = 5m;
let threshold = 3;
CommonSecurityLog
| where TimeGenerated > ago(1h)
| where RequestURL has_any ("/saml/", "/sso/", "/login")
| where RequestMethod == "POST"
| where HttpStatusCode == 200
| summarize Users = dcount(RequestContext), UserList = make_set(RequestContext), Count = count() by SourceIP, bin(TimeGenerated, timeframe)
| where Users > threshold
| project TimeGenerated, SourceIP, Users, UserList, Count
| order by TimeGenerated desc;

// Alternative for IIS logs ingested into Log Analytics
let timeframe = 5m;
let threshold = 3;
W3CIISLog
| where TimeGenerated > ago(1h)
| where csUriStem has_any ("/saml/", "/sso/", "/login")
| where scStatus == 200
| where csMethod == "POST"
| summarize Users = dcount(csUserName), UserList = make_set(csUserName), Count = count() by cIP, bin(TimeGenerated, timeframe)
| where Users > threshold
| project TimeGenerated, cIP, Users, UserList, Count
| order by TimeGenerated desc;

Velociraptor VQL

This VQL artifact can be deployed to endpoints (e.g., a Mendix server) to hunt for suspicious process execution related to SAML module manipulation or unexpected child processes of the web server. While the vulnerability is server-side, an attacker who successfully replays an assertion may attempt to execute commands or establish persistence. This hunt focuses on post-exploitation activity originating from the web server process.

-- Hunt for suspicious child processes spawned by web server processes (e.g., IIS w3wp.exe, Apache, Nginx) on a Mendix server
-- This may indicate post-authentication bypass activity
LET web_processes = (SELECT Pid, Name, CommandLine, Exe FROM pslist() WHERE Name =~ '(w3wp|httpd|nginx|java|node)')

SELECT 
    Pid,
    Name,
    CommandLine,
    Exe,
    Username,
    CreateTime,
    ParentPid
FROM pslist()
WHERE ParentPid IN web_processes.Pid
    AND NOT Name =~ '(conhost|dllhost|backgroundTaskHost)' // Common legitimate children
    AND NOT CommandLine =~ '.*\\windows\\system32.*' // Filter system paths

Remediation Script (Bash for Linux-based Mendix Server)

This script helps verify the current Mendix SAML Module version if the application is deployed in a standard Mendix cloud/on-premise structure. It assumes the module files are within the application's deployment directory. Note: The definitive fix is updating via the Mendix Marketplace/Studio Pro, not via direct file manipulation. This script is for verification and inventory purposes.

#!/bin/bash
# Verify Mendix SAML Module Version
# Run on the Mendix application server

APP_DIR="/opt/mendix/apps" # Adjust to your Mendix app directory
SAML_MODULE_PATH="$APP_DIR/*/resources/saml"

echo "=== Mendix SAML Module Version Check ==="
echo "Searching for SAML module in: $SAML_MODULE_PATH"

find $APP_DIR -path "*/resources/saml/module.json" 2>/dev/null | while read -r module_file; do
    app_path=$(dirname $(dirname $(dirname "$module_file")))
    version=$(grep -o '"version"[^,]*' "$module_file" | cut -d'"' -f4)
    echo "Application: $app_path"
    echo "SAML Module Version: $version"
    
    # Check if version is vulnerable
    if [[ "$version" < "4.2.4" ]] || [[ "$version" < "3.6.29" ]]; then
        echo "STATUS: POTENTIALLY VULNERABLE to CVE-2026-89209"
        echo "ACTION: Update to 4.2.4 (Mendix 10/11) or 3.6.29 (Mendix 9) immediately via Mendix Studio Pro/Studio."
    else
        echo "STATUS: Appears patched."
    fi
    echo "---"
done

# Check for SAML endpoints in web server logs for recent activity (if logs are local)
echo ""
echo "=== Recent SAML Authentication Attempts (last 24h) ==="
find /var/log -name "*.log" -mtime -1 -exec grep -l "saml" {} \; 2>/dev/null | while read -r logfile; do
    echo "Log file: $logfile"
    grep -i "saml" "$logfile" | tail -20
done

Remediation

Immediate Actions (Next 24-72 Hours)

1. Patch Immediately: Update the Mendix SAML Module to the fixed versions:
   • Mendix 10 compatible: Update to version 4.2.4 or later.
   • Mendix 11 compatible: Update to version 4.2.4 or later.
   • Mendix 9 compatible: Update to version 3.6.29 or later.
   • Updates are available via the Mendix Marketplace within Studio Pro or Mendix Studio.
2. Review IdP-Initiated Flow Configuration: If possible, disable or restrict IdP-initiated SSO in your Mendix application settings and your Identity Provider (e.g., Azure AD, Okta, ADFS) until patching is complete. SP-initiated flows are not affected by this specific flaw.
3. Audit SAML Assertion Usage: Review your application logs, web server logs, and IdP logs for any signs of assertion replay. Look for:
   • Multiple logins from the same source IP using different usernames in a short period.
   • Assertions with identical ID attributes being presented multiple times.
   • Unusually high volumes of successful SAML POST requests.
4. Hunt for Post-Exploitation: If you suspect compromise, hunt for lateral movement or persistence on the Mendix server itself (see VQL above).

Strategic Actions (Next 7-30 Days)

1. Enforce Short Assertion Lifetimes: Configure your IdP to issue SAML assertions with the shortest practical NotOnOrAfter lifetime (e.g., 5 minutes). This minimizes the window of opportunity for replay attacks.
2. Enable SAML Assertion Signing and Encryption: Ensure that your IdP is configured to sign the assertion and, if possible, encrypt it for the Mendix SP. This protects the assertion from being tampered with or read in transit and at rest.
3. Implement Strict Audience Restriction and Recipient Validation: Verify that your IdP is configured to include the correct AudienceRestriction (the Mendix application's entity ID) and that the Recipient attribute in the SubjectConfirmationData matches the exact assertion consumer service URL of your Mendix app.
4. Monitor for SAML Tracer/Debugger Extensions: Educate developers and admins on the risks of browser extensions like SAML-tracer, which can inadvertently expose valid assertions if screenshots or logs are shared.
5. Network Segmentation: Ensure Mendix servers, especially those hosting critical infrastructure applications, are segmented from general user networks. Restrict inbound access to the SAML assertion consumer service to only the IdP's IP ranges if feasible (though this may not always be possible with cloud IdPs).

Official References

• CISA ICS Advisory: ICSA-26-302-01 - Siemens Mendix SAML Module
• Siemens ProductCERT Advisory: SSA-071006 (Link from CISA advisory)
• Mendix SAML Module Documentation: Mendix Marketplace - SAML
• MITRE CWE-294: Authentication Bypass by Capture-replay

Related Resources

Security Arsenal Managed SOC Services AlertMonitor Platform Book a SOC Assessment soc-mdr Intel Hub