Alpine Linux: Angriff auf GitLab trotz Update
Alpine Linux hat seine GitLab-Instanz nach Angriffsversuchen über CVE-2026-97229 (CVSS 10) neu aufgebaut. Der Vorfall zeigt: Wer GitLab mit eigenem Ruby betreibt, braucht zusätzlich Ruby 3.3.13, 3.4.12 oder 4.0.9.
Das Alpine-Linux-Projekt hat am 28. Oktober 2026 einen Sicherheitsvorfall auf seiner GitLab-Instanz gitlab.alpinelinux.org offengelegt. Am 20. und 21. Oktober versuchte ein Angreifer, die kritische Lücke CVE-2026-97229 (CVSS 10.0) auszunutzen, eine Woche nach Erscheinen des Fixes. Belege für einen Erfolg fanden die Betreiber nicht, ausschließen können sie ihn aber nicht. Die Instanz wurde deshalb komplett neu aufgebaut, alle Passwörter wurden zurückgesetzt.
Die eigentliche Lehre betrifft alle Betreiber selbst gehosteter GitLab-Instanzen: Das GitLab-Update allein hat bei Alpine nicht gereicht. Der Fix steckt in einem Patch an Ruby, den GitLab nur in seinen offiziellen Paketen und Images mitliefert. Wer GitLab mit eigenem Ruby betreibt, etwa als Quellinstallation oder in einem selbst gebauten Container, braucht zusätzlich ein aktuelles Ruby. Wer die offiziellen Omnibus-Pakete oder Images auf dem Stand vom 12. Oktober oder neuer nutzt, ist laut Alpine nicht in dieser Lage. Für alle anderen gilt: heute prüfen, nicht bis zum nächsten Wartungsfenster warten.
Was ist passiert?
CVE-2026-97229 ist laut GitLab ein Integer Overflow im Compiler für reguläre Ausdrücke, der bei der Auswertung von CI/CD-Konfigurationen greift. Ein nicht angemeldeter Angreifer kann damit unter bestimmten Bedingungen beliebigen Code auf dem Server ausführen. Die Ursache liegt in Onigmo, der in Ruby eingebauten Regex-Engine. GitLab veröffentlichte am 12. Oktober die Versionen 19.4.2, 19.3.5 und 19.2.8 mit dem Fix. Betroffen sind laut Advisory alle Versionen ab 19.2 vor 19.2.8, ab 19.3 vor 19.3.5 und ab 19.4 vor 19.4.2.
Alpine aktualisierte am 13. Oktober versehentlich auf 19.3.4 statt 19.3.5. Ab dem 20. Oktober schickte ein frisch registriertes Konto präparierte CI-Konfigurationen, GitLab-Worker stürzten achtmal ab, in vier Fällen kam der Angreifer laut Alpine ein Stück weit durch den Exploit. Er lud zudem das GitLab-Image des Projekts herunter, was auf ein Feintuning am konkreten Build hindeutet. Das Upgrade auf 19.3.6 am 22. Oktober schloss die Lücke nicht, weil das eigene Image ein Standard-Ruby ohne GitLabs Patch nutzte. Erst am 26. Oktober fiel das auf, am 27. Oktober wurde die Instanz geschlossen und neu aufgebaut.
Wer ist betroffen?
Laut ruby-lang.org geht es um vier GitLab-CVEs, deren Ursache in Onigmo liegt: CVE-2026-89078, CVE-2026-93577, CVE-2026-97229 und CVE-2026-110264. Ruby hat am 23. Oktober die Versionen 3.3.13, 3.4.12 und 4.0.9 veröffentlicht, die alle vier Fehler beheben. Kritisch sind GitLab-Installationen mit eigenem Ruby. Betroffen ist zudem jede Ruby-Anwendung, die reguläre Ausdrücke aus nicht vertrauenswürdigen Eingaben kompiliert, etwa per Regexp.new. Laut Ruby schützen weder Regexp.timeout noch eine Längenbegrenzung der Muster zuverlässig. Wer das Image alpinelinux/gitlab nutzt, muss das Tag 19.3.6 neu ziehen: Erst das Image vom 27. Oktober enthält Ruby 3.3.13. Ältere Pulls und Tags sind verwundbar. Das Ruby-Paket von Alpine selbst ist aktuell (3.4.12 ab Alpine 3.22, 3.3.13 in 3.21).
Wie kritisch ist das?
Sehr kritisch. Die Lücke erlaubt Codeausführung ohne Anmeldung, und der Vorfall zeigt, dass Angreifer gepatchte Versionen gezielt gegen nicht vollständig aktualisierte Builds testen. Alpine nennt als möglicherweise abgeflossene Daten bei einem Erfolg unter anderem Passwort-Hashes, 2FA-Geheimnisse, CI/CD-Variablen, Runner-Tokens und private Repositories. Pakete, Releases und Signaturschlüssel waren laut Projekt nicht betroffen. Problematisch ist auch die Spurenlage: Ein erfolgreicher Exploit hinterlässt laut Alpine weder Absturz noch Eintrag im Weblog.
Was sollten Admins jetzt tun?
- Inventar prüfen: GitLab-Version und Installationsart feststellen (Omnibus, offizielles Image, Quellinstallation, eigenes Image) und bei eigenem Ruby die Version mit ruby -v kontrollieren.
- GitLab mindestens auf den Stand vom 12. Oktober bringen, besser auf die Critical Patch Releases vom 21. Oktober.
- Bei eigenem Ruby auf 3.3.13, 3.4.12, 4.0.9 oder neuer aktualisieren und eigene Images neu bauen.
- Logs auf gehäufte Worker-Abstürze und auffällige CI-Lint-Anfragen prüfen. GitLab hat dazu sechs Detection-Regeln veröffentlicht.
- Bei Verdacht Tokens, Runner-Registrierungen und CI-Variablen rotieren. Offene Registrierung neuer Konten kritisch prüfen.
Einordnung für Unternehmen
Der Fall zeigt eine typische Falle bei selbst gebauten Images: Die Versionsnummer der Anwendung sagt nichts darüber aus, ob gebündelte Laufzeit-Patches enthalten sind. Alpine zieht daraus selbst Konsequenzen, kritische GitLab-Releases sollen binnen eines Tages eingespielt und auf Ruby-Patches geprüft werden, ausgehende Verbindungen werden künftig protokolliert. Unternehmen mit eigenen GitLab-Builds sollten diesen Prüfschritt fest in ihren Patch-Prozess aufnehmen. Hintergrund zur verwandten Lücke CVE-2026-110264 liefert unser Bericht zum GitLab-Patch vom 21. Oktober.
Passende Anleitungen auf S-EDV
- GitLab CE mit Docker als DevOps-Plattform betreiben
- Docker-Container-Updates überwachen mit Diun und WUD
- Docker-Images mit Trivy auf Schwachstellen scannen
