CVE-2024-4985 is a critical authentication bypass vulnerability in GitHub Enterprise Server (GHES) that allows an unauthenticated attacker to forge a SAML assertion to gain unauthorized access to an instance with administrator privileges. The vulnerability stems from a failure in the SAML response validation logic when SAML Single Sign-On (SSO) is enabled with optional encrypted assertions. By sending a specially crafted SAML response to the Assertion Consumer Service (ACS) endpoint, an attacker can impersonate any user, including site administrators, effectively bypassing the entire authentication mechanism without possessing a valid session or cryptographic keys from the Identity Provider (IdP).
SAML Authentication Architecture in GHES
To understand the mechanics of CVE-2024-4985, one must first examine the standard Security Assertion Markup Language (SAML) 2.0 flow within a GitHub Enterprise Server environment. GHES acts as the Service Provider (SP), relying on an external Identity Provider (IdP) such as Okta, Azure AD, or PingFederate to authenticate users. The process typically involves a browser-based redirect where the user is sent to the IdP, authenticates, and is then redirected back to the GHES ACS endpoint with a SAML Response.
This SAML Response is an XML document containing assertions about the user's identity, group memberships, and session validity. In a secure implementation, the SP must verify the digital signature of the Response or the individual Assertion to ensure it originated from a trusted IdP. This verification relies on a public key certificate previously exchanged between the SP and IdP. This flaw represents a significant failure in the core security model, categorizing it alongside other broken authentication vulnerabilities that undermine the trust relationship between distributed systems.
The Root Cause: Validation Logic Bypass
The technical root of CVE-2024-4985 lies in the way GHES processed SAML assertions when encryption was configured as optional. In many enterprise environments, assertions are encrypted to protect sensitive user attributes (PII) from being read by the client's browser during the redirect. However, GHES allowed a configuration state where it would accept both encrypted and unencrypted assertions.
The vulnerability manifested in the signature validation routine. Specifically, the application failed to strictly enforce signature requirements on unencrypted assertions when the system was expecting (but not strictly requiring) encrypted ones. An attacker could construct a SAML Response containing a forged, unencrypted assertion that claimed the identity of a high-privileged user (e.g., the primary administrator account). Because the validation logic did not properly verify the cryptographic signature of this specific XML block under certain conditions, the forged identity was accepted as legitimate.
This is fundamentally an implementation error in the XML processing pipeline. When the SAML parser receives the `samlp:Response`, it iterates through the `saml:Assertion` elements. If the logic responsible for checking the `ds:Signature` is bypassed or returns a "true" result prematurely due to malformed XML structures that the parser handles inconsistently, the SP proceeds to provision a session for the user identified in the `saml:Subject`.
Exploitation Methodology
Exploiting CVE-2024-4985 requires the attacker to identify a GHES instance with SAML SSO enabled and determine the target username or email address of an administrator. Since GHES instances often follow predictable naming conventions for administrative accounts (e.g., `admin`, `site-admin`), this information is often easily guessed or gathered through OSINT.
The attacker begins by capturing a legitimate SAML Response from any valid login attempt to understand the required XML structure, including the `Audience`, `Recipient`, and `AttributeStatement` fields. Using this template, the attacker crafts a malicious XML payload. Tools like Burp Suite with the SAML Raider extension are commonly used to manipulate these assertions.
# Example of a forged SAML Assertion structure (Simplified)
<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" ...>
<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="_123456" Version="2.0">
<saml:Issuer>http://idp.example.com/</saml:Issuer>
<saml:Subject>
<saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">[email protected]</saml:NameID>
<saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<saml:SubjectConfirmationData Recipient="https://ghes.target.com/login/saml/consume"/>
</saml:SubjectConfirmation>
</saml:Subject>
<saml:Conditions NotBefore="2024-05-14T00:00:00Z" NotOnOrAfter="2024-05-14T01:00:00Z">
<saml:AudienceRestriction>
<saml:Audience>https://ghes.target.com</saml:Audience>
</saml:AudienceRestriction>
</saml:Conditions>
<saml:AuthnStatement AuthnInstant="2024-05-14T00:00:00Z">
<saml:AuthnContext>
<saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</saml:AuthnContextClassRef>
</saml:AuthnContext>
</saml:AuthnStatement>
<!-- The vulnerability allows this assertion to be accepted without a valid signature -->
</saml:Assertion>
</samlp:Response>
The attacker then base64 encodes the forged XML and sends it via a POST request to the `/login/saml/consume` endpoint of the GHES instance. If the instance is vulnerable and the configuration matches the exploit requirements, the GHES server will process the assertion, find the `NameID` corresponding to the administrator, and issue a session cookie (`user_session`) for that user. This grants the attacker full access to the GHES Management Console and all hosted repositories.
Identifying Vulnerable Instances
For security researchers and red teams, identifying exposed and vulnerable GHES instances is a critical step in assessing organizational risk. Researchers often use Zondex to scan for specific GHES headers or Favicon hashes that indicate the presence of a GitHub Enterprise Server. Because GHES version information is often visible in the HTML source or specific API endpoints, it is possible to filter for versions prior to the 3.13.0 release branch.
Organizations can also leverage the Secably EASM API to monitor their external attack surface for these instances. By automating the discovery of GHES deployments and checking their versioning against the list of affected releases, security teams can proactively identify assets that require immediate patching before they are exploited by malicious actors.
Affected Versions and Patches
GitHub released patches for all supported release series to address CVE-2024-4985. The following table outlines the affected versions and the corresponding secure versions:
Branch
Affected Versions
Fixed Version
GHES 3.13
All versions prior to 3.13.0
3.13.0 (Initial Release)
GHES 3.12
3.12.0 - 3.12.3
3.12.4
GHES 3.11
3.11.0 - 3.11.9
3.11.10
GHES 3.10
3.10.0 - 3.10.11
3.10.12
It is critical to note that GitHub Enterprise Server instances using built-in authentication or LDAP/CAS without SAML SSO are not affected by this specific vulnerability. However, the prevalence of SAML in enterprise environments makes this one of the most impactful GHES vulnerabilities in recent history, comparable in severity to the scenarios described in the zero-day exploits guide.
Technical Comparison: CVE-2024-4985 vs. Previous SAML Flaws
SAML vulnerabilities often fall into several categories: XML Signature Wrapping (XSW), Comment Injection, or improper validation of the `NotOnOrAfter` condition. CVE-2024-4985 is particularly dangerous because it bypasses the signature requirement entirely rather than manipulating a legitimate signature.
Unlike XSW attacks, where an attacker moves a valid signature to cover a different part of the XML document, CVE-2024-4985 exploits the SP's willingness to ignore the absence of a signature or accept a self-signed assertion when optional encryption is enabled. This suggests a logic flaw in the state machine of the SAML authentication module. The module likely reached a state where it assumed verification had already occurred or was not required for the specific XML node being processed.
Incident Response and Detection
Detecting an exploitation attempt of CVE-2024-4985 requires looking at the GHES audit logs. Specifically, administrators should monitor for unusual login patterns, such as an administrator session originating from an unknown IP address or a login event that does not correlate with IdP logs.
Reviewing the `audit.log` on the GHES instance is the primary method for forensic analysis. Look for `auth.login` events where the `auth_type` is `saml`.
A key indicator of compromise is a SAML login success event in GHES that has no corresponding successful authentication log in the Identity Provider's management console. If an attacker forges an assertion, the IdP is never contacted, leaving a visible discrepancy between the two systems. Furthermore, organizations using Secably for attack surface management can correlate their asset inventory with these log events to prioritize investigations on high-value GHES instances containing sensitive intellectual property.
Remediation and Hardening
The immediate remediation for CVE-2024-4985 is to upgrade the GHES instance to the latest patch release (3.13.0, 3.12.4, 3.11.10, or 3.10.12). This update modifies the SAML processing library to strictly enforce signature validation regardless of whether encryption is used.
Beyond patching, organizations should implement the following hardening measures:
Enable Mandatory Encryption: Configure both the IdP and GHES to require encrypted assertions. This reduces the attack surface by ensuring that the client browser never handles the plaintext XML of the assertion.
Rotate SAML Certificates: If a compromise is suspected, rotate the X.509 certificates used for signing and encrypting SAML assertions.
Restrict ACS Access: If possible, restrict access to the `/login/saml/consume` endpoint to known IdP IP ranges, though this can be difficult with cloud-based IdPs.
Implement Multi-Factor Authentication (MFA): While SAML bypasses the primary authentication, if GHES is configured to require an additional layer of MFA for administrative actions (Sudo mode), the impact of the initial bypass may be mitigated, although this is not a substitute for patching.
The severity of this vulnerability highlights the risks inherent in complex XML-based authentication protocols. As demonstrated in other critical analysis pieces, such as the analysis of CVE-2024-30051, flaws in core authentication or privilege management components can lead to total system compromise.
For developers working on similar integrations, using well-vetted libraries and ensuring that "optional" security features do not lead to "permissive" security defaults is paramount. In the case of GHES, the interaction between optional encryption and signature enforcement created a gap that allowed unauthenticated remote code execution (RCE) indirectly through administrative access. Maintaining a rigorous EASM strategy and prompt patching cycle remains the most effective defense against such high-impact vulnerabilities.
