# samlify signature wrapping, forge SAML as any user

Source: https://startwithidentity.com/cves/cve-2025-47949/
Last updated: 2026-08-29
License: content by Start with Identity. Cite the source URL.

---

## What broke

[samlify](https://github.com/tngan/samlify) below 2.10.0 did not correctly bind the XML signature to the assertion it later consumed. An attacker can wrap a valid signature around a new [SAML](https://startwithidentity.com/glossary/saml/) response and authenticate as any user, including admins (CWE-347). Fixed in samlify 2.10.0.

## Why it matters

The 2025 SAML story is not "Ruby is bad." It is that the most widely copied SSO libraries, in Ruby and in Node, failed the same signature-wrapping test. If your SP is a Node service using samlify (or a SaaS that embeds it), the blast radius matches [ruby-saml](https://startwithidentity.com/cves/cve-2025-25291/). authentik later shipped its own ACS wrapping fix in 2025.12.5 / 2026.2.3 / 2026.5.1, which is the same pattern in a different codebase.

## What to do

- Upgrade samlify to 2.10.0 or later. Check lockfiles, not just package.json ranges.
- Rotate IdP signing keys after the upgrade if the ACS was public.
- Inventory Node SPs the same way you inventory Rails SPs. `npm ls samlify` in every SSO-facing service.

## After you patch

A SAML bypass means the service provider accepted an assertion it should have rejected, so anyone who exploited it authenticated as a real user and left a normal-looking log line.

- **Revoke every session** issued by the affected service provider, then rotate its session signing keys. Patching stops new forgeries and does nothing about sessions already minted.
- **Audit administrative accounts and group memberships** for changes during the exposure window. Signing in as an administrator is the point of this class, and adding a second account is the standard persistence step.
- **Rotate the identity provider signing certificate** if the flaw involved signature validation, and confirm the service provider pins the expected certificate rather than trusting anything in the assertion.
- **Check your own implementation for the same class**: exact-match comparison on verification results, rejection of unexpected signature algorithms, and audience and recency checks on every assertion. See [SAML 2.0](https://startwithidentity.com/standards/saml-2-0/) and [SAML vs OIDC](https://startwithidentity.com/guides/fundamentals/saml-vs-oidc/).

## Sources

- [NVD: CVE-2025-47949](https://nvd.nist.gov/vuln/detail/CVE-2025-47949)