[redis-ha] HAProxy image 3.3.10-alpine carries 3 critical CVEs; no bot tracks the image tags

[JanWelker]

Describe the bug

charts/redis-ha/values.yaml pins haproxy.image.tag: 3.3.10-alpine (set in #405, 2026-06-14). That image carries three critical CVEs:

Package	In 3.3.10-alpine	Fixed in	CVE
libcrypto3 / libssl3	3.5.7-r0	3.5.8-r0	CVE-2026-63073, CVE-2026-75803
socat	1.8.1.1-r0	1.8.1.2-r0	CVE-2026-56123

haproxy:3.3.14-alpine was rebuilt 2026-09-18 on Alpine 3.24, whose APKINDEX carries libcrypto3/libssl3 3.5.8-r0 and socat 1.8.1.3-r0 — so it clears all three.

The underlying cause

This is the third time an image pin here has gone stale into a CVE report (#392 for 3.0.8-alpine, then #405's bump, now this). No Renovate or Dependabot configuration exists in this repository — I checked renovate.json, renovate.json5, .renovaterc*, .github/renovate.* and .github/dependabot.*; none are present, and no PR in the repo's history was authored by a bot. Every image tag in values.yaml — haproxy, redis, busybox, shellcheck, redis_exporter — is hand-maintained, so they drift until someone files a report like this one.

Renovate's built-in helm-values manager would pick up haproxy and redis automatically, since both have sibling repository/tag keys. exporter.tag (line 753) has no sibling repository and would need an annotation comment.

Happy to send a config PR if you'd want one — though it needs the Renovate GitHub App installed on the repo, which only you can do. Your call entirely.

Minor

README.md line 262 still documents haproxy.image.tag as 3.0.8-alpine — helm-docs wasn't re-run after #405. The linked PR fixes that row in passing.

Prepared with the help of Claude Code; package versions verified against the Alpine v3.24 APKINDEX and the chart on master, and reviewed before filing.

[JanWelker]

Worth recording the blast radius here, because it is larger than this repo: this pin ships inside the Argo CD chart, and Argo CD users cannot patch it from their own values without knowing the trick below.

argo-cd declares redis-ha as a dependency, but the published release tarball vendors the subchart rather than resolving it at install time:

$ tar tzf argo-cd-10.9.2.tgz | grep charts/redis-ha/Chart.yaml
argo-cd/charts/redis-ha/Chart.yaml

$ tar xzf argo-cd-10.9.2.tgz -O argo-cd/charts/redis-ha/Chart.yaml | grep ^version
version: 4.38.0

So Argo CD 10.9.2 carries redis-ha 4.38.0, haproxy.image.tag: 3.3.10-alpine, and the affected HAProxy is what every Argo CD HA install actually runs. Nothing reaches out to this repo's Helm index at render time, which means the usual escape hatches do not apply — there is no repository to redirect, and forking this chart does not help unless you also stop using the Argo CD chart's redis-ha.enabled path entirely.

Workaround for Argo CD users

The tag is a plain values field, so it can be overridden through the parent chart's redis-ha key without forking anything:

redis-ha:
  haproxy:
    image:
      tag: 3.3.14-alpine

Verified against argo-cd-10.9.2.tgz:

$ helm template argocd argo-cd-10.9.2.tgz -f values.yaml | grep haproxy
image: ecr-public.aws.com/docker/library/haproxy:3.3.14-alpine

I diffed the vendored 4.38.0 values.yaml against the fixed chart to confirm the override is sufficient and not papering over other drift — the HAProxy tag is the entire functional delta:

140c140
<     tag: 3.3.10-alpine
---
>     tag: 3.3.14-alpine

This is a stopgap, not a fix: it leaves every Argo CD user who has not read this thread on the vulnerable image. The real fix is #424 landing and Argo CD picking up the new chart version.