Dockerfile pins haproxy:3.4.2-alpine (frozen 2026-07-06), so v0.5.0 and nightly ship 6 fixable HIGH CVEs — #178 again #190

This is #178's root cause again. #179 fixed that one by moving the base from one patch tag to another, FROM haproxy:3.4.2-alpine. Docker's official images don't rebuild old patch tags, so that base has been frozen since 2026-07-06. Every image published since, including v0.5.0/latest and the 2026-10-04 master/nightly rebuild, carries the same out-of-date Alpine packages. The weekly rebuild can't help, because the base it rebuilds from never changes.

Findings

Trivy, HIGH/CRITICAL with a fix available, on v0.5.0 (sha256:1f5038b5…):

Pinned vs current base

Reproduce:

$ for t in 3.4.2-alpine 3.4-alpine; do docker run --rm --entrypoint sh haproxy:$t -c \
    'haproxy -v | head -1; apk list -I | grep -E "^(libssl3|libcrypto3|pcre2)-" | cut -d" " -f1'; done
HAProxy version 3.4.2-9feeb3287 2026/07/03 - https://haproxy.org/
libcrypto3-3.5.7-r0
libssl3-3.5.7-r0
pcre2-10.47-r1
HAProxy version 3.4.6-56332c5 2026/09/28 - https://haproxy.org/
libcrypto3-3.5.8-r0
libssl3-3.5.8-r0
pcre2-10.48-r0

Suggested fix

1. Move the base to haproxy:3.4.6-alpine (or later) and cut a release. That clears 5 of the 6 above for anyone pinning a version tag.
2. To stop this recurring a third time, either:
   • build FROM haproxy:3.4-alpine, as Dockerfile pins haproxy:3.2.4-alpine (frozen Aug 2025), so every published image ships openssl 3.5.1-r0 / musl 1.2.5-r10 — 2 Critical + 19 High #178 suggested, so the existing weekly nightly rebuild actually picks up Alpine security updates; or
   • keep a patch pin but let Dependabot/Renovate bump the Dockerfile FROM.

One caution from #180: the 3.2 → 3.4 bump in v0.5.0 broke /version calls. A test that hits /version, /containers/json and /events through the proxy would make base bumps safe to take routinely.