Impact statement: CVE-2026-42882 is a critical authorization problem in oxyno-zeta/s3-proxy, an S3-compatible object-storage proxy written in Go. Public or customer-facing deployments older than 5.0.0 can make different authorization and storage decisions for the same object path. For hosting providers, SaaS teams, and admins using s3-proxy in front of private buckets, the practical risk is unauthorized access to protected objects, unauthorized object changes, and possible customer data exposure.
This is a protect-only guide. We are not publishing traffic patterns, route examples, scanner-ready checks, lab notes, or internal WAF test cases. The safe answer is to update s3-proxy to 5.0.0 or newer, prefer the latest 5.1.0 release when possible, restrict public access while patching, review object-storage access logs, and rotate credentials if there is any sign of unauthorized object activity.
Who Is Affected
- s3-proxy deployments older than 5.0.0.
- Docker, Compose, Kubernetes, or systemd deployments that expose s3-proxy to customers, developers, vendors, or the public Internet.
- Hosting platforms that use s3-proxy for private downloads, customer media, backup access, artifact storage, or file delivery.
- CDN or reverse-proxy setups where s3-proxy is the layer deciding which bucket paths should be public and which should require authentication.
- Internal tools where support staff, automation, or customer portals can reach s3-proxy over a shared network.
The highest-risk lane is any s3-proxy service that fronts a private or mixed-sensitivity bucket and can be reached without a VPN or strict allowlist. A private-only lab service is lower risk, but still worth patching because object-storage tooling is often copied into production later.
Patch First
Before changing production, save the current s3-proxy configuration, confirm the bucket credentials in use, and decide whether customers need a short maintenance notice. If the proxy handles private customer files, treat the update like a storage access-control change instead of a routine container refresh.
Docker Or Compose
docker compose ps
docker compose pull s3-proxy
docker compose up -d s3-proxy
docker compose logs --tail=100 s3-proxy
If your Compose service has a different name, replace s3-proxy with the service name from your stack. Confirm the running image tag after the restart and make sure the service is now on 5.0.0 or newer.
Kubernetes
kubectl -n storage get deploy,po,svc | grep s3-proxy
kubectl -n storage set image deployment/s3-proxy s3-proxy=ghcr.io/oxyno-zeta/s3-proxy:5.1.0
kubectl -n storage rollout status deployment/s3-proxy
kubectl -n storage logs deployment/s3-proxy --tail=100
Use your real namespace, deployment name, and approved image registry. If the proxy serves customer downloads, roll through one replica at a time and verify object access through the same CDN or load balancer path customers use.
Linux Binary Or Systemd
s3-proxy --version 2>/dev/null || true
systemctl status s3-proxy --no-pager
systemctl restart s3-proxy
journalctl -u s3-proxy --since "24 hours ago" --no-pager | tail -200
Install the current upstream release package or your internally built fixed binary, then restart the service. Keep the old binary only long enough for rollback, and do not leave retired copies reachable through old service files or manual scripts.
Built From Source
git fetch --tags
git checkout v5.1.0
go test ./...
go build ./cmd/s3-proxy
If your team embeds s3-proxy code or maintains an internal fork, compare your fork against the upstream 5.0.0 security changes and the current 5.1.0 release. Rebuild, redeploy, and document any config changes required by the upstream path-matching behavior change.
Temporary Protection If You Cannot Patch Today
- Remove direct public access to s3-proxy and require VPN, SSO, mutual TLS, or a strict IP allowlist.
- Place private-object routes behind your CDN or reverse proxy with an explicit deny-by-default policy.
- Separate public-only buckets from private buckets instead of mixing both behind one proxy.
- Disable anonymous object write or delete flows until the fixed version is live.
- Rotate S3 access keys used by the proxy if logs suggest unusual object reads, writes, or deletes.
- Reduce cache lifetime for sensitive object responses while you verify the patch and log review.
Safe Review Checklist
Review the proxy like an authorization boundary. Look for unusual object access volume, unexpected private-object downloads, unfamiliar source networks, spikes in failed authorization decisions, unexpected object changes, and delete activity that does not match known customer or automation behavior.
docker compose logs --since=24h s3-proxy | tail -200
journalctl -u s3-proxy --since "24 hours ago" --no-pager | tail -200
aws s3api list-objects-v2 --bucket YOUR_BUCKET_NAME --max-items 20
Use the final command only with your own bucket name and normal admin credentials. For providers, also check CDN logs, reverse-proxy logs, S3 access logs, object lock or versioning history, and any customer-facing download audit trail.
Hosting Provider Checklist
- Inventory every s3-proxy container, binary, deployment, and old staging copy.
- Prioritize proxies that serve customer files, backups, private downloads, media libraries, or software artifacts.
- Update to 5.0.0 or newer, preferably 5.1.0 where compatible.
- Confirm that public and private bucket paths are separated by policy, not just naming convention.
- Review S3 credentials, bucket policies, CDN cache rules, and reverse-proxy access controls.
- Tell affected customers what was patched, whether their service was exposed, and whether credential or file-access follow-up is needed.
What To Tell Customers
Tell customers that a critical s3-proxy authorization flaw was disclosed and fixed upstream. The issue matters when s3-proxy sits in front of private or mixed-sensitivity object storage. Customers do not need attack details; they need to know whether the service was exposed, when it was patched, whether logs showed unauthorized object activity, and whether any keys or shared download links should be rotated.
Fix I.T. Phill CDN Virtual Patching Note
We are handing a sanitized signal to the CDN side so defensive rules can watch for ambiguous object-path handling against exposed s3-proxy services while customers patch. The rule request is intentionally high level: normalize consistently, deny ambiguous private-object routing, rate-limit suspicious object access, and avoid publishing internal test cases.
