# GitHub Enterprise Server SAML bypass via libxml2 canonicalization

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

---

## What broke

GitHub Enterprise Server's [SAML](https://startwithidentity.com/glossary/saml/) verifier trusted libxml2's canonicalization of the signed assertion. Canonicalization quirks let an attacker present XML that verifies one way and is interpreted another. The result is an authentication bypass on self-hosted GitHub SSO. GitHub shipped a patched GHES release.

## Why it matters

GHES is often the crown-jewel [service provider](https://startwithidentity.com/glossary/service-provider/) in an enterprise: source, secrets in Actions, and production deploy keys. An SSO bypass there is not "just a forge login." It is a path to the codebase and the CI identity plane. The bug is also a reminder that XML DSig is only as strong as the canonicalizer you share with the attacker.

## What to do

- Apply the GHES security update that lists CVE-2025-23369. Confirm the version on every appliance, including DR.
- If GHES SAML was reachable while unpatched, review new organization owners and PAT grants that have no matching IdP session.
- Prefer OIDC to GitHub where you can. The [OIDC](https://startwithidentity.com/glossary/oidc/) path does not inherit this XML stack.

## 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-23369](https://nvd.nist.gov/vuln/detail/CVE-2025-23369)
- GitHub Enterprise Server release notes