Fixable CVEs in tecnativa/docker-socket-proxy (0 critical, 6 high) #1005

Activity

1. github-actions

   added

   securityA credential, an exposure, or a control that is weaker than recordedA credential, an exposure, or a control that is weaker than recorded

   observabilitystacks/observability on prometheusstacks/observability on prometheus

   labstacks/lab on alexander (VLAN 30)stacks/lab on alexander (VLAN 30)

   socstacks/soc on odin (VLAN 30)stacks/soc on odin (VLAN 30)

   sensorstacks/sensor on fenrir (VLAN 30)stacks/sensor on fenrir (VLAN 30)

   on Oct 7, 2026
2. Gerrrt

   added

   bloodhoundstacks/bloodhound on eden (VLAN 30)stacks/bloodhound on eden (VLAN 30)

   on Oct 7, 2026
3. Gerrrt commented on Oct 8, 2026

   

   Gerrrt

   on Oct 8, 2026

   Owner

   More actions

   Triaged 2026-10-08: no upstream fix exists yet, so this waits for the Dependabot bump.

   Upstream. On Docker Hub:

   • v0.5.0 and latest are still the digest we pin, sha256:1f5038b5…, last pushed on 2026-07-27.

   • There is no newer version tag.

   • master and nightly were rebuilt on 2026-10-04. Their Alpine package database, read straight from the registry, holds the same vulnerable packages as our pin:

     	libssl3 / libcrypto3	pcre2
     v0.5.0 (pinned)	3.5.7-r0	10.47-r1
     master (2026-10-04)	3.5.7-r0	10.47-r1
     fixed in	3.5.8-r0	10.48-r0 / 10.49-r0

     So even pinning the unversioned master build would fix nothing.

   Exposure, as deployed. In all five stacks (bloodhound, lab, observability, sensor, soc) the proxy has no ports:. It sits only on that stack's own compose network, and its one client is the same host's Alloy, GET-only, against the estate's allowlist (#836).

   • OpenSSL: the proxy listens on plain HTTP and does no TLS.
   • pcre2: reached only through the proxy's path matching on requests, which come from Alloy alone.

   Reaching either library means already being inside the compose network, and at that point the Docker API behind the proxy is the bigger prize anyway.

   Not doing: building our own image with apk upgrade on top. This repository pins vendor images by digest and builds none of them; a derived image would be a new kind of artefact to maintain for a low-exposure finding.

   What closes this: a new upstream tag, then Dependabot's bump, and make up on prometheus, alexander, odin, fenrir and eden. The scan closes this issue itself once the pinned digest is clean.

   🤖 Generated with Claude Code
4. Gerrrt commented on Oct 10, 2026

   

   Gerrrt

   on Oct 10, 2026

   Owner

   More actions

   Rechecked 2026-10-10: no change upstream. v0.5.0 and latest still resolve to the pinned sha256:1f5038b5…, master/nightly are still the 2026-10-04 build, and there is no newer version tag. Nothing to do yet.

   One addition to the exposure above: a sixth stack now carries this pin, analyst (garuda, #1116), at stacks/analyst/compose.yaml:50. It follows the same pattern as the other five: the estate's GET-only allowlist with POST: 0, no ports:, only on the analyst network, and Alloy as its one client. The next scan will add analyst to the stack list in the body. The triage above applies to it unchanged.
5. Gerrrt commented on Oct 10, 2026

   

   Gerrrt

   on Oct 10, 2026

   Owner

   More actions

   This is waiting on upstream. Nothing in the repo needs to change.

   • The pinned digest is current: tecnativa/docker-socket-proxy:v0.5.0 (sha256:1f5038b5…). pin-digests.sh reports no drift, so the tag hasn't been rebuilt since it was pinned.
   • There is no newer release on the registry to move to.
   • The fixed versions exist (table above), but no published image includes them yet. Mostly:
     • pcre2: 4 findings, fixed in 2 different versions (see the table)
     • libcrypto3: 1 finding, fixed in 3.5.8-r0
     • libssl3: 1 finding, fixed in 3.5.8-r0

   When upstream rebuilds or ships a release with these fixes, Dependabot should open the bump. Check it with trivy and check_image_pins.py, then deploy. The next scan will then close this issue.
6. Gerrrt commented on Oct 10, 2026

   

   Gerrrt

   on Oct 10, 2026

   Owner

   More actions

   Rechecked 2026-10-10. I found where this is actually stuck: upstream's base image is frozen at a stale HAProxy patch tag.

   Upstream's Dockerfile is FROM haproxy:3.4.2-alpine. Docker's official images only rebuild the current patch tag, so haproxy:3.4.2-alpine hasn't been rebuilt since 2026-07-06. That's why the 2026-10-04 master/nightly rebuild picked up nothing. I scanned both with our pinned trivy (HIGH/CRITICAL, fixable):

   Base	Pushed	Alpine	Findings
   haproxy:3.4.2-alpine (what upstream builds on)	2026-07-06	—	all 6 in this issue (libssl3/libcrypto3 3.5.7-r0, pcre2 10.47-r1 ×4)
   haproxy:3.4.6-alpine (= 3.4-alpine, current)	2026-09-29	3.24.2	1: pcre2 10.48-r0, CVE-2026-103111 (fixed in 10.49-r0)

   So waiting for upstream to tag a release isn't enough on its own. A tag built on the same FROM would carry the same six findings. The fix needs upstream to move the base to haproxy:3.4.6-alpine or later, then cut a release. That would clear 5 of 6. The last pcre2 finding clears when Docker rebuilds haproxy:3.4-alpine on an Alpine with pcre2 10.49.

   One caution for whoever takes that bump: upstream #180 ("HAProxy bump in v0.5.0 breaks /version calls") shows HAProxy bumps here have broken API paths before. Alloy's discovery uses /containers/json and /version, so after any Dependabot bump, check that each Alloy still lists containers.

   Still not building our own image (reasons above).
7. Gerrrt commented on Oct 10, 2026

   

   Gerrrt

   on Oct 10, 2026

   Owner

   More actions

   Upstream report: Tecnativa/docker-socket-proxy#190 (the frozen haproxy:3.4.2-alpine base; same root cause as their #178).
8. Gerrrt

   added

   analyststacks/analyst on garuda (VLAN 30)stacks/analyst on garuda (VLAN 30)

   on Oct 10, 2026
9. Gerrrt commented on Oct 11, 2026

   

   Gerrrt

   on Oct 11, 2026

   Owner

   More actions

   Rechecked 2026-10-11. The upstream fix already exists as a maintainer PR, so we won't send one.

   Tecnativa/docker-socket-proxy#185 ("[IMP] Modernize project", by a Tecnativa maintainer, open since 2026-08-31) replaces the frozen base:

   -FROM haproxy:3.4.2-alpine
   +ARG HAPROXY_VERSION=lts
   +FROM haproxy:${HAPROXY_VERSION}-alpine

   It also adds a CI matrix over HAProxy versions (docker-bake.hcl). That fixes the root cause the 15:29 comment found, a patch tag Docker no longer rebuilds, rather than just moving the pin. A one-line FROM bump from us would conflict with it. The last community HAProxy bump (#177) was withdrawn, and the maintainers did #179 themselves.

   So this waits on #185 merging and a release cut from it. Our report Tecnativa/docker-socket-proxy#190 still has no reply. v0.5.0 / latest still resolve to the pinned sha256:1f5038b5…, and the repo's last commit is 2026-07-27.

   When the bump arrives: a floating lts base means future rebuilds pick up Alpine fixes, but the digest only moves when Tecnativa pushes. As before, check that each Alloy still lists containers after the bump (upstream #180).