On May 20, 2024, GitHub disclosed CVE-2024-4985, a critical authentication bypass vulnerability (CVSS 10.0) in GitHub Enterprise Server (GHES). The flaw allowed an attacker to forge a SAML response and gain access to a GHES instance with site administrator privileges, without any prior authentication. It affected GHES instances using SAML single sign-on (SSO) authentication with the optional encrypted assertions feature enabled.
Understanding the Vulnerability
SAML (Security Assertion Markup Language) is widely used for enterprise single sign-on. In a typical SAML authentication flow, a user attempts to access a service provider (in this case, GHES), gets redirected to an identity provider (like Okta, Azure AD, or PingFederate) for authentication, and the identity provider sends a signed SAML assertion back to the service provider confirming the user's identity.
CVE-2024-4985 was a flaw in how GHES validated SAML responses when encrypted assertions were enabled. The vulnerability allowed an attacker to craft a SAML response that would be accepted by GHES as valid, even without access to the identity provider's signing key. In effect, the attacker could forge a SAML assertion claiming to be any user, including a site administrator.
The encrypted assertions feature is an optional SAML configuration that adds an encryption layer to the SAML assertion for additional confidentiality. Ironically, enabling this security feature is what introduced the vulnerability. GHES instances using SAML SSO without encrypted assertions were not affected.
Impact Assessment
The impact of CVE-2024-4985 was severe for affected instances. An attacker who could reach the GHES instance's network could:
- Gain site administrator access without any credentials
- Access all repositories, including private and internal repositories
- Modify repository contents, including inserting backdoors into source code
- Access secrets, tokens, and credentials stored in repositories or GitHub Actions workflows
- Create new administrator accounts for persistent access
- Modify GitHub Actions workflows to inject malicious code into CI/CD pipelines
For organizations using GHES to host proprietary source code, the vulnerability represented a direct path to intellectual property theft and supply chain compromise. An attacker with admin access to a GHES instance could modify code in repositories that feed into production builds, effectively turning the source code repository into an attack vector.
Affected Versions and Fix
The vulnerability affected GHES versions 3.6.0 through 3.13.0 when configured with SAML SSO and encrypted assertions. GitHub released patches in versions 3.9.15, 3.10.12, 3.11.10, and 3.12.4. Version 3.13.0 was initially released with the fix included.
GitHub noted that GHES instances not using SAML SSO, or using SAML SSO without the encrypted assertions option, were not vulnerable. However, organizations that had encrypted assertions enabled, generally those with stricter security requirements, were exposed.
Why SAML Vulnerabilities Are Particularly Dangerous
SAML authentication bypass vulnerabilities are among the most dangerous classes of web application flaws because they completely undermine the authentication boundary. Unlike authorization vulnerabilities that might allow access to specific resources, SAML bypass flaws grant access as any user, typically with the highest privileges.
This is not the first time a critical SAML vulnerability has had major impact. In 2023, Citrix NetScaler (CVE-2023-4966, "Citrix Bleed") involved session token theft that bypassed SAML authentication. Going back further, the 2017 SAML vulnerability in multiple identity providers demonstrated that subtle implementation flaws in XML signature verification could bypass SAML authentication entirely.
The complexity of the SAML specification is part of the problem. SAML relies on XML processing, XML signature verification, optional encryption, and multiple binding types. Each of these layers introduces opportunities for implementation errors that can result in authentication bypass.
Self-Hosted vs Cloud-Hosted Security Tradeoffs
CVE-2024-4985 only affected GitHub Enterprise Server (self-hosted), not GitHub.com or GitHub Enterprise Cloud. This highlights an often-overlooked tradeoff in the self-hosted versus cloud-hosted debate.
Self-hosted solutions give organizations more control over their data and infrastructure, but they also transfer the responsibility for security patching to the customer. When a critical vulnerability is disclosed, self-hosted customers must identify affected instances, plan maintenance windows, test patches, and deploy updates. Cloud-hosted customers benefit from the vendor patching the vulnerability centrally.
For GHES specifically, organizations choosing self-hosting often do so for regulatory or data sovereignty reasons. These same organizations tend to have stricter security requirements, which is why they might enable features like encrypted assertions. The irony that enabling an additional security feature introduced the vulnerability underscores the complexity of secure software configuration.
Recommendations
Organizations running GHES should patch immediately if they have not already. Beyond patching:
- Audit GHES access logs for the period the instance was vulnerable, looking for unexpected administrator sessions or user creations
- Review repository audit logs for unauthorized changes, particularly in repositories that feed CI/CD pipelines
- Rotate any secrets or tokens stored in GHES repositories or Actions workflows
- If encrypted assertions were enabled, verify that the patched behavior correctly validates SAML responses by testing with your identity provider
For organizations evaluating whether to self-host GitHub or use the cloud-hosted service, this incident is a data point worth considering in the risk assessment.
How Safeguard.sh Helps
Safeguard.sh monitors your infrastructure components, including self-hosted developer tools like GitHub Enterprise Server. When critical vulnerabilities like CVE-2024-4985 are published, Safeguard.sh identifies affected instances in your inventory and prioritizes them for immediate patching. Our policy gates can enforce version compliance for development infrastructure, ensuring that critical tools are kept at secure versions. For organizations that host their own development platforms, Safeguard.sh provides the same continuous vulnerability tracking for infrastructure components that it does for application dependencies.