close notice<\/p>\n
\n This article is also available in It was translated with technical assistance and editorially reviewed before publication.\n <\/p>\n \n Don\u2019t show this again.\n<\/p>\n Eine L\u00fccke mit eingebautem Ohrwurm \u201ePush it\u201c von Salt-N-Pepa: Angreifer mit push-Berechtigung auf einem oder mehreren Repositories k\u00f6nnen einem GitHub Enterprise Server (und GitHub.com) Schadcode aus dem Netz unterjubeln. Dazu gen\u00fcgte ein Standard-git-Client.<\/p>\n Weiterlesen nach der Anzeige<\/p>\n Die IT-Forscher von Wiz haben die L\u00fccke entdeckt und er\u00f6rtern sie in einem Blog-Beitrag<\/a>. Durch das Ausnutzen eines Injection-Fehlers in den internen GitHub-Protokollen konnte jeder authentifizierte Nutzer beliebige Befehle auf den Backend-Servern von GitHub ausf\u00fchren, mit einem einzigen \u201egit push\u201c-Befehl. Wenig \u00fcberraschend merken die Wiz-Forscher an, dass sie die Schwachstelle mit Zuhilfenahme von KI aufgesp\u00fcrt haben. Auf GitHub.com konnten sie Schadcode aus dem Netz auf geteilten Storage-Nodes ausf\u00fchren. Auf GitHub Enterprise Server lie\u00df sich der Server vollst\u00e4ndig kompromittieren, einschlie\u00dflich des Zugriffs auf alle gehosteten Repositories und internen Geheimnisse.<\/p>\n CVE-Eintrag mit knapper Fehlerbeschreibung<\/p>\n GitHub hat einen CVE-Schwachstelleneintrag<\/a> dazu ver\u00f6ffentlicht. Demnach basiert die Schwachstelle auf unzureichender Filterung spezieller Elemente, die in Nutzeranfragen als Optionen zum push-Befehl \u00fcbertragen werden. Sie wurden in interne Service-Header \u00fcbernommen. Da diese Header ein Trennzeichen enthalten k\u00f6nnen, das auch in Nutzereingaben vorkommen kann, konnten Angreifer zus\u00e4tzliche Metadaten-Felder mit manipulierten push-Optionen einschleusen (CVE-2026-3854<\/a>, CVSS4 8.7, Risiko \u201ehoch\u201c). Die Schwachstelle wurde \u00fcber das Bug-Bounty-Programm gemeldet \u2013 ob es eine Pr\u00e4mie gab und in welcher H\u00f6he, schreibt GitHub nicht. Aufgrund einer Schwemme von mit KI-Hilfe generierten Schwachstellenmeldungen gehen zunehmend Projekte dazu \u00fcber, keine Pr\u00e4mien<\/a> mehr auszuzahlen.<\/p>\n GitHub.com habe innerhalb von sechs Stunden nach der Fehlermeldung reagiert und die Sicherheitsl\u00fccken geschlossen, f\u00fchren die IT-Forscher von Wiz aus. Zudem haben die Programmierer die Patches f\u00fcr alle unterst\u00fctzten GitHub-Enterprise-Server-Fassungen ver\u00f6ffentlicht. Eine CVE-Schwachstellennummer mit Beschreibung folgte ebenso schnell. Wiz merkt an, dass zu dem Zeitpunkt der Ver\u00f6ffentlichung des Blog-Beitrags im Laufe des Dienstags noch 88 Prozent der GitHub-Enterprise-Server-Instanzen f\u00fcr die Sicherheitsl\u00fccke anf\u00e4llig waren.<\/p>\n IT-Verantwortliche sollten ihre GitHub-Enterprise-Server-Instanzen daher auf die fehlerkorrigierten St\u00e4nde aktualisieren. GitHub hat die Fehler in diversen Versionen des Enterprise-Servers geschlossen: 3.14.25, 3.15.20, 3.16.16, 3.17.13, 3.18.8, 3.19.4 und 3.20.0 (oder neuer). Die Schwachstellenbeschreibung auf GitHub nennt zudem noch die direkten Vorg\u00e4ngerversionen, Admins sollten jedoch laut GitHub-Blog-Beitrag<\/a> auf die noch j\u00fcngeren Versionen aktualisieren. GitHub weist zudem darauf hin, dass die Sicherheitsl\u00fccke bislang noch nicht in Angriffen missbraucht wurde.<\/p>\n
\n English<\/a>.<\/p>\n