Kritische Sicherheitslücke in GitLab: RCE-Schachstelle betrifft Versionen seit 2014

Security · 21.10.2026

Eine kritische Sicherheitslücke mit der maximalen Risikobewertung CVSS 10.0 gefährdet selbstgehostete GitLab-Server. Betroffen sind Versionen der letzten zwölf Jahre.

In der populären Entwicklerplattform GitLab wurde eine kritische Sicherheitslücke geschlossen, die die maximale Risikobewertung von CVSS 10.0 erhalten hat. Die Schwachstelle ermöglicht es nicht authentifizierten Angreifern, Schadcode auf selbstverwalteten GitLab-Servern auszuführen (Remote Code Execution, RCE). Erschwerend kommt hinzu, dass der Fehler fast alle Softwareversionen der letzten zwölf Jahre betrifft – zurückreichend bis zur Version 7.0 aus dem Jahr 2014.

Warum ist das wichtig?

Viele Unternehmen im DACH-Raum betreiben eigene GitLab-Instanzen, um die volle Kontrolle über ihren Quellcode und ihre CI/CD-Pipelines (Continuous Integration/Continuous Delivery) zu behalten. Ein erfolgreicher Angriff auf diese Systeme kann verheerende Folgen haben. Da für die Ausnutzung keine vorherige Anmeldung am System erforderlich ist, können Angreifer im schlimmsten Fall die vollständige Kontrolle über die Server übernehmen, geistiges Eigentum stehlen oder Schadcode direkt in die Software-Lieferkette einschleusen.

Die Tatsache, dass die Sicherheitslücke seit zwölf Jahren unentdeckt im Code schlummerte, bedeutet auch, dass ältere, vermeintlich stabile und vom Internet isolierte Altsysteme hochgradig gefährdet sind, sobald sie netzwerktechnisch erreichbar werden oder intern exponiert sind. Das Risiko für Betriebsspionage und Sabotage ist hierbei als extrem hoch einzustufen.

Was Nutzer jetzt tun sollten

Administratoren von selbstgehosteten GitLab-Instanzen müssen unverzüglich handeln. Da der Hersteller bereits entsprechende Sicherheitsupdates bereitgestellt hat, ist das Einspielen dieser Patches die einzig wirksame Schutzmaßnahme. Es wird dringend empfohlen, die Versionsstände aller im Unternehmen genutzten GitLab-Server zu prüfen und das Update-Prozedere sofort anzustoßen.

Folgende Schritte sollten priorisiert werden:

• Version prüfen: Ermitteln Sie die genaue installierte Versionsnummer Ihrer GitLab-Instanz.
• Updates einspielen: Installieren Sie unverzüglich die bereitgestellten Sicherheits-Patches für Ihre jeweilige Hauptversion.
• Systeme isolieren: Falls ein sofortiges Update nicht möglich ist, sollten die GitLab-Server temporär vom öffentlichen Internet getrennt oder der Zugriff über VPN und Firewalls streng reglementiert werden.
• Protokolle analysieren: Überprüfen Sie die System- und Zugriffsprotokolle auf ungewöhnliche Aktivitäten, um eine bereits erfolgte Kompromittierung auszuschließen.

Fazit

Die Entdeckung dieser fundamentalen Schwachstelle zeigt erneut, dass auch langjährig genutzte und etablierte Open-Source-Komponenten Risiken bergen können. Ein konsequentes Patch-Management und die schnelle Reaktion der IT-Verantwortlichen sind jetzt essenziell, um die Integrität der eigenen IT-Infrastruktur und der Softwareentwicklungsprozesse zu sichern.

Quelle: The Hacker News