CVE-2026-128015 in FrankenPHP
Summary
by MITRE • 11/13/2026
FrankenPHP before 1.13.4 contains a use-after-free vulnerability that leaves a dangling pointer to a freed environment table when putenv() is called during request shutdown. Attackers triggering putenv() in shutdown functions, destructors, or session handlers can crash the process on the next getenv() call or leak previous request environment values.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 11/13/2026
The vulnerability identified in FrankenPHP versions prior to 1.13.4 represents a critical memory management flaw classified as a use-after-free condition. This specific defect occurs within the internal handling of environment variables during the lifecycle of an HTTP request, specifically when the putenv function is invoked during the shutdown phase of the server process. In standard web application architectures, the request lifecycle involves initialization, execution, and finally cleanup or shutdown phases where resources are released to prepare for subsequent requests. The flaw arises because the internal data structures managing environment variables are deallocated prematurely while references to them remain active in memory. When putenv is called during this sensitive window, it modifies an environment table that has already been freed by the runtime engine, leaving a dangling pointer that points to invalid or recycled memory addresses rather than valid configuration data.
From a technical perspective, this vulnerability exploits the race condition between garbage collection mechanisms and explicit function calls within shutdown handlers such as destructors, session handlers, or registered shutdown functions. These hooks are designed to execute code after the main request logic has completed but before the entire process terminates or resets for the next connection. By triggering putenv in these contexts, an attacker can manipulate the state of memory that is no longer protected by standard allocation boundaries. The consequence of this manipulation depends on how quickly subsequent operations access environment variables. If a getenv call occurs immediately after the corrupted pointer is established, it attempts to read from freed memory, which typically results in immediate process termination or segmentation fault due to accessing unmapped pages. This leads to a denial of service condition where the web server becomes unstable and requires restarts to restore functionality.
Beyond simple crashes, this vulnerability poses significant risks related to information disclosure through side-channel attacks or data leakage. Because the freed memory is often reused for new allocations in high-concurrency environments like those managed by FrankenPHP, previous request environment values may still reside in the same memory locations now pointed to by the dangling pointer. An attacker who can control the timing and content of subsequent requests might be able to read sensitive information from prior sessions, such as authentication tokens, session IDs, or internal configuration details that were not properly cleared before deallocation. This type of vulnerability aligns with CWE-416, which describes use-after-free errors leading to undefined behavior, and can also map to ATT&CK techniques involving memory manipulation for credential access or disruption of service availability.
The operational impact extends beyond immediate crashes to include potential privilege escalation if the server runs under elevated privileges, although in typical web hosting scenarios, the primary concern remains stability and confidentiality. The ability to crash the process disrupts service continuity, affecting all users connected through that worker process. Furthermore, leaking previous request data compromises user privacy and security posture by exposing potentially sensitive metadata across different sessions or requests. This is particularly dangerous in multi-tenant environments where isolation between users relies heavily on proper memory management and state separation during request boundaries.
Mitigation strategies primarily involve upgrading to FrankenPHP version 1.13.4 or later, where the internal handling of environment tables has been corrected to ensure that pointers are nullified after deallocation and that shutdown functions do not interact with freed resources. For organizations unable to upgrade immediately, implementing strict controls over which PHP extensions can be loaded during request shutdown may reduce exposure. Additionally, deploying web application firewalls or runtime security monitoring tools that detect abnormal memory access patterns or frequent process crashes can help identify exploitation attempts in real-time. Developers should also audit custom code for any use of putenv within destructors or session handlers and refactor such logic to occur earlier in the request lifecycle where environment tables are still valid, thereby avoiding interaction with freed memory structures entirely.