Update eniz1806/vaults3 Docker tag to v4.4.66 #367

2026-08-27T10:02:32+02:00

renovate-bot commented

2026-08-27 10:02:32 +02:00

This PR contains the following updates:

Package	Update	Change
eniz1806/vaults3	patch	`4.4.64` → `4.4.66`

Release Notes

Kodiqa-Solutions/VaultS3 (eniz1806/vaults3)

`v4.4.66`

Compare Source

Fixed

An unauthenticated request could panic the S3 handler. A bucket with no CORS
configuration makes the metadata store return (nil, nil), which is how it
reports "not configured" rather than an error. Three call sites ranged straight
over cfg.Rules and dereferenced that nil.

The worst of them, addCORSHeaders, runs before authentication, so any
anonymous request carrying an Origin header and any bucket-shaped path was
enough. The panic recovery middleware caught it, so the server never fell over,
but every such request cost a recovered panic and a stack trace in the log.

Found on the production instance, where internet scanners probing
/wp-json/wp/v2/users triggered it three times in a single day. The other two
paths, the CORS preflight handler and GET /{bucket}?cors, panicked on the
same nil for buckets that had simply never been given a CORS policy. All three
are guarded now, GET /{bucket}?cors correctly answers
NoSuchCORSConfiguration, and the store documents the nil contract so the next
caller does not repeat it.

`v4.4.65`

Compare Source

Security

Bumped klauspost/compress from 1.18.2 to 1.18.7, closing an out-of-bounds
read in its s2 decompressor (GO-2026-5841, reported by Docker Scout as
GHSA-259r-337f-4rfw). VaultS3 uses this module for zstd compression and never
calls the affected s2 code, so no released version was exploitable through
it, and govulncheck reported zero reachable vulnerabilities before and after.
The bump removes it from image scans regardless, since an unfixable finding in
a scan report is noise that hides the next real one.

Two findings remain in the image scan, both by design. GO-2026-5932 flags
golang.org/x/crypto/openpgp as unmaintained: it has no fixed version, and
VaultS3 does not import it. CVE-2025-60876 is in the base image's busybox
wget, which the image no longer uses for anything: the container health check
runs vaults3 healthcheck instead, so no shell or HTTP client is invoked.

Changed

Rate limiting is now on by default, at a ceiling far above real client
traffic: 2000 requests per second per IP and per access key, with a 4000
burst. An unauthenticated request is rate limited before it is
authenticated, so on a server reachable from the internet the limiter is the
only thing bounding what a flood costs. Scanners find a newly exposed
endpoint within seconds of it going up.

The ceiling was chosen by measurement rather than by feel. A saturating
8-thread boto3 client runs at roughly 1300 requests per second, comfortably
inside the limit, while a 64-thread flood attempting 4455 requests per second
is cut off. The previously shipped numbers, 100 per IP and 50 per key, would
have throttled that same legitimate client to 48 requests per second, a 24x
reduction, which is why they were never safe to enable by default.

This matters most behind a proxy: the per-IP bucket keys on the connection's
real address, not the forgeable X-Forwarded-For, so every client behind an
nginx or Kubernetes ingress shares one bucket. A low ceiling would have
throttled an entire deployment at once. Helm and the Kubernetes manifests,
which already enabled rate limiting at 200 per second, move to the same
numbers.

Set rate_limit.enabled: false to turn it off. An explicit false in a
config file still wins over the new default, and is covered by a test.

Fixed

The S3 conformance workflow could not build the server. It ran a bare
go build, but the binary embeds the dashboard from internal/dashboard/dist,
which only exists after the web build, so a clean checkout failed with
pattern all:dist: no matching files found. It passed locally only because a
previous build had left that directory behind.

It now writes a stub there instead of building the real frontend: this job
drives the S3 API and never opens the dashboard, so building React would add
minutes per run to embed assets nothing requests. ci.yml still builds and
tests the dashboard properly. The failure-log step is guarded too, so a build
failure no longer produces a second, misleading error about a missing log.

Configuration

📅 Schedule: (UTC)

Branch creation
- At any time (no schedule defined)
Automerge
- At any time (no schedule defined)

🚦 Automerge: Enabled.

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

If you want to rebase/retry this PR, check this box

This PR has been generated by Mend Renovate CLI.

