GHSA-x9p2-77v6-6vhf — frankenphp
CRITICALGHSA-x9p2-77v6-6vhf is a critical-severity (CVSS 9.8) remote code execution vulnerability in github.com/dunglas/frankenphp. A fix is available for github.com/dunglas/frankenphp — see the affected versions and patch details below.
FrankenPHP has delayed propagation of security fixes in upstream base images
Real-World Exposure
github.com/dunglas/frankenphpReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.
Description
Delayed propagation of security fixes in upstream base images
Summary
Vulnerability in base Docker images (PHP, Go, and Alpine) not automatically propagating to FrankenPHP images.
FrankenPHP's container images were previously built only when specific version tags were updated or when manual triggers were initiated. This meant that if an upstream base image (such as Alpine Linux or official PHP/Go images) received a security patch under an existing tag, the FrankenPHP image would remain on the older, vulnerable version of those base layers.
Impact
Users pulling FrankenPHP images may have been running environments with known vulnerabilities in underlying system libraries (e.g., libcrypto3) even if they were using the "latest" version of a specific FrankenPHP tag.
Specifically, this includes vulnerabilities recently patched in Alpine 3.20.9, 3.21.6, 3.22.3, and 3.23.3, such as CVE-2025-15467 (Remote Code Execution in libcrypto3).
Details
The issue was a lack of automated "staleness" detection in the CI/CD pipeline.
Unless explicitly told, our build server was building new Docker images only when a new tag for base images was created. However, base images such as Alpine, PHP, and Go usually overwrite existing Docker tags to apply security fixes, which wasn't triggering a new build on our side.
Patches
As of February 4, 2026, the CI/CD pipeline has been updated.
- Automated Detection: A daily check is now performed to compare the digest of local base images against upstream registries.
- Auto-Rebuild: If a change is detected in base images (even if the tag name remains the same), FrankenPHP images are automatically rebuilt and re-pushed.
Users are advised to pull the latest versions of their specific tags to receive these updates.
Workarounds
You can force a local rebuild of your environment using the --pull flag to ensure you are fetching the latest patched base layers:
docker pull dunglas/frankenphp:latest
# If building your own image based on FrankenPHP
docker build --pull -t my-app .
References
- Alpine Linux Security Advisories
- CVE-2025-15467 (RCE in libcrypto3)
Credits
Thanks to Tim Nelles for reporting and fixing this issue.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/dunglas/frankenphp | all versions | 1.1.11go get github.com/dunglas/frankenphp@v1.1.11 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/dunglas/frankenphp, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update github.com/dunglas/frankenphp to 1.1.11 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-x9p2-77v6-6vhf is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like GHSA-x9p2-77v6-6vhf can be triaged on real exposure rather than presence alone.
Tailored to GHSA-x9p2-77v6-6vhf. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-x9p2-77v6-6vhf in your dependencies?
O3 Security finds GHSA-x9p2-77v6-6vhf across Go dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.