Server-Side Request Forgery in GitHub Enterprise Server Could Lead to Remote Code Execution

A Server-Side Request Forgery (SSRF) vulnerability was identified in GitHub Enterprise Server that allowed a repository contributor to cause the appliance to issue requests to attacker-controlled internal hosts, which could be chained to achieve remote code execution on the appliance. The secret scanning validator for GCP service account credentials trusted the token endpoint embedded in a committed credential and issued a request to it without restricting the destination. Exploitation required an authenticated user with permission to push to a repository on an instance with GitHub Advanced Security and secret scanning validity checks enabled, a non-default configuration. This vulnerability affected GitHub Enterprise Server 3.20, 3.21, and 3.22 and was fixed in versions 3.20.9, 3.21.7, and 3.22.2. This vulnerability was reported through the GitHub Bug Bounty program.

GitHub Enterprise Server is affected in the following release branches:

• 3.20 branch: releases from 3.20.0 before 3.20.9 are affected; 3.20.9 is marked unaffected.
• 3.21 branch: releases from 3.21.0 before 3.21.7 are affected; 3.21.7 is marked unaffected.
• 3.22 branch: releases from 3.22.0 before 3.22.2 are affected; 3.22.2 is marked unaffected.

The described configuration scope is an instance with GitHub Advanced Security and secret scanning validity checks enabled. The record does not establish the status of other branches or releases.

The flaw is in the secret scanning validator for GCP service account credentials. The validator trusted the token endpoint embedded in a committed credential and issued a request to that destination without adequately restricting or validating it.

At a high level, the attack sequence is:

1. An authenticated user with repository push permission commits a credential whose token endpoint points to an attacker-selected internal destination.
2. Secret scanning performs a validity check and the appliance sends a request to the supplied destination.
3. The SSRF can be chained with additional conditions to achieve remote code execution on the appliance.

Exploitation requires GitHub Advanced Security and secret scanning validity checks to be enabled on the instance. Public details do not establish the exact internal endpoint, the service reached, or the detailed steps in the remote code execution chain.

• The attack path is network-reachable and requires an authenticated user with permission to push to a repository.
• The user does not need appliance administrator privileges, but must have repository write access on an instance meeting the configuration requirements.
• GitHub states that exploitation requires GitHub Advanced Security and secret scanning validity checks to be enabled, which is a non-default configuration.
• The supplied attack characterization indicates that no additional user interaction is required after the exploitation conditions are met.
• The supplied record does not identify a public exploit and does not establish known exploitation status. This does not prove that exploitation has never occurred.

• The vulnerability allows a repository contributor with push permission to influence a request sent by the appliance to an address specified in the credential.
• This is SSRF with potential impact beyond the repository because the appliance may be able to reach internal network locations or services unavailable to an external client.
• GitHub states that the SSRF could be chained to achieve remote code execution on the appliance, which could potentially result in loss of confidentiality, unauthorized changes, or service disruption.
• The initial authority is repository push permission rather than system administrator access. The exact internal service, chaining mechanism, and evidence of actual compromise are not established by the public record.

• The appliance may be forced to send requests to internal services that a repository user could not normally reach directly.
• If the described chain reaches remote code execution, an attacker could affect the confidentiality, integrity, and availability of the appliance and the data or services it manages.
• The initial condition requires an authenticated account with repository push permission, so this is not an anonymous attack path.
• Actual risk depends on whether the relevant features are enabled, what internal network access the appliance has, and which internal services are present. The record does not identify a victim, breach, or impact beyond the appliance.

1. Upgrade GitHub Enterprise Server to the fixed release for the deployed branch: 3.20.9 for the 3.20 branch, 3.21.7 for the 3.21 branch, or 3.22.2 for the 3.22 branch.
2. After the upgrade, verify that every relevant appliance and node is running the applicable fixed release. Do not infer that parallel branches or other releases are unaffected unless the record confirms them.
3. During upgrade planning, prioritize instances with GitHub Advanced Security and secret scanning validity checks enabled because this configuration is an exploitation prerequisite identified by the advisory.
4. If an upgrade cannot be completed immediately, treat instances meeting the configuration requirement as exposed. The record does not provide a separate confirmed mitigation, so the configuration should not be treated as a remediation by itself.

1. Inventory GitHub Enterprise Server appliances and compare each installed release with the fixed releases listed in affected_summary and remediation.
2. Verify separately whether GitHub Advanced Security and secret scanning validity checks are enabled on each instance.
3. Review recent commits for GCP service account credentials, especially credentials whose token endpoint differs from the expected service destination.
4. Inspect appliance outbound network logs around secret scanning validity checks for requests to internal or otherwise unexpected destinations. This is precautionary monitoring, not a confirmed indicator of compromise.
5. Review audit records for repository push activity and related secret scanning validation activity. The available sources do not specify an event name or IOC; absence of suspicious log evidence does not prove that an instance is safe.