Repository navigation
Bug: 1-php8.4-alpine remains on x/net 0.59.0 after 1.13.1 build #2710
Description
What happened?
The floating Docker tag dunglas/frankenphp:1-php8.4-alpine still resolves to an image that contains golang.org/x/net v0.59.0. Trivy reports the fixed high-severity CVE-2026-78669 against that binary.
#2707 updated the dependency. It merged as 77b32f5517ec419725a945d12bc48ba10eabce6f. The v1.13.1 source tag contains golang.org/x/net v0.61.0. The v1.13.1 Docker-image build completed successfully. Its explicit image tag, dunglas/frankenphp:1.13.1-php8.4-alpine, is available.
Could 1-php8.4-alpine be repointed to the v1.13.1 image? Alternatively, could the intended major-tag policy be documented? The current state leaves users of the documented major tag on an older image despite the nightly-rebuild statement in SECURITY.md.
This is related to #2459. That issue tracks a different HTTP/2 denial-of-service concern, so this is not a duplicate.
Build Type
Docker (Alpine)
Worker Mode
No
Operating System
GNU/Linux
CPU Architecture
x86_64
PHP configuration
Not applicable. The discrepancy is visible in the published image and its source tag.
Relevant log output
usr/local/bin/frankenphp (gobinary)
Library: golang.org/x/net
Vulnerability: CVE-2026-78669
Severity: HIGH
Installed Version: v0.59.0
Fixed Version: 0.60.0
Activity
AlliBalliBaba commentedon Oct 12, 2026
Seems like the release push for 1.13.1 was running with the new dependencies https://github.com/php/frankenphp/actions/runs/38071545577
but the scheduled push afterwards overwrote it and was still using1.13.0
https://github.com/php/frankenphp/actions/runs/38110437773
@dunglas this is probably due to the 1.13.1 release still missing, as the scheduled run bases its version on the latest release. (1.13.1 is still a.draft telease, but the tag exists)
AlliBalliBaba commentedon Oct 15, 2026
I think @dunglas just forgot to publish the release as it's still in draft. I'd publish it myself, but would like to confirm first if there's another reason.
sovrin-tio commentedon Oct 16, 2026
Looks like the two workflows disagree on what "latest" is.
release.yamlcreates the release as a draft and then dispatchesdocker.yaml, which already pushes the floating tags (1,latest,1-phpX.Y). The nightly rebuild picks its version withgh release view, though, and that only returns published releases.So while v1.13.1 is still a draft, the nightly puts the v1.13.0 images back on the floating tags. That's what happened here: the v1.13.1 build ran on Oct 10, and the scheduled rebuild on Oct 11 overwrote
1-php8.4-alpineagain.Same thing hit
1-php8.5in the Oct 14 nightly, which is how we noticed: Renovate opened a PR downgrading us to 1.13.0.What's the intended behavior? Should floating tags follow the latest stable git tag, or only move once the release is published? Happy to open a PR once it’s clear which way you’d prefer.