CVE-2026-80465: Siemens Mendix SAML Signature Bypass — Detect and Remediate SSO Account Hijacking

Siemens has disclosed a high-severity vulnerability in the Mendix SAML module — the component thousands of Mendix low-code applications rely on for enterprise single sign-on. Tracked as CVE-2026-80465 and published under CISA ICS advisory ICSA-26-258-06, the flaw is an Improper Verification of Cryptographic Signature weakness that could allow an unauthenticated remote attacker to hijack an account when the application is deployed in specific SSO configurations. CVSS v3 base score: 8.7 (High).

Let me be blunt about what this means operationally. Your Mendix applications authenticate users through SAML precisely so that identity assurance is enforced by a trusted IdP. When the service provider side fails to properly validate the cryptographic signature on a SAML response, that trust chain collapses — an attacker who can reach the application's assertion consumer endpoint may be able to present a forged or tampered assertion and walk straight into a victim's session, without credentials, without MFA, and without tripping a failed-login alert. Given Mendix's footprint in Critical Manufacturing and Information Technology sectors worldwide, this is not a theoretical exposure. It is a perimeter-to-account-takeover path on business-critical applications, including OT-adjacent workflow and shop-floor systems.

The good news: Siemens has shipped fixed releases for every supported Mendix major version. The bad news: SAML modules are Marketplace components, which means they are updated independently of the Mendix platform runtime — and they are routinely forgotten in patch cycles. If you run Mendix 9.24, 10, or 11 applications with SSO, assume you are exposed until you verify otherwise.

Technical Analysis

Affected Products and Versions

Vendor: Siemens. CWE classification: CWE-347 — Improper Verification of Cryptographic Signature. CVSS v3 base score 8.7. Deployments: worldwide, concentrated in Critical Manufacturing and Information Technology sectors.

How the Vulnerability Works — Defender's View

The Mendix SAML module acts as the SAML Service Provider (SP) inside a Mendix application. In a normal flow, the IdP authenticates the user and returns a signed SAML response/assertion to the SP's assertion consumer service (ACS) endpoint, typically exposed under the application's /sso/ or /saml/ path. The SP must cryptographically verify that signature against the IdP's trusted signing certificate before mapping the assertion to a local account and establishing a session.

CVE-2026-80465 is a failure in that verification step. In the affected module versions and under specific SSO configurations, signature validation can be subverted such that an unauthenticated remote attacker can supply a crafted SAML response and be logged in as a chosen user — classic SAML account hijacking. The exploitation requirements that matter for your risk model:

• Network reachability to the Mendix application's SSO endpoints (for internet-facing or partner-facing Mendix apps, this is trivially satisfied).
• No credentials or user interaction required — this is pre-authentication from the attacker's perspective.
• A specific SSO configuration state, per the vendor. Do not read this as reassurance. Until you identify which configuration elements gate exploitability in your environment, treat all affected-version deployments as exploitable.
• Target selection is easy: SAML assertions carry the victim's NameID in plaintext XML. If an attacker knows or guesses a valid username/email format, the forged assertion does the rest.

The attacker-controlled outcome is a fully authenticated application session as an arbitrary user — including administrators, if the IdP maps them into the Mendix app. From there, impact depends on what the Mendix application does: in critical manufacturing environments, Mendix apps frequently broker workflows, approvals, and integrations into ERP/MES/OT systems.

Exploitation Status

As of this writing, CISA and Siemens have not reported confirmed in-the-wild exploitation, and CVE-2026-80465 is not listed in the CISA Known Exploited Vulnerabilities catalog. There is no public PoC. However, the advisory is fresh, the attack surface (pre-auth SSO endpoints) is extremely attractive, and SAML signature-validation flaws historically attract rapid researcher and adversary attention. The correct posture is patch immediately, hunt retrospectively.

Detection & Response

Detection here centers on the assertion consumer path: malformed or unsigned SAML responses, anomalous SSO request volumes, and sessions established via SSO that don't correlate with legitimate IdP-issued flows. Tune these to your Mendix deployment topology (IIS reverse proxy, Nginx ingress, or Mendix Cloud front-end) and confirm your log pipelines capture request bodies for SSO endpoints where privacy policy permits.

---
title: SAML Response Without Detectable Signature Submitted to SSO Endpoint
id: 8b4e2a17-3c6d-4f91-b2a8-5e7d9c1f0342
status: experimental
description: Detects HTTP POST requests to SAML/SSO assertion consumer endpoints where the request body lacks a Signature element, consistent with attempts to exploit improper signature verification such as CVE-2026-80465 in Siemens Mendix SAML.
references:
  - https://www.cisa.gov/news-events/ics-advisories/icsa-26-258-06
  - https://attack.mitre.org/techniques/T1190/
