CVE-2026-42882: Critical s3-proxy Authentication Bypass

Are You Affected?

The vulnerable behavior exists in versions prior to 5.0.0. The available NVD information does not identify other products, vendors, or downstream distributions as affected.

The vulnerable deployment pattern is a proxy that applies resource-path restrictions before constructing S3 object keys. An unauthenticated remote attacker can send specially formed paths that the authorization middleware and bucket handler interpret differently.

Exposure is especially significant where the proxy is internet-facing or where protected buckets contain sensitive, mutable, or operationally important data.

To determine whether you are affected:

1. Identify every deployed s3-proxy binary, container image, package, and source checkout.
2. Confirm the embedded project version.
3. Check whether each deployment is running before or after version 5.0.0.
4. Include custom-built binaries and pinned container images in the inventory.
5. Review path-based authorization rules and exposed S3 namespaces.

Organizations reviewing access boundaries should also understand what least privilege means in IAM, particularly where proxy identities can access multiple buckets or prefixes.

The Fix, If You’re in a Hurry

Upgrade oxyno-zeta/s3-proxy to version 5.0.0 or later. The available vulnerability record identifies 5.0.0 as the fixed version.

After upgrading:

• Restart or redeploy every proxy instance.
• Confirm traffic is reaching the new binary rather than an old replica or sidecar.
• Refresh container image digests.
• Verify the running version on every instance.
• Test authorization against encoded slashes, traversal sequences, and protected prefixes.
• Record the deployed version as part of the change.

For a source checkout, a representative upgrade and verification sequence is:

git fetch --tags --force
git checkout v5.0.0
go build -o s3-proxy .
./s3-proxy --version

The exact build and startup options depend on your deployment process. If you use a container image, update the image reference to one built from 5.0.0 or later, refresh the image digest, and roll the deployment.

If an immediate upgrade is impossible, reduce exposure rather than treating a gateway rule as a complete fix. Restrict the proxy to trusted networks, require upstream authentication, limit access to sensitive buckets, and block suspicious requests containing encoded slashes or traversal sequences where operationally safe.

These are compensating controls, not a vulnerability fix. They may fail if another intermediary decodes or normalizes the request differently, and they can disrupt legitimate object names.

Analyst’s Take: Put version inventory and the 5.0.0 upgrade first. The bypass reaches protected S3 namespaces without authentication, while gateway rules can behave differently from the application and may disrupt legitimate object names.

Temporary Reverse-Proxy Controls

A temporary reverse-proxy rule should be tested carefully before enforcement. For example, an NGINX deployment might log and reject obvious traversal indicators:

map $request_uri $s3_proxy_suspicious_path {
    default 0;
    ~*"%2f" 1;
    ~*"%2F" 1;
    ~*"\.\." 1;
}

server {
    if ($s3_proxy_suspicious_path) {
        return 403;
    }

    proxy_pass http://s3-proxy_backend;
}

This example is not a substitute for upgrading. URL normalization differs between components, and rejecting encoded slashes may affect legitimate object keys. Deploy such a rule in monitoring or staged mode first, then validate it against known application traffic.

How This Vulnerability Works

The flaw is an authorization and resource-resolution mismatch. The authentication middleware evaluates configured resource-path patterns against r.URL.RequestURI(), which preserves the percent-encoded request representation. The bucket handler, however, constructs S3 object keys from Go’s decoded r.URL.Path.

The authorization layer and storage layer can therefore process the same request as different paths. A sequence such as %2F may remain an encoded token during authorization but become / when the handler builds the S3 key.

The request can satisfy an allow rule for one apparent path while reaching a different, protected namespace during object processing.

A second contributing issue is glob semantics. The matching library permits * to match across path separators. Rules intended to constrain one path segment can consequently match a broader path than administrators expect. A path such as the following illustrates the relevant class of input:

/open/foo/drafts/../restricted/

Depending on the configured pattern and processing stage, the raw path may match an open route while later normalization changes the effective S3 key. Similar behavior can occur with ** patterns and dot-dot traversal.

The security boundary fails because authorization is not performed against the same canonical representation used to identify the S3 object. In a path-authorized proxy, canonicalization, matching, and backend key construction must agree on:

• Path separators
• Encoded characters
• Traversal elements
• Repeated separators
• Dot segments
• Normalization rules

Conceptual Processing Model

The affected processing model can be represented conceptually as:

// Authorization layer: encoded request representation.
authorized := matchesConfiguredRule(r.URL.RequestURI())

// Backend layer: decoded path representation.
objectKey := r.URL.Path
s3.GetObject(bucket, objectKey)

The exact upstream implementation should be reviewed in the fixed release and remediation commits. Defenders should not assume that a front-end normalization rule reproduces the application’s behavior.

After upgrading, test:

• %2F
• %252F
• ../
• Encoded dot segments
• Repeated separators
• Paths containing mixed encoded and decoded characters

Severity, Explained

The reported CVSS score is 9.4, Critical. The supplied NVD material does not include the vector string, so the individual CVSS components should not be reconstructed or presented as authoritative. Before publishing a formal score breakdown, retrieve the current vector directly from the NVD record.

The practical severity is nevertheless clear. The issue is remotely reachable, requires no authentication according to the vulnerability description, and can cross a configured authorization boundary.

Successful exploitation may permit:

• Reading protected objects
• Writing attacker-controlled content
• Deleting objects
• Exposing customer or configuration data
• Tampering with CI/CD artifacts or backups
• Placing malicious content where downstream systems trust stored objects

Organizations should not downgrade risk solely because the proxy sits behind another service. A reverse proxy, WAF, or identity-aware gateway may reduce exposure, but the vulnerable authorization path remains reachable wherever requests can reach the affected application.

Risk is highest for:

• Internet-facing instances
• Administrative object stores
• CI/CD artifacts
• Backups
• Configuration data
• Buckets containing credentials
• Customer information
• Objects consumed by automated systems

Is It Being Exploited?

CVE-2026-42882 was not found in the CISA Known Exploited Vulnerabilities catalog in the checked data. Consequently, there is no CISA dateAdded, due date, required action, or ransomware-campaign designation available for this CVE.

KEV absence does not prove that exploitation has not happened. It means CISA has not included the vulnerability based on the checked catalog data.

The supplied NVD and upstream references describe practical exploitation techniques, including:

• Glob matching across path separators
• Encoded-slash handling
• Dot-dot traversal
• Differences between raw and decoded URL paths

Those details establish high technical exploitability, but they do not by themselves prove a public weaponized exploit or active campaign.

Assessment: Confirmed in-the-wild exploitation was not established from the supplied NVD, CISA KEV, and upstream references. The supplied material also does not establish a standalone public proof of concept.

Treat the issue as high priority regardless of current exploitation evidence. An unauthenticated authorization bypass affecting object reads, writes, and deletes can become attractive quickly once deployment details and path rules are understood.