Kritische GitLab-Schwachstelle hätte öffentliche Projekte löschbar gemacht

GitLab hat außerplanmäßig eine kritische Lücke geschlossen, über die sich öffentliche Projekte ohne Anmeldung löschen ließen.

Die als CVE-2026-19478 geführte Schwachstelle stuft GitLab als kritisch ein und bewertet sie mit einem CVSS-Wert von 9,4. Der am 17. August veröffentlichte Patch erschien außerhalb des sonst üblichen, zweimal monatlich stattfindenden Update-Rhythmus, nur fünf Tage nach einem regulären Update ohne kritische Fehlerbehebungen. Nach Angaben von GitLab beruht die Schwachstelle auf einem Fehler bei der Verarbeitung einer bestimmten GraphQL-Direktive, welche konkrete Direktive betroffen ist und welche genauen Voraussetzungen für eine Ausnutzung nötig sind, teilte das Unternehmen bislang nicht mit. Der veröffentlichte CVSS-Vektor zeigt jedoch, dass sich die Lücke über das Netzwerk ohne jegliche Zugangsdaten und ohne Interaktion eines Opfers ausnutzen ließe.

Betroffen sind sämtliche Versionen von 18.2 bis vor 18.11.11 sowie 19.0 vor 19.0.8, 19.1 vor 19.1.6 und 19.2 vor 19.2.4. Da die eigentliche Korrektur die Versionsreihen 18.2 bis 18.10 nicht mehr rückwirkend abdeckt, sollten Nutzer dieser älteren Versionen laut GitLab ebenfalls auf eine der reparierten Versionen aktualisieren. Ausschließlich selbst betriebene GitLab-Installationen müssen aktiv handeln, da GitLab.com sowie GitLab Dedicated die reparierte Version nach Unternehmensangaben bereits einsetzen.

Zweite, weniger kritische Lücke ebenfalls behoben

Zusätzlich schließt das Update eine als CVE-2026-19650 geführte, von GitLab als hoch eingestuft und mit einem CVSS-Wert von 7,1 bewertete Cross-Site-Request-Forgery-Schwachstelle in der Verarbeitung sogenannter GraphQL-Multiplex-Anfragen. Anders als bei der kritischen Lücke ist für deren Ausnutzung eine Interaktion des Opfers erforderlich. Laut GitLab hätte die fehlerhafte Anfragevalidierung nicht authentifizierten Angreifern erlaubt, Datenänderungen über einfache GET-Anfragen auszulösen. Nach Angaben von GitLab bringt das Update keine neuen Datenbankmigrationen mit sich und erfordert bei Installationen mit mehreren Knoten voraussichtlich keine Ausfallzeit.

Bislang keine Hinweise auf Ausnutzung

Beide Schwachstellen wurden bislang nach Angaben von GitLab nicht aktiv ausgenutzt, öffentlich verfügbarer Exploit-Code lag zum Zeitpunkt der Berichterstattung ebenfalls nicht vor. Die Offenlegung erfolgt einen Monat, nachdem Sicherheitsforscher bereits funktionierenden Exploit-Code für eine andere, selbst betriebene GitLab-Server betreffende Schwachstelle veröffentlicht hatten. GitLab reagierte zunächst nicht auf eine Anfrage zu weiteren Details. Nach eigener Praxis veröffentlicht das Unternehmen technische Einzelheiten zu Schwachstellen üblicherweise 90 Tage nach dem jeweiligen Patch im eigenen Issue-Tracker, wodurch weitere Details zu beiden aktuellen Lücken voraussichtlich Mitte November 2026 öffentlich einsehbar werden.

(red)