author: Security Arsenal
date: 2026/09/17
tags:
  - attack.initial_access
  - attack.t1190
logsource:
  category: webserver
detection:
  selection_endpoint:
    c-uri|contains:
      - '/saml/'
      - '/sso/'
      - '/assertionconsumer'
      - '/acs'
  selection_method:
    cs-method: 'POST'
  filter_signed:
    cs-body|contains:
      - '<ds:Signature'
      - '<saml2:Signature'
      - 'SignatureValue'
      - '<dsig:Signature'
  condition: selection_endpoint and selection_method and not filter_signed
falsepositives:
  - IdP-initiated flows using POST bindings that carry signatures in form-encoded fields captured under different field names
  - Log pipelines that do not record request bodies (verify logging coverage first)
level: high
---
title: Suspicious Volume of SSO Assertion Posts From Single Source
id: 2f7c9d54-8a1b-4e63-9d05-b4a6c8e2f197
status: experimental
description: Identifies bursts of repeated POSTs to Mendix SSO/SAML endpoints from one source, indicative of assertion forgery or replay probing against CVE-2026-80465 vulnerable endpoints. Deploy with a count threshold tuned to baseline SSO traffic in your SIEM correlation layer.
references:
  - https://www.cisa.gov/news-events/ics-advisories/icsa-26-258-06
  - https://attack.mitre.org/techniques/T1078/
author: Security Arsenal
date: 2026/09/17
tags:
  - attack.initial_access
  - attack.t1190
  - attack.t1078
logsource:
  category: webserver
detection:
  selection:
    c-uri|contains:
      - '/saml/'
      - '/sso/'
      - '/acs'
    cs-method: 'POST'
    sc-status:
      - 200
      - 302
  condition: selection
falsepositives:
  - Legitimate authentication storms during shift changes or application restarts
  - Health checks or load balancer probes misconfigured to POST
level: medium

// Hunt for anomalous SAML/SSO assertion consumer activity against Mendix applications
// Surfaces unsigned-body posts, single-source bursts, and SSO logins from rare IPs.
// Ingest IIS/Nginx/ingress logs into W3CIISLog or via CommonSecurityLog (CEF).
let ssoPaths = dynamic(["/saml/", "/sso/", "/acs", "/assertionconsumer"]);
let windowStart = ago(14d);
W3CIISLog
| where TimeGenerated >= windowStart
| where csMethod == "POST"
| where csUriStem has_any (ssoPaths)
| summarize Requests = count(),
            DistinctUsers = dcount(csUsername),
            Statuses = make_set(scStatus),
            UserAgents = make_set(csUserAgent),
            FirstSeen = min(TimeGenerated),
            LastSeen = max(TimeGenerated)
    by cIP, csUriStem, Computer, bin(TimeGenerated, 1h)
| where Requests > 25 or (DistinctUsers > 5 and Requests > 10)
| extend RiskNote = iif(DistinctUsers > 5,
    "Single source asserting multiple distinct identities - possible forged assertions",
    "High-volume POST burst to SSO endpoint - probe or replay behavior")
| sort by Requests desc;

-- Hunt on-host Mendix / reverse-proxy logs for SAML signature-validation errors
-- and SSO anomalies consistent with CVE-2026-80465 probing or exploitation.
-- Adjust glob paths to your Mendix runtime and web-tier log locations.
SELECT FullPath, LineNumber, Line
FROM foreach(
  row={
    SELECT FullPath
    FROM glob(globs=[
      'C:/Mendix/**/log/*.log',
      'D:/Mendix/**/log/*.log',
      '/opt/mendix/**/log/*.log',
      'C:/inetpub/logs/LogFiles/**/*.log',
      '/var/log/nginx/access*.log'
    ])
  },
  query={
    SELECT FullPath, LineNumber, Line
    FROM parse_lines(filename=FullPath)
    WHERE Line =~ '(?i)saml|sso|assertion'
      AND Line =~ '(?i)signature|invalid|denied|replay|forg|tamper'
  })
ORDER BY FullPath, LineNumber

# CVE-2026-80465 - Siemens Mendix SAML module exposure check
# Scans Mendix project/deployment directories for the SAML module and
# flags versions below the fixed releases (4.2.3 for Mx10/11, 3.6.27 for Mx9.24).
# Run on Mendix build servers, deployment hosts, or against exported project trees.

