GitHub Enterprise Server Authorization Vulnerabilities (CVE-2026-0573, CVE-2026-1355, CVE-2026-1999)
Feb 18, 2026
GitHub Enterprise Server (GHES) sits at the center of many organizations’ development workflows. It stores source code, drives CI/CD pipelines, and often acts as the backbone of internal automation. When something goes wrong in its authorization logic, the impact isn’t theoretical. It can mean leaked tokens, poisoned repositories, or unauthorized code merges.
Three recently disclosed vulnerabilities highlight a common theme: authenticated user abuse caused by broken or incomplete authorization checks.
Let’s walk through each one, what went wrong, and what we can learn from them.
The Big Picture: Authenticated Risk Surface
All three CVEs share an important characteristic:
- The attacker must be authenticated.
- The flaws exist in authorization logic, not authentication itself.
- The impact is mostly integrity-related, not anonymous remote compromise.
This is important. Modern enterprise platforms are rarely breached by someone hammering a login page. More often, it’s a low-privilege account exploiting logic gaps inside trusted workflows.
CVE-2026-0573: Token Leakage via Unsafe Redirect Handling
What Happened
The repository_pages API in GHES followed HTTP redirects when fetching artifact URLs. During those redirects, it preserved the Authorization header, which contained a privileged JWT.
If an attacker could trigger a redirect to an attacker-controlled domain, the server would forward the authorization token along with the request. That meant the attacker could capture a privileged token.
Why It’s Serious
The leaked token included elevated permissions (such as Actions.ManageOrgs). With that token, an attacker could potentially:
- Escalate privileges
- Manipulate GitHub Actions
- Pivot further into the environment
- In certain setups, move toward remote code execution
Root Cause
The underlying issue is classic: the HTTP client followed redirects and preserved sensitive headers across host boundaries. There was no restriction preventing tokens from being forwarded to a different domain.
Secure design rule: Authorization headers should never be forwarded across domains unless explicitly validated.
CVE-2026-1355: Missing Authorization in Repository Migration Upload
What Happened
GHES provides repository migration features, allowing exports and restores of repositories. The upload endpoint failed to properly verify that the authenticated user actually owned or was authorized to modify the specified migration ID.
An attacker could authenticate, supply a victim’s migration identifier, and upload a replacement migration archive. If the victim later restored the migration, they would restore attacker-controlled repository content.
Why It Matters
This is an integrity attack. An attacker could inject malicious source code, backdoored workflows, modified CI/CD configurations, or hidden persistence mechanisms. It’s essentially a supply-chain style attack within your own Git environment.
Root Cause
This is a textbook broken access control issue. The system verified that the user was logged in, but it did not properly verify object-level authorization for that specific migration resource.
Authentication is not authorization. That distinction is where this vulnerability lives.
CVE-2026-1999: Pull Request Auto-Merge Authorization Bypass
What Happened
The vulnerability existed in the enable_auto_merge GraphQL mutation. Under specific conditions, an attacker could fork a repository, open a pull request into the target repo, enable auto-merge, and merge their PR without having push access.
This only worked when:
- The repository allowed forks
- The pull request status checks were clean
- The target branch did not have branch protection rules enabled
Why It’s Dangerous
This allows direct integrity compromise through unauthorized code merges, backdoored applications, or CI/CD pipeline tampering. In environments where Git drives production deployment, that’s high risk.
Root Cause
The auto-merge mutation logic did not properly enforce repository-level write permissions before completing the merge. Branch protection could prevent exploitation, but if it was not enabled, the permission check inside the mutation became the single point of failure.
Common Themes Across All Three CVEs
1. Authorization Logic Is Hard
Each case involves a permission check that was missing, incomplete, or incorrectly implemented, or a workflow that assumed safety under certain conditions.
2. Authenticated Users Are a Major Threat Vector
None of these were anonymous exploits. They required a valid account and access to the GHES instance, aligning with real-world enterprise risk where internal threats are prominent.
3. Integrity Is Just as Critical as Confidentiality
Two of the three CVEs primarily impact integrity. Compromising code repositories is often more damaging than stealing data, as it enables persistent backdoors.
4. Defense in Depth Works
Branch protection rules, egress filtering, and strict migration permissions could have stopped or limited these attacks. When one control fails, another layer can prevent escalation.
Practical Defensive Steps
- Patch Immediately: Ensure you’re running a fixed version (e.g., 3.19.2, 3.18.5, 3.17.11, etc. depending on your branch).
- Enforce Branch Protection Everywhere: Require pull request reviews and status checks. Restrict who can push and protect all important branches.
- Review Fork Policies: If you do not need internal forking, consider restricting it.
- Audit Migration Activity: Monitor migration events and validate archives before restoration.
- Restrict Outbound Network Access: Limit egress from GHES to prevent arbitrary outbound connections and monitor unusual requests.
Final Thoughts
These three CVEs aren’t about flashy zero-click exploits. They’re about something more common and more dangerous in enterprise systems: subtle authorization failures.