frankenphp:8.5 ships 10 fixable CRITICAL/HIGH Go CVEs, and the 2026-08-11 rebuild did not move them #47

Open
opened 2026-08-15 23:38:31 +00:00 by geusebio · 0 comments
Owner

matthewbaggett/frankenphp:8.5 ships a Go binary with 10 fixable CRITICAL/HIGH
CVEs, and the 2026-08-11 rebuild did not move any of them.

Downstream this is
Someones.Computer#354,
where it fails the nightly CVE gate on every image built on this base.

What is in the binary

/usr/bin/frankenphp, in the current :8.5 (= 8.5-build-2026-08-11,
sha256:053a6ec3ee8b84473a0f0adac974085df27bba401917c7d57f65e7ddddb643bd on
amd64):

Advisory Severity Module Installed Fixed in
GHSA-r277-6w6q-xmqw CRITICAL github.com/getkin/kin-openapi v0.140.0 0.144.0
GHSA-hrxh-6v49-42gf HIGH google.golang.org/grpc v1.81.1 1.82.1
CVE-2026-33818 HIGH stdlib go1.26.5 1.26.6
CVE-2026-39821 HIGH stdlib go1.26.5 1.26.6
CVE-2026-46600 HIGH stdlib go1.26.5 1.26.6
CVE-2026-56853 HIGH stdlib go1.26.5 1.26.6
CVE-2026-56858 HIGH stdlib go1.26.5 1.26.6
CVE-2026-56859 HIGH stdlib go1.26.5 1.26.6
CVE-2026-56860 HIGH stdlib go1.26.5 1.26.6
CVE-2026-56862 HIGH stdlib go1.26.5 1.26.6

The Alpine package set is clean — trivy finds 0 OS-package findings at any
severity. This is entirely the one binary.

The 2026-08-11 rebuild changed nothing here

Worth stating plainly, because "the tag floats, so a rebuild picks up the fix"
is the reasonable assumption and it does not hold. The two builds are
byte-identical in the ways that matter to a scanner:

8.5-build-2026-08-04 8.5 (= 8.5-build-2026-08-11)
kin-openapi v0.140.0 v0.140.0
grpc v1.81.1 v1.81.1
Go toolchain go1.26.5 go1.26.5
FrankenPHP v1.12.6 v1.12.7

Reproducing it

Scanning the image is not reliable here — trivy image reports the
gobinary target on the 08-04 build and silently omits it on 08-11, on the
same trivy and the same cache, so an image-mode scan of the current tag looks
clean when it is not. Extract the binary and scan that:

cid=$(docker create --platform linux/amd64 matthewbaggett/frankenphp:8.5)
docker cp "$cid:/usr/bin/frankenphp" ./frankenphp && docker rm -f "$cid"
docker run --rm -v "$PWD:/scan:ro" aquasec/trivy rootfs /scan/frankenphp

That discrepancy is worth a look in its own right — if it is general rather
than specific to these two images, every consumer scanning this base in image
mode is getting a false green on Go findings.

Where the fix has to come from

FrankenPHP.Dockerfile installs a prebuilt package rather than building
FrankenPHP:

apk add --no-cache nss-tools su-exec xorriso frankenphp $FRANKENPHP_PACKAGES

from pkg.henderkes.com, currently frankenphp-1.12.7p85-r0. So nothing in
this repo can move these versions, and there is no newer upstream release to
move to either:

  • FrankenPHP's newest release is v1.12.7 (2026-08-07), which is what is
    installed.
  • Caddy's newest release is v2.11.4 (2026-06-03), which is what is
    embedded. Caddy's master already carries grpc v1.82.1, but no release
    does yet.
  • kin-openapi is not in FrankenPHP's go.mod at all — it arrives
    transitively.

That leaves two routes, and the choice is yours rather than mine:

  1. Ask the package publisher for a rebuild against a Go 1.26.6+ toolchain
    with kin-openapi and grpc bumped. Clears all ten at once, keeps this
    repo's build as simple as it is.
  2. Build FrankenPHP from source here, with explicit go get overrides for
    the two modules. Fixes it without waiting on anyone, at the cost of owning a
    Go build in this repo — considerably more than the apk line it replaces.

Waiting for upstream releases to carry the bumps is a third option, but it is
not a plan with a date on it, and the downstream gate is red now.

Done when

  • matthewbaggett/frankenphp:8.5 no longer ships kin-openapi < 0.144.0,
    grpc < 1.82.1, or a Go stdlib below 1.26.6.
  • trivy rootfs on the extracted binary reports no fixable CRITICAL/HIGH.
