GitLab hat eine kritische Sicherheitslücke geschlossen, die mit dem maximalen CVSS-Wert von 10,0 bewertet wird. Die Schwachstelle CVE-2026-110264 kann unter bestimmten Voraussetzungen dazu führen, dass Angreifer ohne Anmeldung fremden Programmcode auf einem GitLab-Server ausführen. Betroffen sind selbst betriebene Installationen der GitLab Community Edition und Enterprise Edition. Seit dem 21. Oktober 2026 gibt es sieben korrigierte Versionen.
Am 22. Oktober 2026 hat außerdem CERT-EU eine dringende Sicherheitswarnung herausgegeben. Die europäische Sicherheitsbehörde rät, betroffene Systeme so schnell wie möglich zu aktualisieren und vor allem öffentlich erreichbare GitLab-Server auf mögliche Angriffsspuren zu untersuchen. Wir erklären die Hintergründe, zeigen alle betroffenen Versionen und geben praktische Empfehlungen für Administratoren.
CERT-EU warnt vor kritischer GitLab-Sicherheitslücke CVE-2026-110264
Die Sicherheitslücke CVE-2026-110264 gehört zu den schwerwiegendsten Sicherheitsproblemen, die ein Softwarehersteller melden kann. GitLab bewertet sie nach CVSS 3.1 mit 10,0 von maximal 10 Punkten. Auch CERT-EU übernimmt diese Einstufung und empfiehlt Unternehmen, ihre selbst verwalteten GitLab-Installationen schnellstmöglich zu aktualisieren.
Besonders gefährlich ist, dass ein Angriff unter bestimmten Voraussetzungen ohne gültige Zugangsdaten möglich wäre. Ein Angreifer müsste sich also nicht erst als Benutzer anmelden, um die verwundbare Funktion anzugreifen. Gelingt der Angriff, könnte er Programmcode auf dem betroffenen GitLab-Server ausführen und dessen Sicherheit damit erheblich gefährden.
Das Risiko ist vor allem für Unternehmen relevant, die GitLab zur Verwaltung von Quellcode, Entwicklungsprojekten und automatisierten Bereitstellungsprozessen einsetzen. Solche Systeme können vertrauliche Projekte, Zugangsdaten und Verbindungen zu anderen IT-Diensten enthalten. Eine Kompromittierung könnte deshalb weitere Unternehmenssysteme gefährden.
Was steckt hinter CVE-2026-110264?
Nach Angaben von GitLab befindet sich die Schwachstelle in einem Compiler für reguläre Ausdrücke. Reguläre Ausdrücke, häufig auch Regex genannt, werden verwendet, um bestimmte Textmuster zu erkennen oder Inhalte zu verarbeiten. Solche Funktionen kommen in vielen Softwareprodukten zum Einsatz und sind grundsätzlich nichts Ungewöhnliches.
Im aktuellen Fall kann ein speziell präparierter regulärer Ausdruck einen sogenannten Integer Overflow auslösen. Dabei überschreitet ein berechneter Zahlenwert den vorgesehenen Wertebereich. Behandelt die Software diesen Fehler nicht korrekt, können daraus schwere Speicherfehler und weitere Sicherheitsprobleme entstehen.
GitLab bestätigt, dass die Schwachstelle unter bestimmten Bedingungen eine Codeausführung aus der Ferne ermöglicht. Diese Angriffsart nennt man Remote Code Execution, kurz RCE. Sie zählt zu den gefährlichsten Sicherheitsproblemen, weil Angreifer unter Umständen eigene Befehle auf einem fremden System ausführen können.
Warum erreicht die GitLab-Sicherheitslücke CVSS 10,0?
Der Hersteller gibt für CVE-2026-110264 folgenden CVSS-Vektor an:
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:HDie Bewertung beschreibt unter anderem einen möglichen Angriff über das Netzwerk mit geringer Angriffskomplexität. Es werden keine vorherigen Benutzerrechte und keine zusätzliche Interaktion eines Anwenders vorausgesetzt. Außerdem bewertet GitLab die möglichen Auswirkungen auf Vertraulichkeit, Integrität und Verfügbarkeit als hoch.
Das bedeutet allerdings nicht, dass jeder erreichbare GitLab-Server bereits kompromittiert wurde. Der CVSS-Wert beschreibt die technische Schwere der Schwachstelle und nicht die Anzahl tatsächlich erfolgreicher Angriffe. Trotzdem rechtfertigt die maximale Bewertung eine sehr hohe Priorität bei der Aktualisierung.
Welche GitLab-Versionen sind betroffen?
GitLab nennt zahlreiche betroffene Versionen der Community Edition und Enterprise Edition. Die Schwachstelle reicht bis zu älteren Versionen der Software zurück. Selbst Installationen, die bereits andere Oktober-Sicherheitsupdates erhalten haben, können weiterhin verwundbar sein.
Die folgende Tabelle enthält die von GitLab bestätigten betroffenen Versionsreihen und die ersten korrigierten Versionen.
| GitLab-Versionsreihe | Betroffene Versionen | Erste korrigierte Version |
|---|---|---|
| 7.0 bis 18.11 | Ab 7.0, vor 18.11.13 | 18.11.13 |
| 19.0 | Vor 19.0.10 | 19.0.10 |
| 19.1 | Vor 19.1.9 | 19.1.9 |
| 19.2 | Vor 19.2.9 | 19.2.9 |
| 19.3 | Vor 19.3.6 | 19.3.6 |
| 19.4 | Vor 19.4.3 | 19.4.3 |
| 19.5 | Vor 19.5.1 | 19.5.1 |
Die Sicherheitskorrektur wurde auch auf mehrere ältere Versionsreihen zurückportiert. Dadurch können Administratoren zunächst innerhalb ihrer verwendeten Version aktualisieren, sofern die entsprechende Version unterstützt wird. Ein Wechsel auf die aktuelle Hauptversion 19.5 ist nicht in jedem Fall unmittelbar erforderlich.
Bei sehr alten Installationen muss man allerdings den unterstützten Upgradepfad beachten. Bei größeren Versionssprüngen sieht GitLab bestimmte Zwischenversionen vor. Ein direkter Sprung von einer viele Jahre alten Installation auf die neueste Version ist deshalb nicht immer möglich.
GitLab veröffentlicht insgesamt zwölf Sicherheitskorrekturen
Neben CVE-2026-110264 enthält die Sicherheitsveröffentlichung vom 21. Oktober 2026 elf weitere Korrekturen. Zwei dieser Schwachstellen bewertet GitLab mit dem Schweregrad Hoch, fünf mit Mittel und vier mit Niedrig. Damit betrifft das aktuelle Update nicht nur die Ausführung fremden Programmcodes, sondern auch zusätzliche Funktionen der Authentifizierung und Zugriffskontrolle.
| CVE | Sicherheitsproblem | CVSS 3.1 |
|---|---|---|
| CVE-2026-110264 | Integer Overflow mit möglicher Codeausführung | 10,0 |
| CVE-2026-15723 | Fehlerhafte Authentifizierung bei OmniAuth und LDAP | 8,2 |
| CVE-2026-112212 | Cache Poisoning bei OAuth/OIDC | 7,5 |
Besonders interessant ist CVE-2026-15723. Bei bestimmten Konfigurationen von OmniAuth SAML und LDAP konnte ein bereits angemeldeter Benutzer unter Umständen ein bestehendes LDAP-Konto übernehmen. Die Schwachstelle erforderte allerdings eine entsprechende Kombination aktivierter Authentifizierungsfunktionen.
Die ebenfalls behobene CVE-2026-112212 betrifft die Verarbeitung bestimmter OAuth- und OpenID-Connect-Informationen. Unter geeigneten Umständen konnte ein Angreifer dabei zwischengespeicherte Informationen manipulieren und so bestimmte Authentifizierungsabläufe beeinflussen. Auch diese Schwachstelle sollte man bei der Aktualisierung im Blick behalten.
Falls Deine Firma GitLab mit Microsoft Active Directory verbindet, ist eine Überprüfung der verwendeten Authentifizierungskonfiguration sinnvoll. Die Grundlagen der Verzeichnisverwaltung behandeln wir in unserer Anleitung PowerShell Befehle für Active Directory.
Ist GitLab.com ebenfalls betroffen?
GitLab unterscheidet ausdrücklich zwischen selbst betriebenen Installationen und seinen verwalteten Cloudangeboten. Laut Hersteller wurde GitLab.com bereits mit der korrigierten Software ausgestattet. Anwender der regulären GitLab-Cloudplattform müssen deshalb kein eigenes Serverupdate durchführen.
Auch GitLab Dedicated läuft laut Hersteller bereits auf korrigierten internen Versionen. Kunden mit Dedicated-Installationen müssen für die hier beschriebenen Schwachstellen daher nicht selbst eingreifen, sofern die von GitLab genannten Versionsvoraussetzungen erfüllt sind.
Anders sieht es bei GitLab Self-Managed aus. Wenn Du GitLab auf einem eigenen Linux-Server, einer virtuellen Maschine oder innerhalb einer selbst verwalteten Containerumgebung betreibst, musst Du die Installation selbst überprüfen und aktualisieren. Die Verantwortung für den verwendeten Versionsstand liegt in diesem Fall bei der jeweiligen IT-Abteilung.
Schritt für Schritt: GitLab-Version überprüfen und Sicherheitsupdate installieren
Bevor Du die neue Sicherheitsversion installierst, solltest Du zunächst feststellen, welche GitLab-Ausgabe tatsächlich verwendet wird. Die folgenden Schritte beziehen sich hauptsächlich auf selbst verwaltete Installationen. Je nach Installationsart können sich die Befehle und erforderlichen Wartungsschritte unterscheiden.
Schritt 1: Installierte GitLab-Version feststellen
Bei einer klassischen GitLab-Installation über Linux-Pakete kannst Du die Versionsinformationen direkt auf dem Server abfragen. Dazu eignet sich der folgende Befehl:
sudo gitlab-rake gitlab:env:infoDie Ausgabe enthält unter anderem Angaben zur GitLab-Version und zur Serverumgebung. Achte bitte auf den Versionsstand und darauf, ob die Community Edition oder die Enterprise Edition im Einsatz ist. Das Ergebnis kannst du danach mit der Tabelle der betroffenen Versionen vergleichen.
Falls Du Deinen GitLab-Server über eine gesicherte SSH-Verbindung administrierst, findest Du in unserem Beitrag Windows und Linux-VPS sicher verbinden weitere Informationen zu sicheren Verwaltungszugängen.
Schritt 2: Datensicherung unbedingt durchführen und überprüfen
Vor einer Aktualisierung empfiehlt sich eine vollständige und überprüfte Datensicherung. Bei GitLab betrifft das nicht nur die gespeicherten Git-Projekte, sondern auch Datenbanken, Konfigurationen und weitere Anwendungsdaten. Besonders wichtig sind die GitLab-Konfigurationsdateien und die zugehörigen Secrets, die gesondert gesichert werden müssen.
Bei einer Installation über das GitLab-Linux-Paket kannst Du eine Anwendungssicherung mit folgendem Befehl erstellen:
sudo gitlab-backup createDieser Befehl passt nicht automatisch zu jeder Installationsart. Er sichert außerdem nicht zwingend alle externen Objektspeicher oder Konfigurationsdateien. Bei Docker und Kubernetes gelten teils andere Verfahren. Die Sicherung sollte deshalb zur tatsächlichen Installationsumgebung passen.
Schritt 3: Passende korrigierte Version auswählen
Überprüfe zunächst den vom Hersteller vorgesehenen Upgradepfad. Wenn Du beispielsweise GitLab 19.5.0 verwendest, ist 19.5.1 die passende korrigierte Version dieser Versionsreihe. Bei GitLab 19.4.2 ist dagegen mindestens 19.4.3 erforderlich.
Besonders bei großen Versionssprüngen sind die vorgesehenen Zwischenversionen und Datenbankmigrationen zu beachten. GitLab empfiehlt, erforderliche Migrationsschritte abzuschließen, bevor das nächste Versionsupgrade ausgeführt wird. Eine überstürzte Aktualisierung kann ansonsten zu Funktionsproblemen oder längeren Wartungsarbeiten führen.
Schritt 4: GitLab aktualisieren
Die eigentliche Installation läuft über den Updateweg, der zu deiner Umgebung passt. Bei Linux-Paketinstallationen kommen normalerweise die offiziellen GitLab-Paketquellen zum Einsatz. In Docker-Umgebungen müssen die passenden Containerimages aktualisiert und neu bereitgestellt werden. Kubernetes-Installationen brauchen dagegen die vorgesehenen Helm-Chart-Updates.
Für Entwicklungs- und Testumgebungen unter Windows 11 kannst Du Dich ergänzend über Docker unter Windows informieren. Auch das Windows Subsystem für Linux ist für Entwickler interessant. Beachte jedoch, dass eine Aktualisierung des Windows-Computers keine eigenständige GitLab-Serverinstallation auf einem anderen System absichert.
Schritt 5: Version und Dienste nach dem Update überprüfen
Nach der Installation sollte die neue GitLab-Version erneut kontrolliert werden. Zusätzlich empfiehlt sich eine Prüfung der wichtigsten Dienste und Funktionen. Bei einer klassischen Linux-Paketinstallation kannst Du dafür folgenden Befehl verwenden:
sudo gitlab-ctl statusAnschließend solltest Du die Anmeldung, den Zugriff auf Projekte, das Klonen von Repositories und vorhandene CI/CD-Pipelines überprüfen. Bei größeren Installationen müssen zusätzlich die Datenbankmigrationen und der Zustand einzelner GitLab-Komponenten berücksichtigt werden. Ein erfolgreicher Dienststart allein beweist noch nicht, dass sämtliche Funktionen ordnungsgemäß arbeiten.
GitLab Sicherheitsupdates herunterladen
GitLab hat die korrigierten Versionen bereits am 21. Oktober 2026 veröffentlicht. Die folgenden Versionen stehen für GitLab Community Edition und Enterprise Edition zur Verfügung. Der genaue Installationsweg hängt vom verwendeten Betriebssystem, der Paketverwaltung und der gewählten Bereitstellungsform ab.
.wfde-gl-downloads,
.wfde-gl-downloads * {
box-sizing: border-box;
}
.wfde-gl-downloads {
background: linear-gradient(140deg,#0a1730,#142e52);
border: 1px solid #28476b;
border-radius: 18px;
padding: 30px;
margin: 30px 0;
color: #eaf2ff;
font-family: inherit;
box-shadow: 0 12px 32px rgba(0,19,44,.17);
}
.wfde-gl-downloads .wfde-gl-head {
padding-bottom: 22px;
margin-bottom: 23px;
border-bottom: 1px solid rgba(255,255,255,.15);
}
.wfde-gl-downloads .wfde-gl-kicker {
color: #86cdff;
font-size: 12px;
font-weight: 700;
letter-spacing: 1.2px;
}
.wfde-gl-downloads .wfde-gl-title {
color: #fff !important;
font-size: clamp(22px,3vw,30px) !important;
line-height: 1.3 !important;
font-weight: 700;
margin: 12px 0 !important;
padding: 0 !important;
}
.wfde-gl-downloads .wfde-gl-intro {
color: #c6d6eb !important;
font-size: 15px;
line-height: 1.75;
margin: 0 !important;
}
.wfde-gl-downloads .wfde-gl-grid {
display: grid;
grid-template-columns: repeat(2,minmax(0,1fr));
gap: 15px;
}
.wfde-gl-downloads .wfde-gl-card {
background: #f8fbff;
border: 1px solid #d6e4f4;
border-radius: 13px;
padding: 20px;
color: #182943;
min-width: 0;
transition: transform .2s ease,box-shadow .2s ease;
}
.wfde-gl-downloads .wfde-gl-card:hover {
transform: translateY(-3px);
box-shadow: 0 9px 25px rgba(0,0,0,.2);
}
.wfde-gl-downloads .wfde-gl-cardtop {
display: flex;
align-items: center;
gap: 12px;
}
.wfde-gl-downloads .wfde-gl-icon {
display: flex;
align-items: center;
justify-content: center;
flex: 0 0 45px;
width: 45px;
height: 45px;
border-radius: 10px;
background: #fff0e1;
color: #b96719;
font-weight: 800;
font-size: 14px;
}
.wfde-gl-downloads .wfde-gl-icon.blue {
background: #e6f1ff;
color: #1767cb;
}
.wfde-gl-downloads .wfde-gl-icon.green {
background: #e0f5eb;
color: #168151;
}
.wfde-gl-downloads .wfde-gl-icon.purple {
background: #ede7fc;
color: #7048c7;
}
.wfde-gl-downloads .wfde-gl-name {
color: #142743 !important;
font-size: 17px !important;
line-height: 1.35 !important;
font-weight: 700;
padding: 0 !important;
margin: 0 !important;
}
.wfde-gl-downloads .wfde-gl-desc {
color: #51657f !important;
font-size: 14px;
line-height: 1.7;
margin: 13px 0 !important;
}
.wfde-gl-downloads .wfde-gl-version {
display: inline-block;
background: #e0f5eb;
border: 1px solid #cce7d9;
border-radius: 7px;
padding: 7px 12px;
font-weight: 700;
font-size: 15px;
color: #176c48;
}
.wfde-gl-downloads .wfde-gl-action {
text-align: center;
margin-top: 21px;
padding: 22px;
background: rgba(255,255,255,.07);
border: 1px solid rgba(255,255,255,.16);
border-radius: 12px;
}
.wfde-gl-downloads .wfde-gl-actiontitle {
color: #fff !important;
font-size: 19px !important;
font-weight: 700;
margin: 0 0 10px !important;
}
.wfde-gl-downloads .wfde-gl-actiontext {
color: #cbdcf0 !important;
font-size: 14px;
line-height: 1.7;
margin: 0 0 17px !important;
}
.wfde-gl-downloads .wfde-gl-button {
display: inline-flex;
justify-content: center;
align-items: center;
width: 100%;
max-width: 470px;
min-height: 49px;
padding: 12px 20px;
border-radius: 9px;
background: linear-gradient(135deg,#1265dc,#078cec);
color: #fff !important;
font-size: 15px;
font-weight: 700;
line-height: 1.4;
text-align: center;
text-decoration: none !important;
}
.wfde-gl-downloads .wfde-gl-button:hover,
.wfde-gl-downloads .wfde-gl-button:focus-visible {
color: #fff !important;
filter: brightness(1.13);
text-decoration: none !important;
}
.wfde-gl-downloads .wfde-gl-button:focus-visible {
outline: 3px solid #83caff;
outline-offset: 3px;
}
.wfde-gl-downloads .wfde-gl-button::after {
content: “ ↗“;
margin-left: 9px;
font-size: 19px;
}
.wfde-gl-downloads .wfde-gl-footer {
display: flex;
gap: 12px;
align-items: flex-start;
margin-top: 20px;
padding: 17px 18px;
border-radius: 11px;
border: 1px solid rgba(125,185,255,.25);
background: rgba(63,139,217,.12);
}
.wfde-gl-downloads .wfde-gl-infoicon {
display: flex;
align-items: center;
justify-content: center;
flex: 0 0 25px;
width: 25px;
height: 25px;
border-radius: 50%;
background: #3287e7;
color: #fff;
font-size: 15px;
font-weight: 700;
}
.wfde-gl-downloads .wfde-gl-note {
color: #d4e4f8 !important;
font-size: 13px;
line-height: 1.75;
margin: 0 !important;
}
@media(max-width:720px) {
.wfde-gl-downloads {
padding: 20px 15px;
}
.wfde-gl-downloads .wfde-gl-grid {
grid-template-columns: 1fr;
}
.wfde-gl-downloads .wfde-gl-card {
padding: 18px;
}
.wfde-gl-downloads .wfde-gl-action {
padding: 18px 14px;
}
}
@media(prefers-reduced-motion:reduce) {
.wfde-gl-downloads .wfde-gl-card {
transition: none;
}
}
GITLAB SECURITY RELEASE | OKTOBER 2026
GitLab Sicherheitsupdates herunterladen
GitLab hat am 21. Oktober 2026 sieben korrigierte
Versionen für Community Edition und Enterprise
Edition veröffentlicht. Die Sicherheitsupdates
schließen unter anderem CVE-2026-110264 mit
CVSS 10,0. Wähle die passende Version für Deine
bestehende Installation.
GitLab 19.5
Aktuelle Versionsreihe für CE und EE.
Korrigierter Sicherheitsbuild:
19.5.1
GitLab 19.4
Sicherheitsaktualisierung für vorhandene
Installationen der Versionsreihe 19.4.
19.4.3
GitLab 19.3
Korrigierte Version für GitLab Community
Edition und Enterprise Edition.
19.3.6
GitLab 19.2
Sicherheitskorrektur für die ältere
Versionsreihe 19.2.
19.2.9
GitLab 19.1
Vom Hersteller bereitgestellter
Sicherheits-Backport.
19.1.9
GitLab 19.0
Korrigierter Build für Installationen
der Versionsreihe 19.0.
19.0.10
GitLab 18.11
Sicherheitskorrektur für die ältere
Hauptversionsreihe 18.
18.11.13
Offizielle GitLab-Sicherheitsupdates
Die Herstellerseite enthält die vollständigen
Sicherheitsinformationen, die korrigierten
Versionen und die Zugänge zu den offiziellen
Installations- und Paketquellen.
Wie erkennst Du mögliche Angriffsversuche auf GitLab?
CERT-EU empfiehlt ausdrücklich, betroffene GitLab-Server nicht nur zu aktualisieren, sondern auch auf mögliche Kompromittierungen zu untersuchen. GitLab hat dafür zwei Erkennungsregeln veröffentlicht, die Hinweise auf auffällige Vorgänge liefern können. Sie beziehen sich auf ungewöhnliche Abstürze nativer Verarbeitungsprozesse und auf gehäufte Fehler bei der Verarbeitung bestimmter Dokumentinhalte.
Administratoren sollten vor allem ungewöhnliche Serverfehler, auffällige Abstürze, unerwartete Prozesse und verdächtige Zugriffe untersuchen. Wichtig ist, die relevanten Protokolle möglichst früh zu sichern. Ein Sicherheitsupdate schließt zwar die Schwachstelle, beseitigt aber nicht automatisch alle Folgen eines möglicherweise schon erfolgreichen Angriffs.
Zum Stand vom 23. Oktober 2026 nennen die offiziellen GitLab- und CERT-EU-Veröffentlichungen keine bestätigte großflächige Angriffskampagne gegen CVE-2026-110264. Die Veröffentlichung von Erkennungsregeln ist deshalb nicht automatisch ein Nachweis für bereits erfolgte Angriffe. Aufgrund der technischen Schwere sollte eine mögliche Kompromittierung trotzdem sorgfältig ausgeschlossen werden.
Windows Server, Docker und GitLab Runner: Worauf musst Du achten?
GitLab wird typischerweise auf Linux-Servern oder in geeigneten Container- und Kubernetes-Umgebungen betrieben. Viele Entwickler greifen allerdings von Windows 11 auf diese Systeme zu oder verwenden GitLab Runner für automatisierte Build- und Testaufgaben. Deshalb ist es wichtig, zwischen dem eigentlichen GitLab-Server und den angeschlossenen Entwicklungsrechnern zu unterscheiden.
Ein Update des GitLab Runners unter Windows behebt die hier beschriebene Sicherheitslücke im GitLab-Server nicht. Entscheidend ist die Version der Serveranwendung selbst. Besteht der Verdacht, dass ein Server bereits kompromittiert wurde, sollte man trotzdem angeschlossene Systeme und Zugriffsberechtigungen überprüfen.
Wird GitLab in einer virtuellen Maschine betrieben, sollte vor dem Update eine geeignete Sicherung vorbereitet werden. Ein Snapshot allein ersetzt keine vollständige Anwendungssicherung. Außerdem lohnt sich ein Blick auf die Erreichbarkeit des Servers und auf die vorhandenen Netzwerkfreigaben.
Ob die gewünschte TCP-Verbindung von einem Windows-PC aus grundsätzlich erreichbar ist, kannst Du beispielsweise mit PowerShell überprüfen:
Test-NetConnection -ComputerName gitlab.example.com -Port 443Ersetze den Beispielnamen durch die tatsächliche Adresse Deiner GitLab-Installation. Ein erfolgreicher Verbindungstest bestätigt allerdings nur die TCP-Erreichbarkeit und nicht die Sicherheit oder Funktionsfähigkeit der Anwendung. Weitere Hinweise zur Untersuchung findest Du in unserer Anleitung Welches Programm belegt welchen Port?.
GitLab-Server zusätzlich absichern: Diese Maßnahmen sind sinnvoll
Gerade bei selbst gehosteten GitLab-Servern sollte die Verwaltungsoberfläche nicht unnötig öffentlich erreichbar sein. Wird der Zugriff nur innerhalb des Firmennetzes gebraucht, empfiehlt sich eine entsprechend eingeschränkte Netzwerkfreigabe. Müssen Verbindungen von außen möglich sein, können zusätzliche Zugriffsbeschränkungen und eine passende VPN-Absicherung sinnvoll sein.
Unsere Anleitung Portweiterleitung einrichten erklärt, warum öffentlich freigegebene Dienste regelmäßig überprüft werden sollten. Solche Netzwerkmaßnahmen können das Risiko reduzieren, ersetzen aber kein Sicherheitsupdate. Für CVE-2026-110264 nennt GitLab die Installation einer korrigierten Version als entscheidende Maßnahme.
Zusätzlich sollten Administratorenkonten durch Mehrfaktorauthentifizierung geschützt werden. Nach einem vermuteten Angriff empfiehlt sich außerdem die Überprüfung besonders sensibler Projektzugänge, CI/CD-Variablen und gespeicherter Zugangsdaten. Ob einzelne Geheimnisse tatsächlich offengelegt wurden, muss anhand der jeweiligen Untersuchung festgestellt werden.
Auf angeschlossenen Windows-Systemen können die Windows-Ereignisprotokolle zusätzliche Hinweise auf ungewöhnliche Vorgänge liefern. Wie sich diese Informationen mit PowerShell auswerten lassen, zeigt unser Beitrag Ereignisanzeige mit PowerShell auslesen. Diese Windows-Protokolle ersetzen allerdings nicht die GitLab- und Linux-Protokolle des eigentlichen Servers.
Aus der Administratorpraxis: GitLab-Sicherheitsupdates nicht unnötig verschieben
Die aktuelle Schwachstelle zeigt, wie wichtig regelmäßige Sicherheitsupdates auch außerhalb der Microsoft-Welt sind. Gerade Entwicklungssysteme werden manchmal als weniger kritisch eingestuft, weil dort keine klassischen Unternehmensanwendungen laufen. Tatsächlich können solche Plattformen jedoch besonders sensible Informationen und Zugänge zu anderen Systemen enthalten.
Bei einer größeren GitLab-Umgebung würde ich zuerst alle selbst betriebenen Instanzen erfassen und ihre Versionsstände prüfen. Danach sollten öffentlich erreichbare Systeme und Server mit besonders wichtigen Projekten als Erstes aktualisiert werden. Datensicherung, Upgradepfad und Funktionstests dürfen dabei nicht zu kurz kommen.
Auch angrenzende Entwicklungswerkzeuge benötigen regelmäßige Aktualisierungen. Das haben zuletzt die Node.js-Sicherheitsupdates vom 21. Oktober 2026 gezeigt. Verschiedene Produkte können zur gleichen Zeit von unterschiedlichen Sicherheitsproblemen betroffen sein, weshalb ein vollständiger Überblick über die eingesetzte Software besonders hilfreich ist.
FAQ: Häufige Fragen zur GitLab-Sicherheitslücke CVE-2026-110264
CVE-2026-110264 ist eine kritische Sicherheitslücke in GitLab Community Edition und Enterprise Edition. Ein Fehler beim Verarbeiten regulärer Ausdrücke kann unter bestimmten Voraussetzungen eine entfernte Codeausführung ohne vorherige Anmeldung ermöglichen. GitLab bewertet die Schwachstelle mit CVSS 3.1 10,0.
GitLab hat die korrigierten Versionen 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 und 18.11.13 veröffentlicht. Welche Version geeignet ist, hängt von der bestehenden Installation und dem vorgesehenen Upgradepfad ab.
GitLab.com verwendet nach Herstellerangaben bereits korrigierte Software. Für gewöhnliche Anwender der gehosteten GitLab-Plattform ist deshalb kein eigener Serverpatch erforderlich. Selbst betriebene GitLab-Installationen müssen dagegen überprüft und gegebenenfalls aktualisiert werden.
Zum Stand vom 23. Oktober 2026 enthalten die offiziellen Hersteller- und CERT-EU-Meldungen keine Bestätigung einer großflächigen aktiven Ausnutzung von CVE-2026-110264. GitLab stellt jedoch Erkennungsregeln für mögliche Angriffsversuche bereit. Betroffene Server sollten deshalb aktualisiert und untersucht werden.
Nein. Die Sicherheitslücke betrifft die GitLab-Serveranwendung und nicht unmittelbar Windows. Selbst betriebene GitLab-Installationen benötigen eine korrigierte GitLab-Version. Ein gewöhnliches Windows Update oder die Aktualisierung eines GitLab Runner allein behebt CVE-2026-110264 nicht.
Fazit: Kritische GitLab-Sicherheitslücke benötigt sofortige Aufmerksamkeit
Mit CVE-2026-110264 schließt GitLab eine besonders gefährliche Sicherheitslücke, die mit dem maximalen CVSS-3.1-Basiswert von 10,0 bewertet wird. Unter bestimmten Voraussetzungen könnten Angreifer ohne Anmeldung eigenen Programmcode auf verwundbaren GitLab-Servern ausführen. Besonders kritisch ist das für Firmen, die GitLab für vertrauliche Entwicklungsprojekte und automatisierte Bereitstellungsprozesse nutzen.
Der Hersteller hat bereits sieben korrigierte Versionen veröffentlicht. Selbst betriebene Installationen sollten deshalb möglichst bald aktualisiert werden. CERT-EU rät außerdem, öffentlich erreichbare Systeme auf mögliche Angriffsspuren zu untersuchen. Wer seine eingesetzten Versionen kennt, eine passende Datensicherung hat und den vorgeschriebenen Upgradepfad einhält, kann die Lücke kontrolliert und zuverlässig schließen.
Neueste Kommentare