Git-Push reicht für RCE auf GitHub-Enterprise-Servern
Am 28. April 2026 haben Wiz Research und GitHub die Details zu CVE-2026-3854 veröffentlicht: Eine Command-Injection-Schwachstelle in GitHub Enterprise Server erlaubt jedem authentifizierten Nutzer mit Push-Zugriff auf ein Repository, beliebigen Code auf dem Server auszuführen – mit einem einzigen git push. 88 Prozent der Self-Hosted-Instanzen waren zum Disclosure-Zeitpunkt noch ungepatcht.
6 Min. Lesezeit
Das Wichtigste in Kürze
- CVSS 8.7 – ein einzelner git push reicht. Jeder User mit Push-Zugriff auf ein Repository – auch ein selbst erstelltes – kann beliebige Befehle auf dem GitHub-Enterprise-Server ausführen. Kein Exploit-Kit, nur ein standard git client.
- Command-Injection im Push-Option-Handling. Push-Option-Werte wurden vor der Verarbeitung nicht ausreichend bereinigt. Ein Angreifer kann über ein Delimiter-Zeichen zusätzliche Metadaten-Felder in interne Service-Header injizieren.
- GitHub.com war innerhalb von Stunden gepatcht. Wiz Research entdeckte die Lücke am 4. März 2026, meldete sie GitHub am selben Tag. Patch auf GitHub.com: noch am 4. März. GHES-Patches: 10. März. Öffentliches Disclosure: 28. April 2026.
- Patches für alle unterstützten GHES-Versionen verfügbar. 3.14.25, 3.15.20, 3.16.16, 3.17.13, 3.18.7, 3.19.4, 3.20.0 und höher. Wer ältere Versionen betreibt, hat keinen Support-Pfad mehr.
Der Angriff erklärt: Warum ein git push für RCE reicht
Git Push Operations unterstützen sogenannte Push Options – benutzerdefinierte Schlüssel-Wert-Paare, die Metadaten zum Push übergeben. GitHub Enterprise Server verarbeitete diese Werte in einem internen Protokoll, ohne den Delimiter-Charakter ausreichend zu escapen. Weil dieser Delimiter in User-Input vorkommen kann, lassen sich durch crafted Push-Option-Werte zusätzliche Header-Felder in die interne Kommunikation injizieren.
Das Ergebnis ist Code-Execution auf dem Server – nicht im Repository-Layer, sondern im Backend-Service, der den Push verarbeitet. Wiz Research beschreibt den Angriff als vollständig mit einem Standard-Git-Client reproduzierbar. Kein spezielles Tool, keine pre-existing Schwachstelle, keine besondere Autorisierung außer einem Repository mit Push-Zugriff.
Das Angriffsszenario ist damit niedriger Barriere: Jeder externe Contributor, jeder Mitarbeiter mit Repository-Zugriff, jeder kompromittierte Account kann diese Lücke ausnutzen. In Enterprise-Umgebungen mit Large-Scale-Self-Hosted-GitHub-Deployments ist das Radius erheblich.
Disclosure-Timeline: Was zwischen März und April passiert ist
4. März 2026: Wiz Research entdeckt und meldet die Lücke verantwortungsbewusst an GitHub. GitHub deployed innerhalb von Stunden einen Fix auf GitHub.com.
10. März 2026: Patches für alle unterstützten GitHub Enterprise Server-Versionen werden veröffentlicht: 3.14.25, 3.15.20, 3.16.16, 3.17.13, 3.18.7, 3.19.4, 3.20.0. CVE-2026-3854 wird mit CVSS 8.7 zugewiesen.
28. April 2026: Öffentliches Disclosure nach abgeschlossener koordinierter Offenlegung. Zum diesem Zeitpunkt sind nach Help Net Security-Recherche 88 Prozent der Self-Hosted-Instanzen noch ungepatcht – fast sieben Wochen nach Verfügbarkeit der Fixes.
88 Prozent ungepatcht. Sieben Wochen nach dem GHES-Patch läuft nahezu jede Self-Hosted-Instanz noch auf der verwundbaren Version. Das ist kein Ausnahmefall – das ist der Normalzustand bei Enterprise-Git-Infrastruktur.
Was Security-Teams in DACH jetzt konkret tun müssen
1. GHES-Version sofort prüfen. Aktuell gepatchte Minimum-Versionen: 3.14.25, 3.15.20, 3.16.16, 3.17.13, 3.18.7, 3.19.4, 3.20.0. Wer darunter liegt oder Versionen vor 3.14 betreibt, ist ohne Support-Pfad und muss upgraden.
2. Repository-Zugriffsrechte auditieren. Wer hat Push-Zugriff auf welche Repositories? Externe Contributor, veraltete Service-Accounts, temporäre Zugänge? Jeder dieser Accounts ist ein potenzieller Angriffspfad – unabhängig davon ob das Repository öffentlich oder intern ist.
3. Server-Logs auf Anomalien prüfen. GitHub stellt Logging für Push-Operationen bereit. Ungewöhnliche Push-Option-Werte, Pushes von unbekannten IP-Adressen oder zu unüblichen Zeiten sollten auf manuelle Überprüfung eskaliert werden.
4. Network-Layer-Controls prüfen. Der GHES-Admin-Port (8443) und die internen Service-Endpunkte sollten nicht aus dem öffentlichen Internet erreichbar sein. Das reduziert den Angriffspfad nicht auf null, aber erhöht die Barriere für externe Angreifer.
Häufige Fragen zu CVE-2026-3854
Betrifft CVE-2026-3854 auch GitHub.com oder nur Self-Hosted-Instanzen?
Beides war betroffen. GitHub.com hat innerhalb von Stunden nach dem Responsible Disclosure von Wiz Research am 4. März 2026 einen Fix deployed. Nutzer von GitHub.com sind seit dem 4. März geschützt. Das Risiko liegt ausschließlich bei Organizations, die GitHub Enterprise Server selbst betreiben und noch nicht auf die gepatchten Versionen aktualisiert haben.
Müssen alle Repositories auf einem GHES-Server als kompromittiert betrachtet werden?
Das hängt davon ab, ob die Lücke aktiv ausgenutzt wurde. Ein Patch schließt den Angriffsvektor, behebt aber keine bereits stattgefundene Kompromittierung. Organisationen mit sensiblem Code (Infrastruktur-As-Code, Credentials in Repositories, CI/CD-Pipeline-Konfigurationen) sollten die Git-History und Server-Logs auf verdächtige Aktivitäten seit März 2026 überprüfen. Im Zweifel: Incident-Response-Prozess einleiten.
Können GitHub Actions oder CI/CD-Pipelines die Schwachstelle ausnutzen?
Ja. Jede automatisierte Komponente die Git-Push-Operationen ausführt – Actions-Workflows, CI/CD-Runner, Deployment-Scripts – ist ein potenzieller Angriffsvektor, wenn sie auf einem verwundbaren GHES läuft. Besonders relevant: External Runners, die Zugriff auf mehrere Repositories haben und deren Credentials kompromittiert sein könnten.
Was ist der Unterschied zur Supply-Chain-Schwachstelle im Bitwarden CLI GitHub Action?
CVE-2026-3854 ist eine Server-Side-Schwachstelle – der Angriff trifft den GitHub Enterprise Server selbst. Die Bitwarden CLI GitHub Action Schwachstelle ist ein Supply-Chain-Angriff über externe Abhängigkeiten in Pipelines. Beides ist kritisch, aber mit unterschiedlichen Schutzmechanismen: Patch-Management für CVE-2026-3854, Dependency-Pinning und SBOM-Prozesse für Supply-Chain-Risiken.
Lesetipps der Redaktion
Mehr aus dem MBF Media Netzwerk
Quelle Titelbild: Pexels / Markus Spiske (px:1089438)