`matthewbaggett/frankenphp:8.5` ships a Go binary with 10 fixable CRITICAL/HIGH CVEs, and the 2026-08-11 rebuild did not move any of them. Downstream this is [Someones.Computer#354](https://git.grey.ooo/Grey.ooo/Someones.Computer/issues/354), where it fails the nightly CVE gate on every image built on this base. ## What is in the binary `/usr/bin/frankenphp`, in the current `:8.5` (= `8.5-build-2026-08-11`, `sha256:053a6ec3ee8b84473a0f0adac974085df27bba401917c7d57f65e7ddddb643bd` on amd64): | Advisory | Severity | Module | Installed | Fixed in | | --- | --- | --- | --- | --- | | GHSA-r277-6w6q-xmqw | CRITICAL | `github.com/getkin/kin-openapi` | v0.140.0 | 0.144.0 | | GHSA-hrxh-6v49-42gf | HIGH | `google.golang.org/grpc` | v1.81.1 | 1.82.1 | | CVE-2026-33818 | HIGH | `stdlib` | go1.26.5 | 1.26.6 | | CVE-2026-39821 | HIGH | `stdlib` | go1.26.5 | 1.26.6 | | CVE-2026-46600 | HIGH | `stdlib` | go1.26.5 | 1.26.6 | | CVE-2026-56853 | HIGH | `stdlib` | go1.26.5 | 1.26.6 | | CVE-2026-56858 | HIGH | `stdlib` | go1.26.5 | 1.26.6 | | CVE-2026-56859 | HIGH | `stdlib` | go1.26.5 | 1.26.6 | | CVE-2026-56860 | HIGH | `stdlib` | go1.26.5 | 1.26.6 | | CVE-2026-56862 | HIGH | `stdlib` | go1.26.5 | 1.26.6 | The Alpine package set is clean — `trivy` finds 0 OS-package findings at any severity. This is entirely the one binary. ## The 2026-08-11 rebuild changed nothing here Worth stating plainly, because "the tag floats, so a rebuild picks up the fix" is the reasonable assumption and it does not hold. The two builds are byte-identical in the ways that matter to a scanner: | | `8.5-build-2026-08-04` | `8.5` (= `8.5-build-2026-08-11`) | | --- | --- | --- | | kin-openapi | v0.140.0 | v0.140.0 | | grpc | v1.81.1 | v1.81.1 | | Go toolchain | go1.26.5 | go1.26.5 | | FrankenPHP | v1.12.6 | v1.12.7 | ## Reproducing it Scanning the *image* is not reliable here — `trivy image` reports the `gobinary` target on the 08-04 build and silently omits it on 08-11, on the same trivy and the same cache, so an image-mode scan of the current tag looks clean when it is not. Extract the binary and scan that: ```bash cid=$(docker create --platform linux/amd64 matthewbaggett/frankenphp:8.5) docker cp "$cid:/usr/bin/frankenphp" ./frankenphp && docker rm -f "$cid" docker run --rm -v "$PWD:/scan:ro" aquasec/trivy rootfs /scan/frankenphp ``` That discrepancy is worth a look in its own right — if it is general rather than specific to these two images, every consumer scanning this base in image mode is getting a false green on Go findings. ## Where the fix has to come from `FrankenPHP.Dockerfile` installs a prebuilt package rather than building FrankenPHP: ``` apk add --no-cache nss-tools su-exec xorriso frankenphp $FRANKENPHP_PACKAGES ``` from `pkg.henderkes.com`, currently `frankenphp-1.12.7p85-r0`. So nothing in this repo can move these versions, and there is no newer upstream release to move to either: - FrankenPHP's newest release is **v1.12.7** (2026-08-07), which is what is installed. - Caddy's newest release is **v2.11.4** (2026-06-03), which is what is embedded. Caddy's `master` already carries `grpc v1.82.1`, but no release does yet. - `kin-openapi` is not in FrankenPHP's `go.mod` at all — it arrives transitively. That leaves two routes, and the choice is yours rather than mine: 1. **Ask the package publisher for a rebuild** against a Go 1.26.6+ toolchain with `kin-openapi` and `grpc` bumped. Clears all ten at once, keeps this repo's build as simple as it is. 2. **Build FrankenPHP from source here**, with explicit `go get` overrides for the two modules. Fixes it without waiting on anyone, at the cost of owning a Go build in this repo — considerably more than the apk line it replaces. Waiting for upstream releases to carry the bumps is a third option, but it is not a plan with a date on it, and the downstream gate is red now. ## Done when - [ ] `matthewbaggett/frankenphp:8.5` no longer ships `kin-openapi` < 0.144.0, `grpc` < 1.82.1, or a Go stdlib below 1.26.6. - [ ] `trivy rootfs` on the extracted binary reports no fixable CRITICAL/HIGH.
Sign in to join this conversation.
No labels
No milestone
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
Grey.ooo/docker#47
No description provided.