What happens
Images built on top of containerbase/base still contain curl 8.5.0-2ubuntu10.11. Ubuntu fixed CVE-2026-11856 in 8.5.0-2ubuntu10.12 with USN-8651-1, published 19 August 2026.
The USN covers curl, libcurl4t64, libcurl3t64-gnutls, libcurl4-openssl-dev and libcurl4-gnutls-dev on 24.04.
Why it does not clear on a rebuild
The Ubuntu layer is pinned by digest, so downstream rebuilds do not pick up the update:
containerbase/base FROM ghcr.io/containerbase/ubuntu:24.04@sha256:561618e2c15b...
containerbase/sidecar 14.14.0, released 10 Aug 2026
renovatebot/base-image FROM ghcr.io/containerbase/sidecar:14.14.0@sha256:897bce9047e2...
renovatebot/renovate sha256:27f008cc..., built 23 Aug 2026
renovatebot/base-image released 13.88.3, 13.88.4 and 13.89.0 on 20 August, 13.89.1 on the 21st and 13.89.2 on the 23rd. All of them sit on sidecar 14.14.0 from 10 August, which predates the USN by nine days. So an image built four days after the fix still ships the vulnerable package.
I could not find an apt-get update && apt-get upgrade step in containerbase/base, so I assume the OS packages come from the pinned containerbase/ubuntu image and refresh only when that pin moves.
How I found it
A Trivy based scanner reported curl 8.5.0-2ubuntu10.11 against ghcr.io/renovatebot/renovate@sha256:27f008cc48b952dff1fdceed42ef91f243f31e64596dc7f5a8754467961243ad.
I have not pulled the image to confirm by hand. To check:
docker run --rm --entrypoint dpkg-query \
ghcr.io/containerbase/ubuntu:24.04@sha256:561618e2c15bf2397621dd04f96926663a3b5616c189cf7e38db7e82f5c538ea \
-W -f='${Package} ${Version}\n' 'libcurl*' curlAsk
- Rebuild
containerbase/ubuntu:24.04 so it picks up 8.5.0-2ubuntu10.12, then move the digest pin in containerbase/base.
- If there is already a schedule for refreshing the Ubuntu base for security updates, it would help to have it written down, so downstream users know whether to wait or to raise an issue like this one.
Not urgent from my side. curl rates this Medium, CVSS 4.8, and it only affects libcurl callers that use Digest auth and reuse a handle across origins. Raising it because the pin means it will not resolve on its own, and I could not find an existing issue for it
in this org or in renovatebot
What happens
Images built on top of
containerbase/basestill containcurl 8.5.0-2ubuntu10.11. Ubuntu fixed CVE-2026-11856 in8.5.0-2ubuntu10.12with USN-8651-1, published 19 August 2026.The USN covers
curl,libcurl4t64,libcurl3t64-gnutls,libcurl4-openssl-devandlibcurl4-gnutls-devon 24.04.Why it does not clear on a rebuild
The Ubuntu layer is pinned by digest, so downstream rebuilds do not pick up the update:
renovatebot/base-imagereleased 13.88.3, 13.88.4 and 13.89.0 on 20 August, 13.89.1 on the 21st and 13.89.2 on the 23rd. All of them sit on sidecar 14.14.0 from 10 August, which predates the USN by nine days. So an image built four days after the fix still ships the vulnerable package.I could not find an
apt-get update && apt-get upgradestep incontainerbase/base, so I assume the OS packages come from the pinnedcontainerbase/ubuntuimage and refresh only when that pin moves.How I found it
A Trivy based scanner reported
curl 8.5.0-2ubuntu10.11againstghcr.io/renovatebot/renovate@sha256:27f008cc48b952dff1fdceed42ef91f243f31e64596dc7f5a8754467961243ad.I have not pulled the image to confirm by hand. To check:
Ask
containerbase/ubuntu:24.04so it picks up8.5.0-2ubuntu10.12, then move the digest pin incontainerbase/base.Not urgent from my side. curl rates this Medium, CVSS 4.8, and it only affects libcurl callers that use Digest auth and reuse a handle across origins. Raising it because the pin means it will not resolve on its own, and I could not find an existing issue for it
in this org or in renovatebot