Alluxio's S3 proxy skipped signature verification, and everyone was root

Alluxio sits between compute frameworks and storage, and its S3 REST proxy exists so applications written for Amazon S3 can talk to an Alluxio cluster without modification. That compatibility promise depends on the proxy checking the signature the client sends. Before the fix for CVE-2026-79787, it did not check it in the default configuration.

What the advisory says

The S3 REST proxy fails to verify AWS Signature Version 4 signatures in its default configuration, which allows unauthenticated attackers to spoof user identity. An attacker can extract a username from an unsigned Authorization header and impersonate that user, including service accounts, to read, write and delete arbitrary data. NVD lists a base score of 9.3. The referenced code path is S3RestUtils.java in the core/server/proxy module, and the tracking issue is Alluxio issue 18755.

Why signature verification is the whole authentication model

The S3 protocol has no login step. A client signs each request with a secret key, and the server recomputes the signature from the secret it holds for the claimed access key. If the recomputed value matches, the request is authenticated. There is no session, no cookie and no token to inspect.
That design puts the entire burden on one comparison. If the handler parses the Authorization header for the access key, resolves a user, and then proceeds without completing the signature comparison, every request is authenticated as whoever the header names. Nothing else in the request has to be forged, because the header is attacker-controlled text.
The default-configuration detail matters for remediation. A proxy that verifies signatures only when a particular option is enabled is not verifying them in the state most clusters run in, and installations that never changed that option are exposed even though a stronger mode exists in the code.

What an attacker gains

Reading and writing arbitrary data through the object interface is enough to take over most data platforms. Overwriting a table's underlying files corrupts the data a downstream query engine will read. Writing to a path that a scheduled job consumes turns storage access into code execution. Deleting data has a recovery cost measured in backups and time.
Impersonating named users and service accounts changes attribution as well. The proxy's log records the identity from the header, so an investigation after the fact starts with the wrong name.

Defensive implications

Upgrade to the release that contains the fix, and confirm the running version rather than the version in a chart's default values.
Do not publish the S3 proxy to the open internet. Authentication failure in a default configuration is bad; authentication failure on a reachable port is worse, because the attacker needs nothing else.
Place an authenticating gateway in front of the proxy while the upgrade is scheduled. A reverse proxy that validates credentials, even a coarse one, removes the anonymous case that this flaw depends on.
Check object storage logs for requests whose access key does not match the pattern your applications use. The proxy records the identity it was given, and unusual access keys are a useful signal.
Verify that the fix behaves as documented by sending a deliberately unsigned request to a test instance and confirming it is rejected. A configuration that was wrong once is worth testing rather than assuming.

What the public surface looks like

Two ZoomEye queries on 2026-10-05 measured the product surface. title="Alluxio" returned 250 assets and app="Alluxio" returned zero. The zero is a real result rather than a failure. It means ZoomEye has no application fingerprint that matches this product, so a query on the fingerprint field finds nothing. The title count records installations whose web interface exposes the name.
The Maven artifact and the documentation site are indexed on the website side, which is why the same search terms also return results unrelated to running clusters. Neither count reports a version, and neither says whether an S3 proxy is enabled, so the useful conclusion is narrow: a small number of Alluxio interfaces are publicly visible, and the real exposure question is the internal accessibility of the proxy, which no external scan answers.

References

• NVD record for CVE-2026-79787, retrieved 2026-10-05
• Alluxio S3RestUtils.java in core/server/proxy at v2.9.5
• Alluxio issue 18755
• ZoomEye queries title="Alluxio" and app="Alluxio", sub_type=all, executed 2026-10-05