You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[redis-ha] HAProxy image 3.3.10-alpine carries 3 critical CVEs; no bot tracks the image tags #423
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.
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:
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:
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.
Activity
JanWelker commentedon Sep 18, 2026
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-cddeclaresredis-haas a dependency, but the published release tarball vendors the subchart rather than resolving it at install time: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'sredis-ha.enabledpath entirely.Workaround for Argo CD users
The tag is a plain values field, so it can be overridden through the parent chart's
redis-hakey without forking anything:Verified against
argo-cd-10.9.2.tgz:I diffed the vendored 4.38.0
values.yamlagainst the fixed chart to confirm the override is sufficient and not papering over other drift — the HAProxy tag is the entire functional delta: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.