CVE-2026-128027: FrankenPHP Docker Images Left Stale System Libraries Open to Remote Exploitation

On the surface, CVE-2026-128027 sounds like a familiar story: outdated base images leading to unpatched system libraries inside containers. But the details here matter, because they reveal a systemic flaw in how the FrankenPHP project handled image rebuilds — one that left downstream users exposed to known, network-exploitable vulnerabilities in core system components for far longer than they should have been.

NVD assigned this CVE a CVSS score of 9.8, marking it as CRITICAL with a NETWORK attack vector. That combination is rare and serious. It means an attacker does not need local access, valid credentials, or user interaction to potentially achieve remote code execution. They only need to reach a vulnerable service over the network. In environments where FrankenPHP containers sit behind load balancers or handle public-facing PHP workloads, this is the kind of exposure that turns a routine scanning alert into an active incident.

For defenders, this is not just about patching a container image. It is about understanding a supply-chain gap in how a widely used PHP runtime was packaged and distributed, and ensuring that your environment is not still running stale, vulnerable layers.

Technical Analysis

What Is FrankenPHP and Why Does This Matter?

FrankenPHP is a modern PHP application server that embeds PHP directly into a Go-based web server, offering features like automatic HTTPS, HTTP/2 and HTTP/3 support, and a built-in Caddy web server. It has gained traction among teams looking for a performant, self-contained PHP runtime that is easy to deploy in containerized environments.

Like most containerized applications, FrankenPHP publishes official Docker images built on top of base layers — in this case, Alpine Linux with PHP and Go toolchain components. These images bundle not just the FrankenPHP binary, but the underlying system libraries that PHP and Go depend on, including OpenSSL's libcrypto3, which handles all cryptographic operations.

The Core Problem: Rebuild Logic That Ignored Security Fixes

The vulnerability stems from how the FrankenPHP project managed its Docker image build pipeline. According to the NVD entry, FrankenPHP Docker images before version 1.1.11 were only rebuilt when new base image tags were created. In other words, the project waited for Alpine Linux, PHP, or Go to publish a new version tag before triggering a rebuild.

The problem is that Linux distributions and language runtimes frequently backport security fixes to existing tags without incrementing the tag version. Alpine Linux, for example, regularly pushes updated packages under the same 3.19 or 3.20 tag. PHP and Go do the same for patch-level releases. By only rebuilding on new tags, FrankenPHP missed these security updates entirely, leaving stale system libraries in place even after fixes were available upstream.

The Downstream Risk: CVE-2025-15467 in libcrypto3

The NVD summary specifically calls out CVE-2025-15467 in libcrypto3 as an example of the kind of known flaw that could remain unpatched inside FrankenPHP images. libcrypto3 is the core cryptographic library in OpenSSL 3.x, used for TLS handshakes, certificate verification, encryption, and hashing. A remote code execution vulnerability in this library — especially one reachable via network-facing TLS endpoints — is exactly the kind of issue that can turn a container into a beachhead.

Because FrankenPHP images were not rebuilt to pick up Alpine's patched libcrypto3 packages, any FrankenPHP container built before 1.1.11 that exposes a TLS endpoint could still be running a vulnerable version of OpenSSL, even if the host system and orchestration platform are fully patched.

Exploitation Requirements

From a defender's perspective, the attack chain here is straightforward:

An attacker identifies a FrankenPHP container running a version prior to 1.1.11.
The attacker scans for known vulnerabilities in the stale system libraries, such as CVE-2025-15467 in libcrypto3.
If a network-exploitable vulnerability is present, the attacker can trigger it remotely, potentially achieving code execution inside the container.
From there, the attacker can pivot to the host, access secrets, or move laterally within the cluster.

The CVSS 9.8 score reflects the fact that no authentication or user interaction is required. If your FrankenPHP container handles inbound TLS connections, it is a target.

Exploitation Status