This PR contains the following updates: | Package | Update | Change | |---|---|---| | [eniz1806/vaults3](https://github.com/Kodiqa-Solutions/VaultS3) | patch | `4.4.64` → `4.4.66` | --- ### Release Notes <details> <summary>Kodiqa-Solutions/VaultS3 (eniz1806/vaults3)</summary> ### [`v4.4.66`](https://github.com/Kodiqa-Solutions/VaultS3/blob/HEAD/CHANGELOG.md#4466---2026-08-26) [Compare Source](https://github.com/Kodiqa-Solutions/VaultS3/compare/v4.4.65...v4.4.66) ##### Fixed - **An unauthenticated request could panic the S3 handler.** A bucket with no CORS configuration makes the metadata store return `(nil, nil)`, which is how it reports "not configured" rather than an error. Three call sites ranged straight over `cfg.Rules` and dereferenced that nil. The worst of them, `addCORSHeaders`, runs *before* authentication, so any anonymous request carrying an `Origin` header and any bucket-shaped path was enough. The panic recovery middleware caught it, so the server never fell over, but every such request cost a recovered panic and a stack trace in the log. Found on the production instance, where internet scanners probing `/wp-json/wp/v2/users` triggered it three times in a single day. The other two paths, the CORS preflight handler and `GET /{bucket}?cors`, panicked on the same nil for buckets that had simply never been given a CORS policy. All three are guarded now, `GET /{bucket}?cors` correctly answers `NoSuchCORSConfiguration`, and the store documents the nil contract so the next caller does not repeat it. ### [`v4.4.65`](https://github.com/Kodiqa-Solutions/VaultS3/blob/HEAD/CHANGELOG.md#4465---2026-08-26) [Compare Source](https://github.com/Kodiqa-Solutions/VaultS3/compare/v4.4.64...v4.4.65) ##### Security - **Bumped `klauspost/compress` from 1.18.2 to 1.18.7**, closing an out-of-bounds read in its `s2` decompressor (GO-2026-5841, reported by Docker Scout as GHSA-259r-337f-4rfw). VaultS3 uses this module for zstd compression and never calls the affected `s2` code, so no released version was exploitable through it, and `govulncheck` reported zero reachable vulnerabilities before and after. The bump removes it from image scans regardless, since an unfixable finding in a scan report is noise that hides the next real one. Two findings remain in the image scan, both by design. `GO-2026-5932` flags `golang.org/x/crypto/openpgp` as unmaintained: it has no fixed version, and VaultS3 does not import it. `CVE-2025-60876` is in the base image's busybox `wget`, which the image no longer uses for anything: the container health check runs `vaults3 healthcheck` instead, so no shell or HTTP client is invoked. ##### Changed - **Rate limiting is now on by default**, at a ceiling far above real client traffic: 2000 requests per second per IP and per access key, with a 4000 burst. An unauthenticated request is rate limited *before* it is authenticated, so on a server reachable from the internet the limiter is the only thing bounding what a flood costs. Scanners find a newly exposed endpoint within seconds of it going up. The ceiling was chosen by measurement rather than by feel. A saturating 8-thread `boto3` client runs at roughly 1300 requests per second, comfortably inside the limit, while a 64-thread flood attempting 4455 requests per second is cut off. The previously shipped numbers, 100 per IP and 50 per key, would have throttled that same legitimate client to 48 requests per second, a 24x reduction, which is why they were never safe to enable by default. This matters most behind a proxy: the per-IP bucket keys on the connection's real address, not the forgeable `X-Forwarded-For`, so every client behind an nginx or Kubernetes ingress shares one bucket. A low ceiling would have throttled an entire deployment at once. Helm and the Kubernetes manifests, which already enabled rate limiting at 200 per second, move to the same numbers. Set `rate_limit.enabled: false` to turn it off. An explicit `false` in a config file still wins over the new default, and is covered by a test. ##### Fixed - **The S3 conformance workflow could not build the server.** It ran a bare `go build`, but the binary embeds the dashboard from `internal/dashboard/dist`, which only exists after the web build, so a clean checkout failed with `pattern all:dist: no matching files found`. It passed locally only because a previous build had left that directory behind. It now writes a stub there instead of building the real frontend: this job drives the S3 API and never opens the dashboard, so building React would add minutes per run to embed assets nothing requests. `ci.yml` still builds and tests the dashboard properly. The failure-log step is guarded too, so a build failure no longer produces a second, misleading error about a missing log. </details> --- ### Configuration 📅 **Schedule**: (UTC) - Branch creation - At any time (no schedule defined) - Automerge - At any time (no schedule defined) 🚦 **Automerge**: Enabled. ♻ **Rebasing**: Whenever PR is behind base branch, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this PR and you won't be reminded about this update again. --- - [ ] If you want to rebase/retry this PR, check this box --- This PR has been generated by [Mend Renovate CLI](https://github.com/renovatebot/renovate).

renovate-bot added 1 commit 2026-08-27 10:02:33 +02:00

Update eniz1806/vaults3 Docker tag to v4.4.66 85a66f8b2e

renovate-bot scheduled this pull request to auto merge when all checks succeed 2026-08-27 10:02:33 +02:00

renovate-bot merged commit d961b1dc45 into main

2026-08-27 10:02:35 +02:00

renovate-bot deleted branch renovate/eniz1806-vaults3-4.x

2026-08-27 10:02:35 +02:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: arnoutvw/compose-files#367