GitHub Enterprise Server CVE-2026-8034 : SSRF via notebook viewer (URL parser confusion)

GitHub Enterprise Server est la version auto-hébergée de GitHub utilisée par les entreprises pour leurs dépôts de code privés — souvent au cœur de l'infrastructure de développement et CI/CD. CVE-2026-8034 (CVSS 9.8) révèle une vulnérabilité SSRF (Server-Side Request Forgery) classique dans le notebook viewer, due à une confusion entre deux parseurs URL différents : celui utilisé pour valider le hostname et celui utilisé pour effectuer la requête HTTP réelle.

L'exploitation permet à un attaquant disposant d'un accès réseau à l'instance de forger des requêtes HTTP depuis le serveur GHES vers des services internes inaccessibles depuis Internet — un classique pour pivoter vers le réseau interne, atteindre des services de metadata cloud (AWS IMDS, GCP), ou attaquer Redis, Elasticsearch, et autres services sans authentification typiquement déployés en interne.

Détails techniques

Le pattern URL parser confusion

L'attaque exploite une asymétrie subtile entre deux bibliothèques de parsing d'URL. Concrètement, le code de validation utilise un parseur (typiquement URL natif de Node.js ou Python urlparse), tandis que la bibliothèque HTTP client utilise un parseur différent (http.request natif, requests, curl). Les deux divergent sur certaines URLs malformées :

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

• Le validateur peut voir allowed.com comme hostname (parseur strict)
• Le client HTTP peut voir evil.com comme hostname (interprétation différente du #@)

Résultat : la validation passe mais la requête réelle frappe une cible différente — l'attaquant injecte ainsi des URLs internes (http://169.254.169.254 pour AWS metadata, http://localhost:6379 pour Redis interne) déguisées en URLs "valides".

Caractéristiques

Produits et versions affectés

Toutes les versions antérieures à 3.21 étaient affectées avant ces patches.

Pour vérifier votre version :

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

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

Exploitation et impact

Conditions d'exploitation

• Accès réseau à l'instance GHES (depuis Internet si exposée, sinon depuis le réseau d'entreprise)
• Aucune authentification GHES requise — l'endpoint vulnérable du notebook viewer accepte des URLs externes

Ce qu'un attaquant peut atteindre via SSRF

1. Services de métadonnées cloud

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

→ Vol des credentials IAM du rôle attaché à l'instance GHES = potentiellement accès admin au compte cloud entier.

2. Services internes non authentifiés

• Redis sur localhost:6379 → exécution de commandes Redis (RCE via CONFIG SET)
• Elasticsearch sur localhost:9200 → lecture/écriture des index
• Docker daemon sur unix socket → escape vers le host
• Kubernetes API sur localhost:6443 → contrôle du cluster

3. Reconnaissance interne

Scan de ports internes via l'instance GHES (qui peut atteindre des subnets non-routés depuis Internet). Cartographie des services internes pour préparer des attaques ultérieures.

4. Bypass des contrôles d'accès

Certaines applications internes utilisent l'IP source comme authentification (whitelist d'IPs internes). Une SSRF depuis GHES fait apparaître les requêtes comme provenant d'une IP "de confiance".

Détection et IOC

Logs GHES

• Audit log : ghe-config check audit_logging_enabled
• Recherchez dans /var/log/github/audit.log les accès au notebook viewer depuis des IPs externes inhabituelles
• Logs Nginx : /var/log/nginx/github.example.com_*.log — requêtes vers le path du notebook viewer avec des paramètres URL inhabituels

# Requêtes suspectes vers le notebook viewer
grep -E "notebook.*\?.*=.*://" /var/log/nginx/github.example.com_access.log | \
  grep -vE "github\.com|githubusercontent\.com"

Indicateurs de SSRF

• Connexions sortantes inattendues depuis le serveur GHES vers :
  • 169.254.169.254 (cloud metadata)
  • localhost, 127.0.0.1
  • IPs RFC1918 internes que GHES n'a normalement pas à contacter
• Apparition de credentials IAM cloud anormalement utilisés (CloudTrail / Azure Activity)

Audit cloud post-incident

Si vous opérez GHES sur AWS/Azure/GCP avec un rôle d'instance attaché :

# AWS — lister les actions effectuées par l'instance role GHES
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=Username,AttributeValue=<ghes-instance-role> \
  --max-results 50

Mitigation et patch

Action immédiate : mettre à jour

GHES applique les correctifs via un fichier .pkg :

# 1. Télécharger le patch correspondant à votre branche depuis enterprise.github.com
# 2. Vérifier la signature
gpg --verify github-enterprise-server-*.pkg.sig

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

Workaround si patch impossible immédiatement

1. Désactiver le notebook viewer si la feature n'est pas utilisée :
   • Site Admin → Settings → désactiver "Show notebooks" si possible
2. Isoler le serveur GHES au niveau réseau :
   • Bloquer le trafic sortant de l'instance GHES vers 169.254.169.254 (metadata cloud)
   • Restreindre les sorties à des destinations explicites (GitHub.com, mirror, etc.)
3. Faire tourner les credentials IAM attachés à l'instance GHES par précaution

Hardening durable

• Renforcer IMDSv2 sur AWS (rendre IMDSv1 indisponible) : aws ec2 modify-instance-metadata-options --http-tokens required
• Sur GCP : utiliser Metadata Server v2 avec en-tête Metadata-Flavor: Google obligatoire
• Auditer l'ensemble des composants qui font des requêtes sortantes sur l'instance GHES — pas juste le notebook viewer

Pourquoi surveiller en continu votre infrastructure de développement

Les outils de développement (GitHub Enterprise, GitLab, Jenkins, Artifactory, Sonatype Nexus…) sont des cibles privilégiées : ils contiennent le code source, les secrets, les credentials de déploiement de toute votre organisation. Une SSRF sur GHES peut révéler les credentials cloud qui contrôlent la totalité de votre infrastructure. Pourtant, ces outils sont rarement intégrés aux scans de vulnérabilités traditionnels.

Avec cveo.tech, inventoriez votre stack DevSecOps (GitHub Enterprise, GitLab, Jenkins, etc.) et soyez alerté automatiquement dès qu'une CVE critique vise une de vos versions exactes — pour patcher avant que les exploits publics ne ciblent vos pipelines CI/CD.