As of this writing, there is no public proof-of-concept exploit specifically for CVE-2026-128027, nor has it been added to CISA's Known Exploited Vulnerabilities (KEV) catalog. However, the underlying issue — stale base images with known vulnerabilities — is a well-understood attack vector. The specific library flaw referenced, CVE-2025-15467, is from 2025 and may already have public exploit code or active scanning activity. Defenders should assume that any unpatched FrankenPHP container is being probed.

Detection & Response

This is a technical vulnerability affecting containerized infrastructure. The following detection content is designed to help you identify vulnerable images, anomalous container behavior, and potential exploitation attempts.

Sigma Rules

YAML

---
title: FrankenPHP Container Spawning Unexpected Processes
id: 7a3f1c82-9e4b-4d67-bc12-3e5a8f901234
status: experimental
description: Detects unexpected process execution inside a FrankenPHP container, which may indicate exploitation of a stale system library vulnerability.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-128027
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.execution
  - attack.t1059
logsource:
  category: process_creation
  product: linux
detection:
  selection:
    Image|contains:
      - 'frankenphp'
    CommandLine|contains:
      - 'sh -c'
      - 'bash -c'
      - 'curl'
      - 'wget'
      - 'nc'
      - 'python'
      - 'perl'
  condition: selection
falsepositives:
  - Legitimate administrative debugging inside containers
level: high
---
title: OpenSSL libcrypto3 Version Mismatch in Container
id: 550d9a23-0f72-4e3a-a8c5-1d2f3b4c5d6e
status: experimental
description: Detects containers running FrankenPHP with an outdated libcrypto3 version, indicating exposure to CVE-2026-128027.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-128027
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.vulnerability
  - attack.t1190
logsource:
  category: file_event
  product: linux
detection:
  selection:
    TargetFilename|contains:
      - 'libcrypto.so.3'
    Image|contains:
      - 'frankenphp'
  condition: selection
falsepositives:
  - Legitimate library updates during image rebuilds
level: medium

KQL (Microsoft Sentinel / Defender)

If you are collecting container logs and process events into Sentinel via CEF/Syslog or Defender for Endpoint, the following query will help you identify FrankenPHP containers that may still be running vulnerable images.

KQL — Microsoft Sentinel / Defender

// Hunt for FrankenPHP containers with unexpected process execution
DeviceProcessEvents
| where ProcessCommandLine contains "frankenphp"
| where ProcessCommandLine contains "sh -c" or ProcessCommandLine contains "bash -c" or ProcessCommandLine contains "curl" or ProcessCommandLine contains "wget" or ProcessCommandLine contains "nc"
| project TimeGenerated, DeviceName, ProcessName, ProcessCommandLine, InitiatingProcessName, InitiatingProcessCommandLine
| order by TimeGenerated desc

// Identify containers running outdated libcrypto3
Syslog
| where SyslogMessage contains "frankenphp" and SyslogMessage contains "libcrypto.so.3"
| project TimeGenerated, Computer, SyslogMessage
| order by TimeGenerated desc

Velociraptor VQL

For endpoint forensics on container hosts, this VQL artifact will enumerate running FrankenPHP processes and check for unexpected child processes or network connections.

VQL — Velociraptor

-- Hunt for FrankenPHP processes with unexpected child processes or network activity
SELECT Pid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE CommandLine =~ 'frankenphp'
   OR Exe =~ 'frankenphp'

-- Check for network connections from FrankenPHP processes
SELECT Pid, Name, RemoteAddr, RemotePort, State
FROM netstat()
WHERE Name =~ 'frankenphp'

Remediation Script (Bash)

Use this script to identify running FrankenPHP containers, check their image tags, and verify whether they are running a vulnerable version. It also checks the libcrypto3 version inside the container.

Bash / Shell

#!/bin/bash
# Identify running FrankenPHP containers and check for stale libcrypto3

set -e

echo "=== FrankenPHP Container Vulnerability Check ==="
echo

