GitLab: Kritische Lücke erlaubt Codeausführung aus der Ferne
Was passiert ist
Der Hersteller GitLab hat eine Sicherheitswarnung veröffentlicht und seine Anwenderinnen und Anwender aufgefordert, ein bereitgestelltes Update unverzüglich einzuspielen. Die Schwachstelle betrifft nach Angaben des Unternehmens den Compiler für reguläre Ausdrücke innerhalb der CI/CD-Funktionalität, also jenen Teil der Plattform, der automatisierte Build- und Auslieferungsprozesse steuert.
Die Lücke ist mit der maximalen Schweregradstufe bewertet. Das bedeutet in der Regel, dass ein Angriff ohne vorherige Anmeldung und ohne Zutun eines Nutzers möglich ist. Gelingt die Ausnutzung, können Angreifer aus der Ferne beliebigen Programmcode auf der betroffenen Instanz ausführen – also faktisch die Kontrolle über das System übernehmen. Weitere technische Details zum Ablauf eines Angriffs hat GitLab bislang nicht ausführlich öffentlich gemacht.
Warum das für kleine und mittlere Unternehmen relevant ist
GitLab ist nicht nur bei Großkonzernen im Einsatz. Auch viele kleine Softwarehäuser, Agenturen, Ingenieurbüros und IT-Dienstleister betreiben eigene GitLab-Instanzen, oft auf einem Server im eigenen Rechenzentrum oder bei einem Hoster. Diese Systeme werden selten so konsequent gepatcht wie etwa Arbeitsplatzrechner.
Das Risiko ist dabei besonders hoch, weil eine Entwicklungsplattform ein sensibler Knotenpunkt ist: Dort liegen Quellcode, Konfigurationsdateien, Zugangsschlüssel für Cloud-Dienste und die Automatisierung, die Software in Produktivsysteme ausrollt. Wer diese Umgebung übernimmt, kann im schlimmsten Fall manipulierten Code bis zu Kundinnen und Kunden durchreichen. Genau solche Angriffe auf die Lieferkette stehen im Fokus kommender Regulierung wie NIS2 und des Cyber Resilience Act, die von Unternehmen ein belastbares Schwachstellenmanagement verlangen.
Was Sie jetzt tun sollten
- Prüfen Sie, ob in Ihrem Unternehmen eine selbst betriebene GitLab-Instanz läuft – auch in Testumgebungen oder bei Dienstleistern.
- Spielen Sie die von GitLab bereitgestellte aktualisierte Version zeitnah ein und planen Sie dafür notfalls ein kurzes Wartungsfenster.
- Beschränken Sie den Zugriff auf die Verwaltungsoberfläche, solange kein Patch möglich ist, etwa über VPN oder IP-Freigaben.
- Sehen Sie Protokolle und CI/CD-Jobs auf ungewöhnliche Aktivitäten durch und rotieren Sie bei Verdacht Zugangstoken und Schlüssel.
- Nehmen Sie Entwicklungs- und Buildsysteme fest in Ihren Patch-Prozess auf, statt sie als reine Nebensysteme zu behandeln.
