Self-hosted GitLab: kritische RCE-Lücke bei Angriff auf Alpine Linux ausgenutzt

Was passiert ist

Am 20. und 21. Oktober haben Angreifer versucht, eine kritische Remote-Code-Execution-Lücke in GitLab auf der Entwicklungsinfrastruktur von Alpine Linux auszunutzen. Der Vorfall wurde am 1. November 2026 öffentlich bekannt. Aus Sorge vor einer möglichen Kompromittierung hat das Alpine-Linux-Projekt seinen GitLab-Server neu aufgesetzt und alle Passwörter zurückgesetzt.

Der Bericht nennt weder die konkrete Schwachstelle noch die betroffenen GitLab-Versionen. Deutlich wird jedoch, dass eine kritische GitLab-Lücke aktiv gegen aus dem Internet erreichbare GitLab-Server eingesetzt wird.

Wer betroffen ist

Betroffen ist jeder, der eine selbst gehostete GitLab-Instanz betreibt, insbesondere Instanzen, die aus dem Internet erreichbar sind. Dazu gehören auch GitLab-Server, die Behörden für Kundenprojekte, CI/CD-Pipelines und Deployments nutzen. Ein kompromittierter GitLab-Server kann Quellcode, gespeicherte Geheimnisse, CI/CD-Variablen, Deploy-Keys und den Zugang zu den Systemen offenlegen, auf die er deployt.

GitLab.com (der gehostete Dienst) wird von GitLab selbst betrieben; diese Warnung betrifft Server, die Sie selbst betreiben.

Was Sie jetzt tun sollten

1. Prüfen Sie, welche GitLab-Version Ihre Instanz verwendet (Admin-Bereich > Übersicht oder gitlab-rake gitlab:env:info bei Omnibus-Installationen).
2. Vergleichen Sie diese mit dem neuesten GitLab-Sicherheitsrelease. Die korrigierten Versionen sind in unseren Quelldaten nicht enthalten. Prüfen Sie daher den Sicherheitshinweis des Herstellers und die Release-Notes zu GitLab-Sicherheitsupdates auf die Versionen, die die kritische Lücke schließen.
3. Sichern Sie Ihre GitLab-Konfiguration und Secrets (bei Omnibus: /etc/gitlab/gitlab.rb und /etc/gitlab/gitlab-secrets.json) und legen Sie ein reguläres Backup an.
4. Aktualisieren Sie GitLab auf das neueste Patch-Release Ihrer Versionslinie, über Ihren Paketmanager oder das Docker-Image. Führen Sie anschließend gitlab-ctl reconfigure aus, falls Ihre Installation dies erfordert.
5. Stellen Sie mit gitlab-ctl status sicher, dass alle Dienste laufen, und prüfen Sie, ob Anmeldung, Repositories und CI-Pipelines funktionieren.
6. Falls Sie nicht sofort aktualisieren können, beschränken Sie den Zugriff auf die Instanz, beispielsweise auf ein VPN oder bekannte IP-Adressen, bis das Update eingespielt ist.
7. Falls Sie Anzeichen einer Kompromittierung finden (siehe unten), gehen Sie wie Alpine Linux vor: Behandeln Sie den Server als kompromittiert, setzen Sie ihn aus einem sauberen Zustand neu auf und setzen Sie Passwörter, persönliche Zugriffstoken, Deploy-Keys, Runner-Token und CI/CD-Geheimnisse zurück.

So prüfen Sie, ob Sie betroffen waren

• Sichten Sie die GitLab-Logs (bei Omnibus unter /var/log/gitlab/, zum Beispiel gitlab-rails/production_json.log, api_json.log und die nginx-Zugriffsprotokolle) auf ungewöhnliche Anfragen, Fehler oder Zugriffe von unbekannten IP-Adressen, insbesondere rund um und nach dem 20. Oktober.
• Prüfen Sie im Admin-Bereich auf neue oder unerwartete Benutzer, Administratoren, persönliche Zugriffstoken, SSH-Keys, Deploy-Keys, Webhooks und Runner.
• Kontrollieren Sie die Audit-Ereignisse auf Änderungen an Berechtigungen, Projekteinstellungen oder CI/CD-Variablen, die Sie nicht vorgenommen haben.
• Suchen Sie auf dem Server selbst nach unbekannten Prozessen, neuen Cron-Jobs, unerwarteten Dateien in den GitLab-Verzeichnissen und ausgehenden Verbindungen zu unbekannten Hosts.
• Prüfen Sie aktuelle Commits und Pipeline-Definitionen (.gitlab-ci.yml) auf Änderungen, die niemand in Ihrem Team vorgenommen hat.

Quellen

• https://www.cisa.gov/known-exploited-vulnerabilities-catalog
• https://www.bleepingcomputer.com/news/security/alpine-linux-rebuilds-gitlab-after-attempted-rce-attack/