Build1 publisherNot yet confirmed elsewhere2 min readPublished
Alluxio's S3 proxy accepted any user named in an unsigned header by default
Alluxio's S3 REST proxy skipped AWS signature checks by default, a flaw NVD scores 9.3 as CVE-2026-79787. An attacker needs only a network route to the port, so internal reachability decides which clusters are exposed until they upgrade.
The Engineer · Build desk
What happened
- An attacker can put a username into an unsigned Authorization header and act as that user, service accounts included, to read, write and delete arbitrary data.
- The faulty code path is S3RestUtils.java in Alluxio's core/server/proxy module, and the bug is tracked as Alluxio issue 18755.
- ZoomEye queries run on 2026-10-05 found 250 assets with Alluxio in the page title and none by application fingerprint.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- exposure Scheduled jobs and query engines that read from proxy-writable paths can be fed attacker-written files, so storage access becomes code execution and corrupted downstream tables.
- cost Deleted objects come back only from backups, so recovery time after an intrusion depends on backup coverage for every bucket the proxy fronts.
- constraint User names logged during the vulnerable period are whatever the attacker typed, so attribution of past reads and deletes cannot rest on the proxy's own logs.
S3 has no login step [7]. A client signs each request with its secret key, and the server recomputes the signature from the secret it holds for the access key the client claims [7]. A match is the authentication. There is no session, cookie or token behind it [7].
According to a write-up on dev.to, Alluxio's proxy handler parsed the Authorization header for the access key, resolved a user, and carried on without completing the signature comparison [8]. Every request was then authenticated as whoever the header named [8]. The header is attacker-controlled text, so nothing else in the request has to be forged [8].
In my view the default is the larger defect. The write-up says a stronger mode exists in the code, but installations that never changed the relevant option are exposed [9]. A proxy that verifies signatures only when an option is enabled is not verifying them in the state most clusters run in, the write-up argues [9].
The point of the proxy is to let applications built for Amazon S3 work with an Alluxio cluster unchanged [3]. Those applications sign every request already [7]. A handler that skips the comparison accepts a correctly signed request just as it accepts an unsigned one. A healthy pipeline shows no symptom, and integration tests with real credentials pass against the vulnerable build [22].
The write-up's remediation, in the order I would run it:
1. Keep the proxy off the open internet. On a reachable port the attacker needs nothing else [13]. 2. Put an authenticating gateway in front of it while the upgrade is scheduled. Even a coarse credential check removes the anonymous case the flaw depends on [14]. 3. Upgrade to the release containing the fix, and confirm the version actually running instead of the one in a chart's default values [12]. 4. Send a deliberately unsigned request to a test instance and confirm it is rejected [16]. 5. Search object storage logs for access keys that do not match the pattern your applications use [15].
Step 4 is the one I would not skip, for the reason above. The write-up links the handler source at v2.9.5 but does not name the release that carries the fix [2].
The internet scan figures say little about risk [18]. A zero from the fingerprint query means ZoomEye has no application fingerprint for Alluxio [19]. The title query also matches the Maven artifact and the documentation site, which are indexed alongside running clusters [20]. Neither count reports a version or whether the S3 proxy is enabled [18].
What to watch
- Whether the fixed release turns signature verification on by default or still leaves the stronger mode behind an option.
- An affected-version range from NVD or Alluxio, so operators pinned to older charts can tell whether they are in scope.
- A public proof of concept against internally reachable proxies; the attack needs no forged credentials, so one would be short.
Clarity's read
What the record supports and how the coverage leans. The claims behind it follow.
Reality
- Evidence55
- Adoption
- Insufficient
- Hype gap+10
- Incentives
- Insufficient
- Confidence50
Claim ledger
Ranked by verification strength, evidence, and original report placement.
- [1]
The referenced code path is S3RestUtils.java in the core/server/proxy module, and the tracking issue is Alluxio issue 18755.
ReportedSupportedSource: dev.to write-up2 sources— create a free account to open themView cited source - [2]
The write-up's code reference points to S3RestUtils.java in core/server/proxy at v2.9.5, and its remediation advice says to upgrade to the release containing the fix without giving a version number.
ReportedSupportedSource: dev.to write-up references list2 sources— create a free account to open themView cited source - [3]
Alluxio's S3 REST proxy exists so applications written for Amazon S3 can talk to an Alluxio cluster without modification.
- [4]
Before the fix for CVE-2026-79787, the Alluxio S3 REST proxy did not verify AWS Signature Version 4 signatures in its default configuration, allowing unauthenticated attackers to spoof user identity.
- [5]
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.
- [6]
NVD lists a base score of 9.3 for CVE-2026-79787.
- [7]
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 it matches, the request is authenticated. There is no session, cookie or token.
- [8]
If the handler parses the Authorization header for the access key, resolves a user, and proceeds without completing the signature comparison, every request is authenticated as whoever the header names; nothing else has to be forged because the header is attacker-controlled text.
- [9]
A proxy that verifies signatures only when a particular option is enabled is not verifying them in the state most clusters run in; installations that never changed that option are exposed even though a stronger mode exists in the code.
- [10]
Overwriting a table's underlying files corrupts the data a downstream query engine will read, and writing to a path that a scheduled job consumes turns storage access into code execution.
- [11]
The proxy's log records the identity from the header, so an investigation after the fact starts with the wrong name.
- [12]
Upgrade to the release that contains the fix, and confirm the running version rather than the version in a chart's default values.
- [13]
Do not publish the S3 proxy to the open internet; on a reachable port the attacker needs nothing else.
- [14]
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 the flaw depends on.
- [15]
Check object storage logs for requests whose access key does not match the pattern your applications use.
- [16]
Verify the fix by sending a deliberately unsigned request to a test instance and confirming it is rejected.
- [17]
Two ZoomEye queries on 2026-10-05: title="Alluxio" returned 250 assets and app="Alluxio" returned zero.
- [18]
Neither ZoomEye count reports a version or whether an S3 proxy is enabled; the real exposure question is the internal accessibility of the proxy, which no external scan answers.
- [19]
The zero result for app="Alluxio" means ZoomEye has no application fingerprint that matches this product.
- [20]
The Maven artifact and the documentation site are indexed, so the same search terms also return results unrelated to running clusters.
- [21]
Deleting data has a recovery cost measured in backups and time.
- [22]
Because the handler skips the comparison, it accepts correctly signed requests as well as unsigned ones, so S3 applications and integration tests using real credentials would show no failure against the vulnerable build; only an unsigned request distinguishes it.
Sources
1 independent publisher whose own reporting we read for this story.
- dev.toAlluxio's S3 proxy skipped signature verification, and everyone was root
1 article · October 8, 2026
Topics and entities
Follow any of these and your For You feed starts watching them — no settings page required.
Topics
- Authentication Bypass FlawsFollow
- Object storage securityFollow
- Data OrchestrationFollow
Entities
- AlluxioFollow
- CVE-2026-79787Follow
- AWS Signature Version 4Follow
- Amazon Simple Storage ServiceFollow
- National Vulnerability DatabaseFollow
- ZoomEyeFollow