The core of PHP, one of the most widely deployed backend technologies, has undergone a comprehensive security audit in 2025. Commissioned and funded by independent external parties, this audit was conducted by an independent security company. Over the course of 57 days, the company reviewed critical components of the PHP interpreter (php-src) in preparation for the release of PHP 8.4.
This post summarizes the audit’s results, outlines relevant technical risks for teams running PHP in production, and highlights recommended next steps for improving the security posture of PHP-based applications.
Why the Audit Was Conducted
PHP powers a large portion of the modern internet, including e-commerce systems, CMS platforms, enterprise intranets and Software-as-a-Service (SaaS) backends. While its feature set has evolved considerably, the runtime itself remains performance-critical and security-sensitive.
The objective of the 2025 PHP security audit was not only to identify vulnerabilities, but to assess structural weaknesses, validate assumptions in cryptographic usage, evaluate PHP-FPM behavior, and establish best practices for safe deployment – particularly in environments where multi-tenancy or persistent processes are involved.
Want to write more secure PHP?
Grab the Hardening Checklist for Developers & Operators, created as part of this blog post. Download it here
The scope included:
- PHP-FPM (FastCGI Process Manager)
- RFC 1867 multipart/form-data upload handling
- PDO and the native MySQL driver
- JSON decoding
- PHP’s integration with OpenSSL and libsodium
- Password hashing and CSPRNG behavior
- Static and dynamic analysis tooling (SAST, fuzzing)
Overview of Findings
The audit resulted in the identification of:
- 3 high-severity vulnerabilities
- 5 medium-severity issues
- 9 low-severity issues
- 10 informative findings
Several of these have already been assigned CVEs, including:
- CVE-2024–8929: Heap buffer over-read in the MySQL native driver
- CVE-2024–9026: Log manipulation vulnerability via PHP-FPM
- CVE-2024–8925: Multipart parser error in RFC 1867 upload handling
The findings primarily concern stability, memory safety, input handling, cryptographic interface integrity, and developer-facing documentation gaps.
Analysis of Key Areas
Let’s have a deeper look into the findings of the key areas. The goal is to have a comprehensive overview in order to be able to conclude action steps to make code bases more robust.
PHP-FPM
The 2025 security audit revealed that PHP-FPM’s internal logic contains several weak points (CVE-2024–9026) that can become significant in shared environments. Specifically:
- Improper validation of UID/GID values can cause privilege confusion or result in persistent worker crashes.
- Standard output and error redirection in PHP-FPM logs can be manipulated to inject null characters, leading to log truncation or tampering.
From a deployment perspective, this implies that improper pool configuration or unvalidated input could degrade system observability and security auditing reliability.
MySQL Native Driver
A high-severity vulnerability (CVE-2024–8929) was found in the MySQL driver used by PHP. A so called heap over-read can occur when parsing server responses, potentially exposing in-memory data.
This poses a particular risk in persistent environments (e.g., PHP-FPM workers, Octane in Laravel) where session tokens, secrets, or serialized data may remain in memory and be unintentionally disclosed.
Input Validation in File Uploads (RFC 1867)
The file upload implementation, which processes multipart/form-data, suffers from several input validation issues:
- Boundary values are not properly constrained in size or character set
- Input parsing can result in memory exhaustion or faulty state transitions
Although not immediately exploitable in most contexts, the accumulated risk can affect stability and correctness, particularly under high load or during file-based attacks.
Cryptographic Functions
PHP’s integration with OpenSSL and libsodium is functional, but suffers from ambiguity and inconsistency at the API level. Key findings include:
- Truncated keys and IVs are silently accepted in multiple contexts
- Some functions (e.g.,
openssl_seal,openssl_csr_new) lack clear documentation regarding parameters - Weak defaults for cipher modes and iteration counts persist in public interfaces
The cryptographic primitives themselves are secure, but the surrounding developer experience facilitates incorrect or unsafe usage.
Recommended Actions
For teams maintaining PHP-based systems, the following actions are recommended:
- Review PHP-FPM pool configurations, especially regarding user and group assignments
- Sanitize or redirect FPM logs in ways that prevent truncation or manipulation
- Apply patches for CVEs as they become available (especially 8929 and 9026)
- Avoid default behaviors in cryptographic functions; explicitly verify key and IV lengths, and document intended behavior
- Ensure proper limits and sanitization on file uploads, including multipart boundary constraints
- Monitor persistent processes for memory pressure and lifecycle leaks
Long-Term Takeaways
This audit demonstrates that even mature and widely used runtimes like PHP benefit from independent, structured reviews. The issues found are not limited to isolated bugs but reflect broader challenges in process isolation, API usability, memory safety, and configuration management.
For organizations using PHP in production — particularly in shared environments or with cryptographic features — this report serves as a call to review assumptions, improve observability, and adopt secure-by-default practices.
The PHP Foundation has already begun addressing several issues raised in the report, and future versions of PHP are expected to integrate many of the suggested improvements.