Vulnerability Database

413,619

Total vulnerabilities in the database

FrankenPHP has delayed propagation of security fixes in upstream base images — github.com/dunglas/frankenphp

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

Credits

Thanks to Tim Nelles for reporting and fixing this issue.

  • Published: Feb 5, 2026
  • Updated: Mar 1, 2026
  • GHSA: GHSA-x9p2-77v6-6vhf
  • Severity: Critical
  • Exploit:
  • CISA KEV:

CVSS v3:

  • Severity: Critical
  • Score: 9.8
  • AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Is frankenphp exposed on your perimeter?

A vulnerability database tells you what is broken. Attack surface management tells you where it is running: it discovers your internet-facing assets and flags the ones affected by issues like this one.

What is attack surface management? →

Frequently Asked Questions

A security vulnerability is a weakness in software, hardware, or configuration that can be exploited to compromise confidentiality, integrity, or availability. Many vulnerabilities are tracked as CVEs (Common Vulnerabilities and Exposures), which provide a standardized identifier so teams can coordinate patching, mitigation, and risk assessment across tools and vendors.

CVSS (Common Vulnerability Scoring System) estimates technical severity, but it doesn't automatically equal business risk. Prioritize using context like internet exposure, affected asset criticality, known exploitation (proof-of-concept or in-the-wild), and whether compensating controls exist. A "Medium" CVSS on an exposed, production system can be more urgent than a "Critical" on an isolated, non-production host.

A vulnerability is the underlying weakness. An exploit is the method or code used to take advantage of it. A zero-day is a vulnerability that is unknown to the vendor or has no publicly available fix when attackers begin using it. In practice, risk increases sharply when exploitation becomes reliable or widespread.

Recurring findings usually come from incomplete Asset Discovery, inconsistent patch management, inherited images, and configuration drift. In modern environments, you also need to watch the software supply chain: dependencies, containers, build pipelines, and third-party services can reintroduce the same weakness even after you patch a single host. Unknown or unmanaged assets (often called Shadow IT) are a common reason the same issues resurface.

Use a simple, repeatable triage model: focus first on externally exposed assets, high-value systems (identity, VPN, email, production), vulnerabilities with known exploits, and issues that enable remote code execution or privilege escalation. Then enforce patch SLAs and track progress using consistent metrics so remediation is steady, not reactive.

SynScan combines attack surface monitoring and continuous security auditing to keep your inventory current, flag high-impact vulnerabilities early, and help you turn raw findings into a practical remediation plan.