Docker images ship a Go 1.26.4 binary, flagged HIGH by Trivy (CVE-2026-39822)

[wkup]

What happened?

What happens

The published Docker images (latest rebuild: 2026-07-09) contain a frankenphp binary built with Go 1.26.4. Go 1.26.5 (and 1.25.12) fixed CVE-2026-39822 — os.Root symlink following allows directory traversal, rated HIGH.

As a result, any image scan of a FrankenPHP-based image fails on the Go stdlib:

usr/local/bin/frankenphp (gobinary)
Total: 1 (HIGH: 1, CRITICAL: 0)

┌─────────┬────────────────┬──────────┬────────┬───────────────────┬──────────────────────────────┐
│ Library │ Vulnerability  │ Severity │ Status │ Installed Version │        Fixed Version         │
├─────────┼────────────────┼──────────┼────────┼───────────────────┼──────────────────────────────┤
│ stdlib  │ CVE-2026-39822 │ HIGH     │ fixed  │ v1.26.4           │ 1.25.12, 1.26.5, 1.27.0-rc.2 │
└─────────┴────────────────┴──────────┴────────┴───────────────────┴──────────────────────────────┘

The rest of the image is clean (debian 12.15: 0 vulnerabilities).

Reproduce

docker pull dunglas/frankenphp:1.12.4-php8.5-bookworm
trivy image --severity CRITICAL,HIGH --ignore-unfixed \
  dunglas/frankenphp:1.12.4-php8.5-bookworm

Trivy v0.71.0. The same finding appears on 1.12-php8.5-bookworm, 1-php8.5-bookworm and php8.5-bookworm, which all point at the same build.

Why it is a problem downstream

CI pipelines that gate deployments on trivy image --severity CRITICAL,HIGH --exit-code 1 cannot ship at all: the vulnerability is reported as fixed upstream (Go), but no FrankenPHP image built on Go >= 1.26.5 exists, so there is nothing to bump to. The only options left are to suppress a HIGH finding or to stop deploying — both bad.

Note the actual exploitability depends on whether the os.Root code path is reachable in a given setup; the point of this issue is the supply-chain gate, not a claim that FrankenPHP is exploitable as shipped.

Suggested fix

Rebuild and republish the Docker images (a plain rebuild of v1.12.4 on the current Go toolchain is enough — no code change required), or cut a v1.12.5 patch release.

Would it also be possible to trigger an image rebuild whenever a Go security release lands, so that stdlib CVEs are picked up without waiting for the next FrankenPHP release?

Environment

• Image: dunglas/frankenphp:1.12.4-php8.5-bookworm (also 1.12, 1, and the floating php8.5-bookworm tag)
• Base: debian 12.15 (bookworm)
• Go (in binary): 1.26.4
• Scanner: Trivy v0.71.0

Build Type

Docker (Debian Bookworm)

Worker Mode

Yes

Operating System

GNU/Linux

CPU Architecture

x86_64

PHP configuration

phpinfo() output

Image: dunglas/frankenphp:1.12.4-php8.5-bookworm (also 1.12, 1, and the floating php8.5-bookworm tag)
Base: debian 12.15 (bookworm)
Go (in binary): 1.26.4
Scanner: Trivy v0.71.0

Relevant log output

Relevant log output

[AlliBalliBaba]

Hmm looking at the docker image builds, even ones from a week ago were using version 1.26.5. Are you still seeing an old go version on a fresh image pull?

[dunglas]

Closing for now. Feel free to reopen if needed.