CVE-2026-27607: RustFS Presigned POST Policy Bypass

CVE-2026-27607 is a high severity flaw (CVSS 8.1) in RustFS, the Rust based distributed object store. It does not enforce presigned POST policy conditions, so uploads can exceed size limits, land on other keys, or carry a spoofed content type. Upgrade to 1.0.0-alpha.83.

What's affected

RustFS 1.0.0-alpha.56 through 1.0.0-alpha.82. The fix is in 1.0.0-alpha.83, according to the record and the project's advisory.

The advisory says any application that uses RustFS as an S3 compatible backend and relies on presigned POST policy conditions for upload restrictions is in scope. If your uploads go through your own service and do not use presigned POST, the exposure is smaller.

How to check if you're exposed

Find your RustFS build, and find whether anything generates presigned POST forms.

rustfs --version

# container deployments
docker image ls | grep rustfs

Then search your application code for presigned POST generation, for example calls to the AWS SDK function that creates a presigned post with a conditions list. If conditions such as content-length-range or starts-with matter to your design, those are the rules the vulnerable versions do not enforce.

What to do now

1. Upgrade RustFS to 1.0.0-alpha.83 or later.
2. Treat objects uploaded through presigned POST on the affected builds as untrusted. Check sizes, key names and content types against what you intended.
3. Add limits at another layer too: bucket quotas, reverse proxy body size caps and monitoring on storage growth.
4. Validate uploads after the fact in your own service rather than trusting the policy alone.
5. Review whether any keys outside the intended prefixes were written.

Why it matters

The advisory classes this as improper input validation and an authorization bypass, CWE-20 and CWE-863. The policy document is signed by the application, and the signature is checked, but the conditions inside it are not parsed and compared with the actual request. A signed rule that nobody enforces gives a false sense of control.

The listed impacts are storage exhaustion, uploads to arbitrary object keys and content type spoofing. In a multi tenant system, writing to a key outside your prefix can reach another tenant's area.

The lesson for anyone building on S3 compatible stores is to test that the conditions you set are actually refused when violated. A policy that cannot fail is not a control.

Quick check

Sources

• GitHub advisory GHSA-w5fh-f8xh-5x3p

Last reviewed: 19 October 2026.