Cve 2024 6800 · Research

Critical SAML Signature Wrapping Flaw Exposes GitHub Enterprise Server to Unauthenticated Admin Takeover

Threat dossier infographic detailing CVE-2024-6800 in GitHub Enterprise Server, showing a 9.5 CVSS score, SAML signature wrapping attack vector, and affected versions.
AK

Threat intelligence editor · Updated Aug 29, 2026, 10:43 AM EDT

A critical SAML flaw (CVE-2024-6800, CVSS 9.5) lets attackers gain admin access on GitHub Enterprise Server. Learn the exploitation mechanism and patch steps.

A critical authentication bypass flaw in GitHub Enterprise Server allows unauthenticated remote attackers with network access to forge Security Assertion Markup Language assertions and gain full site administrator privileges. Tracked as CVE-2024-6800 with a CVSS 4.0 score of 9.5 (Critical), the vulnerability stems from improper XML signature verification in SAML Single Sign-On configurations that rely on publicly accessible signed federation metadata.

Disclosed on August 20, 2024, through the GitHub Bug Bounty program via HackerOne report #2579939, the security flaw affects all self-hosted GitHub Enterprise Server instances across the 3.10 through 3.13 release trains. Because no temporary configuration workarounds exist, platform administrators and security engineers managing private GitHub appliances face an urgent mandate: deploy vendor hotfixes immediately and audit historical authentication records for unauthorized administrative provisioning.

[[image:poster]]


Vulnerability Breakdown and XML Signature Flaw (CVE-2024-6800 / CVSS 9.5)

The defect falls under CWE-347: Improper Verification of Cryptographic Signature. The core flaw is an XML Signature Wrapping (XSW) vulnerability situated in the SAML response processing pipeline of GitHub Enterprise Server (GHES).

MetricSpecification
Vulnerability IdentifierCVE-2024-6800
Advisory ReferenceGHSA-5wm9-5344-qrrj
CVSS v4.0 Score9.5 (Critical)
CVSS v4.0 VectorCVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:L/SC:H/SI:H/SA:L
Vulnerability ClassCWE-347 (Improper Verification of Cryptographic Signature)
Exploitation PrerequisiteNetwork route to GHES; SAML SSO enabled with signed IdP federation metadata

In a standard XML Digital Signature (XML-DSig) handshake, cryptographic signatures validate data integrity by computing cryptographic hashes across specific XML subtrees referenced by URI element IDs (such as <ds:Reference URI="#_element_id">).

In vulnerable GHES versions, cryptographic signature validation operates in complete isolation from application payload extraction.

sequenceDiagram
 autonumber
 actor Attacker as Remote Attacker
 participant IdP as Identity Provider (Metadata)
 participant GHES as Vulnerable GHES Instance
 participant AdminApp as GHES Application Stack

 Attacker->>IdP: Retrieve signed federation metadata XML
 IdP-->>Attacker: Serves valid signed XML element with IdP certificate
 Note over Attacker: Builds forged SAMLResponse wrapping valid XML fragment
and injects untrusted Assertion (site_admin = true)
 Attacker->>GHES: HTTP POST to /saml/consume
 Note over GHES: Validates <ds:Signature> against IdP public certificate.
RESULT: Signature validation succeeds.
 GHES->>AdminApp: Extract User Claims via Top-Level DOM/XPath
 Note over AdminApp: DOM parser selects forged Assertion node.
Identity resolved as site administrator.
 AdminApp-->>Attacker: Issues authenticated session (Site Admin Privileges)

The authentication bypass unfolds in two decoupled steps:

  1. Signature Verification: The cryptographic parser traverses the incoming SAML document, isolates the <ds:Signature> block, validates the mathematical digest of the referenced structure against the Identity Provider (IdP) public certificate extracted from federation metadata, and marks the document authentic.
  2. Identity Resolution: The GHES authentication handler searches the Document Object Model (DOM) via top-level XPath queries (such as /samlp:Response/saml:Assertion/saml:Subject) to resolve the username and role claims. Instead of parsing the signed block, the handler processes the attacker's forged, unsigned assertion.

Exploitation Mechanism and SAML Assertion Forgery

The architectural vulnerability allows attackers to forge identities without possessing private cryptographic keys or intercepting live user sessions.

An attacker begins by downloading the publicly accessible federation metadata XML file hosted by the enterprise IdP (e.g., Okta, Microsoft Entra ID, PingFederate, or Shibboleth). This metadata document contains valid XML elements digitally signed by the IdP's private signing key alongside its public certificate.

+-------------------------------------------------------------+
| Crafted SAML Response (/saml/consume) |
| |
| [ Forged Unsigned Assertion ] <--- Parsed by GHES App Logic|
| - NameID: target_admin |
| - site_admin: true |
| |
| [ Legitimate Signed Metadata Fragment ] <--- Checked by |
| - &lt;ds:Signature> valid against IdP Cert Crypto Engine|
+-------------------------------------------------------------+

The attacker wraps this legitimate, signed metadata fragment inside an HTTP POST payload destined for the GHES assertion consumer service endpoint at /saml/consume. Immediately adjacent to the valid structure, the attacker injects an arbitrary &lt;saml:Assertion> declaring arbitrary NameID and role attributes:

  • NameID: Matches an existing site administrator or creates a novel identity.
  • Role/Attribute Statements: Asserts administrative entitlements (administrator: true).

Because SAML 2.0 Web Browser SSO profiles communicate authentication tokens through client-side browser POST redirects, the IdP is never contacted during payload transmission. The IdP generates zero transaction logs, zero error flags, and zero security alerts.

When user auto-provisioning is enabled—a common enterprise configuration—GHES creates a new local account endowed with full site administrator rights. If provisioning is disabled, the payload maps directly onto existing privileged accounts, completing an instant account takeover.


Forensic Triage and Breach Identification Runbook

Security operations and incident response teams must evaluate whether self-hosted appliances sustained exploitation prior to patch installation. Triage requires analyzing enterprise audit logs, backend server journals, and database states.

1. Enterprise Audit Log Inspection

Platform operators should run targeted queries across SIEM streams and the GHES Enterprise Audit Log API:

Event IdentifierQuery FilterDetection Objective
Site Admin Escalationaction:business.add_admin or action:enterprise.add_adminDetects accounts elevated to enterprise administrator without approved change requests.
Unauthorized Member Additionsaction:org.add_member or action:org.add_outside_collaboratorFlags unexpected collaborator assignments on internal repositories.
Rogue Account Creationaction:user.createIdentifies accounts provisioned via SAML with unfamiliar external NameIDs.
Persistence Establishmentaction:public_key.create, action:personal_access_token.createUncovers SSH keys and personal access tokens generated immediately post-login.
Auth Architecture Changesaction:business.saml_provider_changedCatches adversary modifications to identity provider configurations.

2. Appliance Shell Forensics

Security personnel with administrative SSH access (port 122) can execute internal diagnostics to inspect low-level service logs and database tables:

# 1. Search web service access logs for anomalous SAML consumption requests
grep -i "POST /saml/consume" /var/log/github/unicorn.log* /var/log/github/production.log*

# 2. Correlate site administrator session creation events in authentication logs
grep -i "site_admin" /var/log/github/auth.log* | grep -E "created|authenticated"

# 3. List all SSH public keys tied to site administrator accounts
ghe-console -y -c "User.where(site_admin: true).each { |u| puts \"#{u.login}: #{u.public_keys.pluck(:title, :fingerprint, :created_at)}\" }"

# 4. Enumerate OAuth tokens and Personal Access Tokens created in the last 30 days
ghe-console -y -c "OauthAccess.where('created_at > ?', 30.days.ago).each { |t| puts \"User: #{t.user.login} | App: #{t.application.name} | Created: #{t.created_at}\" }"

3. Indicators of Compromise Checklist

  • Administrative logins originating from unrecognized or external IP addresses.
  • Accounts carrying site_admin: true attributes inside GHES that have no corresponding identity record in the central enterprise IdP directory.
  • Generation of SSH keys, OAuth applications, or fine-grained personal access tokens within minutes of an unverified SAML authentication event.
  • Unscheduled repository export, clone, or migration events executed by newly created administrative accounts.

Patch Deployment and Mitigation Realities

GitHub released official remediation updates across all supported versions on August 20, 2024. GitHub confirmed that no configuration workarounds or non-patch mitigations exist for CVE-2024-6800.

| Release Branch | Vulnerable Builds | Remediated Release | Support Lifecycle Notes | | :--- | :--- | :--- | | 3.13.x | Prior to 3.13.3 | 3.13.3 | Active maintenance train | | 3.12.x | Prior to 3.12.8 | 3.12.8 | Active maintenance train | | 3.11.x | Prior to 3.11.14 | 3.11.14 | Active maintenance train | | 3.10.x | Prior to 3.10.16 | 3.10.16 | End-of-Life reached August 29, 2024 | | 3.14.x+ | None | 3.14.0+ | Base release includes permanent patch |

Organizations running the 3.10 release branch faced an aggressive lifecycle deadline: version 3.10.16 arrived just nine days before the entire 3.10 branch reached end-of-life status on August 29, 2024. Fleet operators on 3.10 must patch to 3.10.16 before staging a sequential upgrade to 3.11.x or higher to remain eligible for ongoing security coverage.

The patch packages also resolve two co-packaged vulnerabilities:

  • CVE-2024-7711 (Moderate): An unauthorized state modification flaw allowing issue alterations in public repositories.
  • CVE-2024-6337 (Moderate): An information disclosure flaw leaking private repository issue contents through specific markdown rendering conditions.

During hotfix deployment via ghe-config-apply, temporary background Elasticsearch re-indexing operations or brief web interface pauses may occur while service daemons restart.


Long-Term IdP and DevSecOps Hardening

Remediating signature wrapping requires architectural defenses across both identity infrastructure and source code management platforms:

  1. Restrict IdP Metadata Endpoints: Remove public internet access to IdP federation metadata endpoints (federationmetadata.xml). Configure SAML trust relationships via statically uploaded, authenticated metadata configurations where operational workflows permit.
  2. Mandate Dual-Element Signatures: Reconfigure Identity Providers to sign both the root &lt;samlp:Response> container and the nested &lt;saml:Assertion> payload using secure algorithms such as RSA-SHA256 (http://www.w3.org/2001/04/xmldsig-more#rsa-sha256).
  3. Enforce SAML Assertion Encryption: Activate full XML assertion encryption (&lt;saml:EncryptedAssertion>). Encrypting payloads with the GHES public key ensures intermediary proxies and unauthenticated actors cannot inspect or restructure DOM elements prior to verification.
  4. Decouple Administrator Elevation from SAML Claims: Prohibit automated Just-In-Time provisioning rules from directly assigning site administrator privileges. Require secondary administrative approvals or dedicated break-glass accounts for privileged appliance operations.
  5. Establish Externalized Immutable Logging: Stream /var/log/github/audit.log and /var/log/github/auth.log in real time to an isolated SIEM system to prevent adversaries from altering forensic records following administrative compromise.