CVE-2026-96890: 
GitHub Enterprise Server vulnerability analysis and mitigation

CVE-2026-96890 is a Server-Side Request Forgery (SSRF) vulnerability in GitHub Enterprise Server (GHES) that allows an authenticated repository contributor to cause the appliance to issue HTTP requests to attacker-controlled internal hosts, which can be chained to achieve remote code execution (RCE) on the appliance. The flaw resides in the secret scanning validator for GCP service account credentials, which blindly trusted the token endpoint URL embedded within a committed credential without restricting the destination. Affected versions include GHES 3.20.0–3.20.8, 3.21.0–3.21.6, and 3.22.0–3.22.1; exploitation requires GitHub Advanced Security and secret scanning validity checks to be enabled, a non-default configuration. The vulnerability was disclosed on October 6, 2026, and carries a CVSS v3.1 base score of 8.8 (High) and a CVSS v4.0 base score of 8.7 (High) (Github Advisory, GHES 3.22 Release Notes).

The root cause is classified as CWE-918 (Server-Side Request Forgery). The GHES secret scanning subsystem, when performing validity checks on GCP service account credentials committed to a repository, extracts the token_endpoint field from the credential JSON and issues an HTTP request to that URL without validating or restricting the destination to legitimate GCP endpoints. An attacker with push access to any repository on a vulnerable instance can craft a fake GCP service account credential JSON containing an attacker-controlled internal URL as the token endpoint; when secret scanning triggers a validity check upon the push, the appliance makes an outbound request to that internal address. This SSRF primitive can be chained — for example, by targeting internal metadata services or other co-located services — to escalate to full remote code execution on the appliance (Github Advisory, GHES 3.20 Release Notes).

Successful exploitation allows an authenticated attacker to pivot from a low-privileged repository contributor role to achieving remote code execution on the GHES appliance, resulting in complete compromise of confidentiality, integrity, and availability of the system. An attacker could exfiltrate sensitive data stored on the appliance (source code, secrets, credentials), tamper with repository data or configurations, and disrupt service availability. Because GHES appliances are typically central to enterprise software development workflows, compromise could enable lateral movement into connected internal systems and supply chain attacks (Github Advisory, GHES 3.21 Release Notes).

As of the disclosure date, there is no public proof-of-concept exploit code and no evidence of in-the-wild exploitation (Github Advisory). The vulnerability was reported through the GitHub Bug Bounty program and is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. The EPSS score is approximately 0.414% (34th percentile), indicating a relatively low near-term exploitation probability. Exploitation is not automatable as it requires an authenticated user with repository push access on an instance with the non-default GitHub Advanced Security and secret scanning validity checks configuration enabled (Github Advisory).

1. Identify a target instance: Locate a GitHub Enterprise Server instance running versions 3.20.0–3.20.8, 3.21.0–3.21.6, or 3.22.0–3.22.1 with GitHub Advanced Security and secret scanning validity checks enabled.
2. Obtain repository push access: Authenticate as a user with at least contributor/push access to any repository on the target instance (e.g., via a legitimate account, compromised credentials, or a free/invited account).
3. Craft a malicious GCP service account credential: Create a JSON file resembling a GCP service account key, but with the token_endpoint field set to an attacker-controlled internal URL (e.g., http://169.254.169.254/latest/meta-data/ for cloud metadata, or an internal service endpoint).
4. Commit the credential to the repository: Push the crafted credential file to the repository. This triggers the GHES secret scanning subsystem to detect the GCP credential pattern and initiate a validity check.
5. SSRF triggered: The secret scanning validator extracts the token_endpoint from the committed credential and issues an HTTP request to the attacker-specified internal address without destination validation.
6. Escalate to RCE: By targeting internal services (e.g., internal APIs, metadata endpoints, or other co-located services on the appliance), leverage the SSRF response data to extract secrets or tokens that can be used to achieve remote code execution on the appliance (Github Advisory, GHES 3.20 Release Notes).

• Network: Unexpected outbound HTTP/HTTPS requests from the GHES appliance to internal IP ranges (RFC 1918 addresses) or cloud metadata endpoints (e.g., 169.254.169.254) originating from the secret scanning service process.
• Network: Outbound connections to unusual internal ports or services not normally contacted by the GHES appliance, particularly shortly after a repository push event.
• Logs: GHES audit logs showing push events to repositories followed by secret scanning validity check activity targeting non-GCP endpoints; look for secret scanning log entries referencing unexpected token endpoint URLs.
• Logs: Application logs from the secret scanning service showing HTTP requests to internal addresses or non-standard GCP token endpoints.
• File System: Presence of crafted GCP service account JSON files in repository commits containing a token_endpoint field pointing to internal or non-GCP URLs.
• Process: Unusual network connections or child processes spawned by the secret scanning service on the appliance after repository push events.

GitHub has released patched versions addressing this vulnerability: 3.20.9, 3.21.7, and 3.22.2, all released on October 6, 2026. Administrators should upgrade to the appropriate patched version as the primary remediation (GHES 3.20 Release Notes, GHES 3.21 Release Notes, GHES 3.22 Release Notes). As a temporary workaround if immediate patching is not possible, administrators should consider disabling GitHub Advanced Security secret scanning validity checks on affected instances, as exploitation requires this non-default feature to be enabled. Restricting repository push access to trusted users can also reduce the attack surface until patching is completed.