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.
dunglas commentedon Oct 16, 2026
Release published, sorry about that. I'm not sure if it is worth it to change the workflow files, in theory the release should be published just after the tag... but I messed this step up this time.
zaccesss commentedon Oct 18, 2026
Thanks for publishing the release. I checked the registry today and the Debian floating tags have moved to 1.13.1, but the Alpine ones have not:
1-php8.4sha256:b32a81ad4db41.13.1-php8.41-php8.4-alpinesha256:001bf9290f601.13.0-php8.4-alpine1-alpinesha256:1373eac4c3d31.13.0-alpineThe scheduled run after the release (39001060911) only built the trixie variants, so the Alpine floating tags were never repointed and still ship
golang.org/x/net v0.59.0. Could the Alpine images be rebuilt? Happy to open a separate issue if that is easier to track.zaccesss commentedon Oct 18, 2026
@dunglas @AlliBalliBaba I think I've found why Alpine was left behind. The nightly only rebuilds a variant when its base images have changed since the versioned builder tag (
1.13.1-builder-php8.4-alpineand so on, indocker-compute-fingerprints.sh). The 1.13.1 Alpine images were built on 10 October, then the scheduled run on 11 October (while the release was still a draft) rebuilt 1.13.0 and pushed the floating Alpine tags back to it. After the release was published the Debian base images had changed, so those variants were rebuilt and their floating tags moved to 1.13.1. The Alpine bases had not changed, so Alpine was skipped. Its floating tags will stay on 1.13.0 until the Alpine base image next changes.I've opened #2726 with a small fix: the nightly also rebuilds a variant when its floating tag's
org.opencontainers.image.versionlabel does not match the latest release. Feel free to close it if you'd rather not change the workflow; a manual run of the Docker workflow onv1.13.1would repoint the Alpine tags too.