# List all running containers with 'frankenphp' in the image name
containers=$(docker ps --format '{{.ID}} {{.Image}}' | grep -i frankenphp || true)

if [ -z "$containers" ]; then
  echo "No running FrankenPHP containers found."
  exit 0
fi

for line in $containers; do
  container_id=$(echo "$line" | awk '{print $1}')
  image_name=$(echo "$line" | awk '{print $2}')

  echo "Checking container: $container_id (Image: $image_name)"

  # Extract FrankenPHP version from image tag
  version=$(echo "$image_name" | grep -oE '[0-9]+\.[0-9]+\.[0-9]+' | head -1)

  if [ -z "$version" ]; then
    echo "  [WARN] Could not determine FrankenPHP version from image tag. Manual inspection required."
    continue
  fi

  # Compare version to 1.1.11
  if [ "$(printf '%s\n' "1.1.11" "$version" | sort -V | head -1)" != "1.1.11" ]; then
    echo "  [VULNERABLE] FrankenPHP version $version is below 1.1.11. Rebuild required."
  else
    echo "  [OK] FrankenPHP version $version is 1.1.11 or higher."
  fi

  # Check libcrypto3 version inside container
  echo "  Checking libcrypto3 version inside container..."
  docker exec "$container_id" sh -c 'apk info -v libcrypto3 2>/dev/null || echo "libcrypto3 not found"' || true

  echo
 done

echo "=== Check Complete ==="

Remediation

Immediate Actions

Upgrade to FrankenPHP 1.1.11 or later. The FrankenPHP project has fixed the rebuild pipeline issue in version 1.1.11. Pull the latest image and redeploy your containers immediately.
Verify base image freshness. After upgrading, confirm that your container is running the latest Alpine Linux, PHP, and Go packages. Use docker exec <container> apk upgrade to check for pending updates, but note that this is a temporary measure — the fix must come from a rebuilt image.
Audit all container images for stale libraries. This issue is not unique to FrankenPHP. Run a vulnerability scan across all running containers using tools like Trivy, Grype, or Clair to identify other images with outdated system libraries.

Configuration Changes

Enforce image pinning and rebuild policies. Do not rely on mutable tags like latest or 1.1. Pin your deployments to specific image digests and implement automated rebuilds whenever base images are updated.
Enable automatic base image updates. Use tools like Renovate, Dependabot, or a CI/CD pipeline that triggers image rebuilds when Alpine, PHP, or Go release security patches.
Restrict container capabilities. Run FrankenPHP containers with minimal privileges. Drop unnecessary Linux capabilities, use read-only root filesystems where possible, and avoid running as root.

Vendor Advisory and References

NVD Entry: https://nvd.nist.gov/vuln/detail/CVE-2026-128027
FrankenPHP GitHub Releases: Check the official FrankenPHP repository for release notes and updated Docker images.
Alpine Linux Security Advisories: Monitor Alpine's security feed for updates to libcrypto3 and other core libraries.

CISA Deadlines

As of this writing, CVE-2026-128027 has not been added to CISA's Known Exploited Vulnerabilities catalog, so there is no federal remediation deadline. However, given the CVSS 9.8 score and the potential for remote code execution, treat this with the same urgency as a KEV entry. Remediate within 72 hours if the container handles public traffic, and within 7 days for internal services.

Conclusion

CVE-2026-128027 is a reminder that container security is not just about the application code — it is about the entire stack, including the base image, system libraries, and the build pipeline that assembles them. A well-intentioned but flawed rebuild policy left FrankenPHP users exposed to known vulnerabilities for an extended period, and the consequences could be severe.

For defenders, the lesson is clear: assume your containers are running stale libraries unless you have explicit, automated processes to rebuild and redeploy them when upstream fixes are released. Patch your FrankenPHP containers now, audit your entire container estate, and close the gap between "latest tag" and "latest security fix."

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub