Start with Identity
Identity CVE · SAML

CVE-2024-4985GitHub Enterprise Server SAML encrypted-assertion bypass

high
Product: GitHub Enterprise ServerVendor: GitHubCWE-347Disclosed: 2024-05-20Status: PatchedProtocol deep diveNVD ↗

What broke

GitHub Enterprise Server's optional encrypted-SAML assertions feature did not bind the signature to the assertion it later consumed. An attacker who could reach the ACS forged a response and provisioned a site administrator, with no prior account. Reported through the GitHub Bug Bounty. Fixed in GHES 3.9.15, 3.10.12, 3.11.10, and 3.12.4 (May 2024). CVE-2024-9487 is the incomplete-fix follow-on. CVE-2024-6800 is a related wrapping path on the same product.

Why it matters

Encrypted assertions are sold as the "more secure" SAML mode. Here they were the bypass. GHES is often the crown-jewel service provider in an enterprise: source, Actions secrets, and deploy keys. An SSO forge there is a supply-chain incident, not a login ticket. The 2025 GHES canonicalization bug (CVE-2025-23369) is the same lesson a year later.

What to do

  • Confirm every GHES appliance is past the May 2024 builds, then take the 9487 and 6800 updates as well.
  • If encrypted assertions were on while unpatched, review newly provisioned site admins and PATs.
  • Prefer OIDC to GitHub where you can. XML encryption does not save a broken verifier.

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 and SAML vs OIDC.

Sources

Last reviewed By SWI Community TeamSuggest a correctionHow we research

Technique

This CVE is an instance of Federation trust abuse and SAML forgery. A service provider that accepts a SAML assertion it should have rejected treats a forged identity as authenticated, because the failure sits in signature validation code, not in cryptography.

Know a primary source we should add, or a patch status that has changed? Email community@startwithidentity.com. See all briefs in the identity CVE catalog, or volunteer as a CVE Analyst.
Compiled from vendor advisories, NVD, CISA KEV, and public research. CVSS figures can disagree across NVD and the CNA. Confirm affected versions against the vendor advisory before you patch. Independent, community-driven analysis. See the disclaimer.