Two critical vulnerabilities in PHP are a timely reminder that vulnerabilities in foundational software components can create risk far beyond the applications where they are first discovered.
On October 21, the PHP security team released fixes for CVE-2026-109618 and CVE-2026-109619, two vulnerabilities rated CVSS 9.2 that can lead to unauthenticated remote code execution. The PHP project strongly recommends that users update immediately.
The vulnerabilities are particularly significant because they exist in the PHP engine itself. That means an application’s own code does not have to contain the vulnerability for it to potentially be exposed.
What happened?
According to the PHP security advisory, the vulnerabilities affect PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The PHP team considers the risk particularly high for mod_php, where unauthenticated exploitation has been demonstrated before application code executes.
The two vulnerabilities involve different paths to remote code execution:
- CVE-2026-109618 involves out-of-memory handling that can leave internal request data partially initialized and potentially cause invalid data to be treated as valid.
- CVE-2026-109619 involves internal state that can persist after its underlying memory has been freed, potentially allowing a subsequent request to use that stale state.
Security researchers have dubbed the combined attack technique PHP2Shell. Sansec reports that the vulnerabilities affect unpatched PHP versions dating back to PHP 5.4. Importantly, however, the research also suggests that exploitation is more conditional than vulnerabilities such as Log4Shell: known attacks require knowledge of the target environment and specific conditions, and public proofs of concept do not work against a default PHP installation.
That should not be interpreted as a reason to wait.
Identifying and Patching remains the priority
PHP has released 8.2.35, 8.3.36, 8.4.27 and 8.5.12 with fixes for the vulnerabilities. PHP 8.1 and earlier are no longer supported by the PHP project, although source patches and some vendor backports are available for older releases. The PHP team is clear that mitigations are not a complete solution and recommends updating. For organizations consuming PHP through a Linux distribution, there is another consideration: availability of the appropriate patched package from the operating-system vendor.
The broader lesson: know what’s inside your software
Incidents like PHP2Shell illustrate why visibility into software composition matters.
A vulnerability in a widely used underlying component can quickly create questions across a large portfolio of applications:
- Where is the affected component being used?
- Which products and versions are actually exposed?
- Is there a vendor or distribution-specific patch available?
- Which systems should be prioritized?
- How do we demonstrate that remediation has taken place?
Answering those questions requires more than monitoring a vulnerability feed. Organizations need an accurate understanding of the open source and third-party components incorporated into their products and the ability to connect new vulnerability intelligence to those components.
Revenera SCA
Software Composition Analysis (SCA) solutions from Revenera help you discover, assess, and manage license and security risk across all your software applications.
That is where software composition analysis and SBOM practices become especially important. When a critical vulnerability is disclosed, teams should be able to move quickly from “there is a new PHP vulnerability” to “these are the products and versions we need to investigate.”
The PHP disclosure also reinforces another important point: vulnerability severity alone does not tell the entire story. Sansec’s analysis indicates that current exploitation requires specific target conditions, even though both vulnerabilities carry a critical CVSS rating. Understanding both component exposure and exploitability in context gives security teams a much stronger basis for prioritizing remediation.
What teams should do now
- Identify PHP in your software environment, including PHP delivered through operating-system or third-party packages.
- Determine which versions and distributions are affected.
- Check your platform or Linux distribution for the relevant security update.
- Apply the patched package as soon as it becomes available and verify that the update contains the CVE fixes.
- Use your SCA and SBOM data to identify other products containing affected PHP versions and prioritize investigation based on actual exposure.
The PHP project also documents temporary mitigations for organizations that cannot update immediately, but emphasizes that these only reduce specific attack paths and do not provide complete protection.
The takeaway is simple: critical vulnerabilities in foundational components can emerge quickly. Knowing where those components exist, understanding the context in which they are deployed, and having a reliable path from disclosure to remediation are essential parts of managing software supply chain risk.