$FixedCurrent = [version]'4.2.3'    # Mendix 10 / 11 compatible track
$FixedLegacy  = [version]'3.6.27'   # Mendix 9.24 compatible track
$SearchRoots  = @('C:\Mendix', 'D:\Mendix', "$env:USERPROFILE\Documents\Mendix")

foreach ($root in $SearchRoots) {
    if (-not (Test-Path $root)) { continue }
    Write-Host "[*] Scanning $root for Mendix SAML module artifacts..." -ForegroundColor Cyan

    # Marketplace module packages and model metadata that expose the SAML module version
    $artifacts = Get-ChildItem -Path $root -Recurse -ErrorAction SilentlyContinue -Include *
        | Where-Object { $_.Name -match 'SAML' -and $_.Extension -in '.mxmodule','.xml','.json','.mpr' }

    foreach ($file in $artifacts) {
        $content = Get-Content $file.FullName -Raw -ErrorAction SilentlyContinue
        $match = [regex]::Match(($file.Name + ' ' + $content), '(?i)saml[^0-9]{0,40}([0-9]+\.[0-9]+\.[0-9]+)')
        if (-not $match.Success) { continue }

        $found = [version]$match.Groups[1].Value
        # 3.x is the Mendix 9.24 track; 4.x is the Mendix 10/11 track
        $isLegacy = $found.Major -lt 4
        $fixed    = if ($isLegacy) { $FixedLegacy } else { $FixedCurrent }

        if ($found -lt $fixed) {
            Write-Warning "VULNERABLE (CVE-2026-80465): SAML module $found in $($file.FullName) - update to $fixed or later"
        } else {
            Write-Host "[OK] SAML module $found meets fixed baseline ($fixed) - $($file.FullName)" -ForegroundColor Green
        }
    }
}

# Post-check: confirm no unsigned assertion posts reached SSO endpoints in IIS logs (last 7 days)
$logRoot = 'C:\inetpub\logs\LogFiles'
if (Test-Path $logRoot) {
    Get-ChildItem $logRoot -Recurse -Filter *.log -ErrorAction SilentlyContinue |
        Where-Object { $_.LastWriteTime -gt (Get-Date).AddDays(-7) } |
        ForEach-Object {
            Select-String -Path $_.FullName -Pattern 'POST\s+/(saml|sso|acs)' -ErrorAction SilentlyContinue
        } | Select-Object -First 50 | ForEach-Object { $_.Line }
}

Remediation

1. Upgrade the Mendix SAML module immediately. Update to 4.2.3 or later for applications on the Mendix 10 and Mendix 11 compatible tracks, and to 3.6.27 or later for the Mendix 9.24 compatible track. Pull the fixed module from the Mendix Marketplace, commit it into your app model, and redeploy — upgrading the Mendix Studio Pro runtime alone does not patch the module.
2. Inventory every Mendix application using SSO. Include shadow and departmental low-code apps. Check the Marketplace modules list in each project; don't rely on a central CMDB that may not track module-level dependencies.
3. Review SSO configuration hardening while you patch. Enforce signed assertions and signed responses, restrict accepted signature algorithms, validate AudienceRestriction/InResponseTo, and ensure IdP signing certificates are current and pinned. Confirm whether your deployment matches the vendor-described vulnerable configuration pattern.
4. Hunt retrospectively. Run the KQL and VQL above across at least the last 30 days. Look specifically for SSO sessions established without a preceding IdP authentication event for that user, and for assertion posts lacking signatures.
5. Force session invalidation post-patch. Terminate active application sessions on patched Mendix apps and, where feasible, force re-authentication at the IdP to flush any sessions established via forged assertions.
6. Reduce exposure at the edge. If you cannot patch immediately, restrict network access to the application's SSO endpoints (WAF rules, IP allowlists for partner-facing flows) and alert on any POST to /saml/, /sso/, or ACS paths. This is a stopgap, not a fix — the module update is the only complete remediation.
7. Review the official advisories: CISA ICS Advisory ICSA-26-258-06 and the Siemens CSAF document referenced in the advisory. CISA recommends critical infrastructure organizations apply vendor mitigations promptly; monitor both sources for updated guidance and any KEV addition.

SAML signature-validation bugs are among the most dangerous identity-layer flaws we see in incident response because they convert directly into authenticated sessions with no failed-login telemetry. Patch the module, verify the configuration, and assume you need to prove — not presume — that no forged assertions have already landed in your environment.

Related Resources

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