Ruby-Lücken: GitLab wird angegriffen, Scanner schweigen

Ein grünes Ergebnis im Schwachstellen-Scanner heißt nicht immer, dass alles in Ordnung ist. Das zeigt ein Fall, der Betreiber von GitLab und anderen Ruby-Anwendungen gerade betrifft: Vier Fehler in der Regex-Engine von Ruby ermöglichen bei GitLab das Ausführen von Schadcode auf dem ServerHostingDer Speicherplatz auf einem Server, auf dem Ihre Website läuft.Im Glossar ansehen →, teils ohne Anmeldung. Eine der Lücken wird laut der US-Behörde CISA bereits aktiv ausgenutzt. Weil die Fehler aber nur als GitLab-CVEs geführt werden, schlagen Scanner bei veralteten Ruby-Installationen nicht an.

Was passiert ist

Die Fehler stecken in der Art, wie Ruby reguläre Ausdrücke übersetzt. Laut Ruby-Projekt hat GitLab festgestellt, dass speziell präparierte Muster beim Kompilieren den Speicher beschädigen können. Konkret geht es um einen Double Free und mehrere Integer-Überläufe. Gefunden hat einen Teil davon der Sicherheitsforscher Johan Carlsson über das Bug-Bounty-Programm von GitLab.

GitLab hat dafür vier Kennungen vergeben. heise nennt diese Bewertungen:

• CVE-2026-89078 (CVSS 9.9): Double Free beim Einlesen eines Musters
• CVE-2026-93577 (CVSS 9.9): Integer-Überlauf bei der Größe des kompilierten Programms
• CVE-2026-97229 (CVSS 10.0): derselbe Überlauf, ausnutzbar über die CI/CD-Konfiguration
• CVE-2026-110264 (CVSS 10.0): Überlauf interner Zähler bei Mustern mit sehr vielen Wiederholungen

Die beiden mit 10.0 bewerteten Lücken lassen sich laut heise ohne Anmeldung ausnutzen. Bei CVE-2026-97229 kann ein Angreifer präparierte reguläre Ausdrücke in einer CI/CD-Konfiguration unterbringen und so Code auf dem GitLab-Server ausführen. Die CISA hat diese Lücke Ende Oktober in ihren Katalog aktiv ausgenutzter Schwachstellen aufgenommen. Behoben ist sie ab GitLab 19.2.8, 19.3.5 und 19.4.2.

Warum Scanner nichts melden

Das eigentliche Problem liegt in der Zuordnung. Ruby selbst hat für diese Fehler bislang keine eigenen CVEs beantragt. Das Projekt sieht das Kompilieren fremder Muster als etwas, das eine Anwendung ohnehin nicht tun sollte. heise bringt die Folge auf den Punkt:

„Die vier GitLab-CVEs beschreiben GitLab-Versionen, nicht Ruby-Versionen.“

Ein Scanner, der eine Ruby-Installation wie 3.4.11 prüft, findet deshalb keinen Eintrag und meldet nichts. Das Ruby-Projekt empfiehlt selbst, bis auf Weiteres die GitLab-Kennungen zu verwenden, wenn man das Thema etwa in einem Sicherheitsscanner verfolgt. Für frühere, ähnliche Fehler hatte Ruby durchaus CVEs vergeben, das Team will seine Regeln dazu laut heise klarstellen.

Das Beispiel Alpine Linux

Wie leicht man trotz Update angreifbar bleibt, zeigt laut heise Alpine Linux. Auf die GitLab-Instanz des Projekts gab es am 20. und 21. Oktober Angriffe. Dort lief zu diesem Zeitpunkt die anfällige Version 19.3.4. Ein Upgrade von GitLab allein hätte aber nicht gereicht: Der Fix besteht aus einem Ruby-Patch, den Standard-Builds von Ruby nicht enthielten. Wer GitLab mit selbst verwaltetem Ruby betreibt, braucht Ruby 3.3.13, 3.4.12 oder 4.0.9. Alpine fand keine Belege für einen erfolgreichen Einbruch, behandelte die Instanz aber als kompromittiert, baute sie neu auf und setzte alle Passwörter zurück.

Wer betroffen ist

Die Korrekturen stecken in Ruby 4.0.9, 3.4.12 und 3.3.13, veröffentlicht am 23. Oktober. Ruby 3.2 und älter bekommen laut heise keine Updates mehr. Gefährdet sind allerdings nur Anwendungen, die reguläre Ausdrücke aus Eingaben von außen bauen, etwa über Regexp.new, Regexp.union oder das Einsetzen von Nutzereingaben in ein Muster. Das Ruby-Projekt schreibt dazu: Anwendungen, die nur von den eigenen Entwicklern geschriebene reguläre Ausdrücke nutzen, sind nicht betroffen.

Zwei naheliegende Schutzmaßnahmen helfen nicht. Regexp.timeout greift nicht, weil der Fehler schon beim Kompilieren passiert, und eine Längenbegrenzung für Muster ist unzuverlässig, weil manche Fehler auch mit kurzen Mustern auslösbar sind.

Was das für Ihr Unternehmen heißt

• GitLab sofort prüfen: Wer GitLab selbst betreibt, sollte auf eine aktuelle Version gehen. Die Omnibus-Pakete bringen ihr eigenes Ruby mit dem Produkt-Update mit. Bei Installationen aus dem Quellcode oder eigenen Images muss Ruby zusätzlich auf 3.3.13, 3.4.12 oder 4.0.9.
• Ruby-Versionen von Hand kontrollieren: ruby -v auf Servern, in Docker-Images und CI-Runnern prüfen. Docker-Images brauchen ein neues Tag, Distributionspakete kommen teils mit Verzögerung.
• Eigenen Code durchsuchen: In Rails- und Ruby-Anwendungen nach Regexp.new mit Nutzereingaben suchen. Für eine einfache Textsuche reicht oft include?, sonst Eingaben mit Regexp.escape absichern.
• Scanner nicht blind vertrauen: Ein fehlender Treffer ist hier kein Entwarnungssignal. Ähnlich war es bei der Brotli-Lücke, bei der ein Node-Update allein nicht reichte: Mitgelieferte Bibliotheken muss man gezielt nachverfolgen.
• Entwicklungssysteme ernst nehmen: Git-Server und CI-Runner haben Zugriff auf Quellcode und oft auf Zugangsdaten für die Produktion. Wie teuer Angriffe auf diese Ebene werden, hat der LiteLLM-Fall gezeigt.

Fazit

Die Ruby-Lücken sind kein exotisches Detail, sondern betreffen mit GitLab ein System, das in vielen Firmen den gesamten Quellcode verwaltet. Gefährlich macht sie vor allem die Lücke in der Buchführung: Weil die CVEs an GitLab hängen, bleibt eine veraltete Ruby-Version im Scanner unauffällig. Wer selbst gehostete Entwicklungswerkzeuge betreibt, sollte deshalb nicht nur auf Meldungen warten, sondern Laufzeitversionen regelmäßig selbst prüfen. Wenn Sie dabei Unterstützung brauchen, etwa bei Updates oder einer sauberen Übersicht über Ihre Server und Abhängigkeiten, sprechen Sie mich gern an.