GitHub Enterprise Server CVE-2026-8034: SSRF via Notebook Viewer (URL Parser Confusion)

GitHub Enterprise Server is the self-hosted GitHub version used by enterprises for their private code repositories — often at the core of the development and CI/CD infrastructure. CVE-2026-8034 (CVSS 9.8) reveals a classic Server-Side Request Forgery (SSRF) vulnerability in the notebook viewer, caused by confusion between two different URL parsers: the one used to validate the hostname, and the one used to issue the actual HTTP request.

Exploitation lets an attacker with network access to the instance forge HTTP requests from the GHES server itself to internal services unreachable from the internet — a classic pattern to pivot into the internal network, reach cloud metadata services (AWS IMDS, GCP), or attack unauthenticated Redis, Elasticsearch, and similar services typically deployed internally.

Technical Details

The URL parser confusion pattern

The attack exploits a subtle asymmetry between two URL parsing libraries. In practice, the validation code uses one parser (typically Node.js' native URL or Python's urlparse), while the HTTP client library uses a different parser (native http.request, requests, curl). The two diverge on certain malformed URLs:

http://allowed.com#@evil.com/

• The validator may see allowed.com as the hostname (strict parser)
• The HTTP client may see evil.com as the hostname (different interpretation of #@)

Result: validation passes but the actual request hits a different target — the attacker thus injects internal URLs (http://169.254.169.254 for AWS metadata, http://localhost:6379 for internal Redis) disguised as "valid" URLs.

Characteristics

Affected Products and Versions

All versions prior to 3.21 were vulnerable before these patches.

Check your version:

# Via SSH to the GHES appliance
ssh admin@github.example.com -p 122 'ghe-version'

# Via the WebUI: Site Admin → Manage → Information → Version

Exploitation and Impact

Exploitation conditions

• Network access to the GHES instance (from the internet if exposed, otherwise from the corporate network)
• No GHES authentication required — the vulnerable notebook viewer endpoint accepts external URLs

What an attacker can reach via SSRF

1. Cloud metadata services

http://169.254.169.254/latest/meta-data/iam/security-credentials/   # AWS
http://metadata.google.internal/computeMetadata/v1/                  # GCP
http://169.254.169.254/metadata/instance?api-version=2021-02-01      # Azure

→ Theft of IAM credentials of the role attached to the GHES instance = potentially admin access to the entire cloud account.

2. Unauthenticated internal services

• Redis on localhost:6379 → Redis command execution (RCE via CONFIG SET)
• Elasticsearch on localhost:9200 → read/write the indices
• Docker daemon on unix socket → escape to the host
• Kubernetes API on localhost:6443 → cluster control

3. Internal reconnaissance

Internal port scanning via the GHES instance (which can reach subnets not internet-routable). Map internal services to prepare follow-on attacks.

4. Access-control bypass

Some internal applications use source IP as authentication (whitelist of internal IPs). An SSRF from GHES makes requests appear to come from a "trusted" IP.

Detection and IOCs

GHES logs

• Audit log: ghe-config check audit_logging_enabled
• Search /var/log/github/audit.log for notebook viewer access from unusual external IPs
• Nginx logs: /var/log/nginx/github.example.com_*.log — requests to the notebook viewer path with unusual URL parameters

# Suspicious requests to the notebook viewer
grep -E "notebook.*\?.*=.*://" /var/log/nginx/github.example.com_access.log | \
  grep -vE "github\.com|githubusercontent\.com"

SSRF indicators

• Unexpected outbound connections from the GHES server to:
  • 169.254.169.254 (cloud metadata)
  • localhost, 127.0.0.1
  • Internal RFC1918 IPs that GHES doesn't normally contact
• Abnormal cloud IAM credential usage (CloudTrail / Azure Activity)

Post-incident cloud audit

If you run GHES on AWS/Azure/GCP with an attached instance role:

# AWS — list actions performed by the GHES instance role
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=Username,AttributeValue=<ghes-instance-role> \
  --max-results 50

Mitigation and Patch

Immediate action: update

GHES applies fixes via a .pkg file:

# 1. Download the patch for your branch from enterprise.github.com
# 2. Verify the signature
gpg --verify github-enterprise-server-*.pkg.sig

# 3. Apply via the admin console (port 8443)
# Settings → Updates → Upload package → Install

Workaround if patching is delayed

1. Disable the notebook viewer if the feature is unused:
   • Site Admin → Settings → disable "Show notebooks" if possible
2. Network-isolate the GHES server:
   • Block outbound traffic from the GHES instance to 169.254.169.254 (cloud metadata)
   • Restrict outbound to explicit destinations (GitHub.com, mirrors, etc.)
3. Rotate IAM credentials attached to the GHES instance as a precaution

Long-term hardening

• Enforce IMDSv2 on AWS (make IMDSv1 unavailable): aws ec2 modify-instance-metadata-options --http-tokens required
• On GCP: use Metadata Server v2 with required Metadata-Flavor: Google header
• Audit every component that makes outbound requests on the GHES instance — not just the notebook viewer

Why Continuous Monitoring of Development Infrastructure Matters

Development tools (GitHub Enterprise, GitLab, Jenkins, Artifactory, Sonatype Nexus…) are prime targets: they hold the source code, secrets, and deployment credentials of your entire organization. An SSRF on GHES can reveal cloud credentials that control your entire infrastructure. Yet these tools are rarely integrated into traditional vulnerability scans.

With cveo.tech, inventory your DevSecOps stack (GitHub Enterprise, GitLab, Jenkins, etc.) and get automatic alerts when a critical CVE targets one of your exact versions — so you patch before public exploits land on your CI/CD pipelines.