CVE-2026-75101 in GitHub
Summary
by MITRE • 09/23/2026
An authorization bypass vulnerability was identified in GitHub Enterprise Server that allowed any authenticated user of the instance to read the raw diff or patch of pull requests in private repositories without authorization. Access tokens for raw pull request diffs and patches were scoped to the repository name and pull request number rather than to a globally unique repository identifier, so an attacker who created a repository and pull request matching a target's repository name and pull request number could use a token for their own repository to retrieve the private pull request's contents. Exploitation required the attacker to know the target repository's name and a valid pull request number. This vulnerability affected all versions of GitHub Enterprise Server prior to 3.22 and was fixed in versions 3.17.21, 3.18.15, 3.19.12, 3.20.8, and 3.21.6. This vulnerability was reported via the GitHub Bug Bounty program.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/23/2026
A critical authorization bypass flaw existed within GitHub Enterprise Server that permitted authenticated users to access sensitive data from private repositories without proper permission checks. The vulnerability centered on how access tokens for raw pull request diffs and patches were generated and scoped. Instead of binding these tokens to a globally unique repository identifier, the system relied solely on the repository name and the specific pull request number as scoping parameters. This design oversight created a scenario where token validation did not sufficiently verify that the requesting user actually owned or had access rights to the target repository associated with those identifiers.
The operational impact of this flaw was significant for organizations relying on GitHub Enterprise Server for private code development. An attacker who possessed valid authentication credentials could exploit this mechanism by creating their own public or private repository and pull request that matched the name and number of a victim's sensitive project. By obtaining an access token scoped to their own maliciously named repository, the attacker could then use that same token to retrieve the raw diff or patch content from the target organization's private repository. This effectively allowed unauthorized reading of proprietary source code, intellectual property, and potentially confidential configuration details embedded in pull requests.
Successful exploitation required specific prerequisites beyond simple authentication. The attacker needed prior knowledge of the exact name of the victim's repository as well as a valid pull request number within that repository. While this requirement limits the blast radius compared to fully automated attacks, it remains highly feasible for targeted adversaries who may have gathered such information through reconnaissance or social engineering. Once these conditions were met, the system incorrectly validated the token against the target resource because the scoping parameters matched, bypassing standard authorization controls entirely.
This vulnerability affected all versions of GitHub Enterprise Server prior to version 3.22. The issue was addressed and patched in specific maintenance releases including versions 3.17.21, 3.18.15, 3.19.12, 3.20.8, and 3.21.6. Organizations running older or unpatched instances were at immediate risk until they upgraded to one of the fixed versions. The vulnerability was responsibly disclosed through the GitHub Bug Bounty program, highlighting the importance of coordinated disclosure practices in maintaining platform security integrity.
From a classification perspective, this flaw aligns with CWE-285 Improper Authorization and CWE-798 Use of Hard-coded Credentials if considering the token generation logic as a form of predictable credential binding. In terms of adversary behavior, it maps to ATT&CK technique T1078 Valid Accounts, where an attacker uses legitimate credentials to access resources they are not authorized for, combined with aspects of data exfiltration through API abuse. To mitigate such risks in similar environments, developers should ensure that all resource identifiers used for scoping tokens include globally unique values rather than just human-readable names or sequential numbers. Implementing strict ownership verification during token validation and auditing API endpoints for proper access control checks are essential defensive measures to prevent unauthorized data exposure.