Skip to content
TrustList
Security advisories

GitHub fixes secret-scanning flaw that can reach code execution on GHES

Editorial

By TrustList Editorial

Exploiting the high-severity bug needs only push access to a repository with Advanced Security on, and a second, medium flaw lets a collaborator swap a repository's default branch.

About GitHub fixes secret-scanning flaw that can reach code execution on GHES

GitHub fixes secret-scanning flaw that can reach code execution on GHES

6 October 2026: GitHub has patched CVE-2026-96890, a high-severity server-side request forgery in the secret-scanning validity checks of GitHub Enterprise Server that can lead to remote code execution on the appliance. A second flaw, CVE-2026-103620, rated medium, lets a repository collaborator replace the default branch. Fixes for both shipped in the 3.22.2, 3.21.7 and 3.20.9 releases; 3.19.13 and 3.18.16 carry only the fix for the second flaw. GitHub's notes do not describe exploitation in the wild.

How the high-severity flaw works

An attacker commits crafted GCP service account credentials to a repository. When secret scanning runs its validity check on them, the appliance sends requests to addresses the attacker chose, without enough validation. GitHub says this could lead to remote code execution on the appliance. The attacker needs push access to a repository that has GitHub Advanced Security enabled, so the exposure sits with organisations that give many contributors push rights and have switched secret scanning on.

The default-branch bypass

CVE-2026-103620 involves the GraphQL API. A collaborator with write access could delete the default branch and make a branch under their control the new default. In repositories that require pull request review but do not restrict branch deletion, this skipped the review requirement, so fresh clones and default-branch API requests would receive the attacker's content. GitHub's 3.18.16 notes say the report came through its bug bounty programme.

Fixed versions by release line

GitHub's release notes for each supported line, all dated 6 October, list the fixes as follows:

  • 3.22.2: CVE-2026-96890 and CVE-2026-103620
  • 3.21.7: CVE-2026-96890 and CVE-2026-103620
  • 3.20.9: CVE-2026-96890 and CVE-2026-103620
  • 3.19.13: CVE-2026-103620 only
  • 3.18.16: CVE-2026-103620 only

Hong Kong's CERT bulletin lists all five releases as fixing the vulnerabilities without separating them, and an earlier version of this item followed it. The notes for 3.19.13 and 3.18.16 do not mention CVE-2026-96890, so an appliance on either of those lines should not be treated as protected against the high-severity flaw by that upgrade alone; GitHub's notes do not say whether those lines are affected by it.

Before upgrading

GitHub's known issues for these releases include custom firewall rules being removed during an upgrade, so they must be reapplied afterwards. The 3.18.16 notes also mention that Management Console lockouts do not unlock on their own and need SSH access to clear. Until a patch is in, restricting who can push to repositories with Advanced Security enabled, and restricting branch deletion where review rules matter, narrows both paths.

Related on TrustList:

Sources

Categories & features

TrustList Weekly

The week in software and IT, in one email

The news that matters to buyers, new rankings and our own research. Every Thursday, free, and easy to leave.

We will email you to confirm. Unsubscribe with one click in any issue. Privacy policy

You may be interested in

T3

Traefik 3.7.17 stops NTLM headers exhausting proxy memory

A client with no credentials can tie up memory, file descriptors and backend connections on Traefik 3.7.14 to 3.7.16 and 2.11.58 to 2.11.60, whether or not NTLM is used. It is the latest of more than a dozen fixes since 6 October.

Keep exploring

More on TrustList

Everything here links back to the same verified catalogue. Pick your next stop.