Key Takeaways
- No confirmed exploitation: Although CVE-2026-109618 and CVE-2026-109619 in PHP remain concerning, as of this writing there are no known, confirmed, functional exploits against these items.
- Scanning & failed POCs: Observed activity since vulnerability disclosure remains limited to scanning, fingerprinting, and use of non-working exploits, with no known compromises.
- Long-tail of vulnerable applications: Organizations should work diligently to apply patches as soon as possible to take advantage of the lack of known exploitation or working exploit code. However, many applications with web servers and similar will likely remain vulnerable until their respective vendors patch these items, meaning potential attack surface may remain significant for the foreseeable future.
Summary
On October 20, 2026, information about two purported remote code execution vulnerabilities in PHP core, CVE-2026-109618 and CVE-2026-109619, was published on a forum, prior to official disclosure. Patches were subsequently released on October 21, with multiple purported proof of concept (POC) exploits published shortly thereafter. However, analysis by TRACE and third-parties indicates that POCs either are non-functional or target other vulnerabilities or specific settings, as opposed to the two CVEs at issue. Organizations thus have a window to patch and mitigate prior to widespread exploitation, but this likely will not last long.
Exploitation Activity
Numerous claims of CVE-2026-109618/9 exploitation or for working POC code have been made since details initially leaked on these vulnerabilities. However, no publicly documented working exploit exists as of this writing. Even evidence of potential pre-disclosure leaks of the vulnerabilities appear to have only resulted in exploitation attempts as opposed to successful, working exploits leading to compromise. While activity targeting internet-accessible assets is significant, such activity appears limited to scanning or using non-functional POCs as opposed to actual exploitation.
TRACE still assesses that, given widespread use of PHP and the severity of these vulnerabilities, it remains only a matter of time for working POCs or successful exploitation activity to emerge. Additionally, it may be possible that working exploit code is being used in targeted intrusions, where initial access has not yet been analyzed. Nonetheless, widespread exploitation simply does not exist as of October 22.
Long-Tail Vulnerabilities
PHP remains integral to many web applications. This includes web servers and related items like administrative portals for networking devices or complex enterprise software applications. Organizations such as CheckPoint and Palo Alto Networks have already indicated vulnerabilities exist in some products and applications due to PHP use, and many other organizations will likely follow with similar disclosures.
As a result, organizations running such applications will be unable to directly patch these applications, and will instead need to monitor for vendor updates that fix these items. The implications of this are that many organizations will likely remain vulnerable to some degree for far longer than when patches are directly applied to owned and managed applications.
Additionally, while the vulnerabilities in question exist in PHP versions as old as 5.4.0 (2012), the issued patches only cover the current, maintained version of PHP (8). Many legacy products and applications likely use older versions of PHP, and will remain vulnerable. Organizations and defenders should work to profile software and applications to determine where such legacy instances exist, and apply mitigation strategies where possible.
Immediate Actions and Recommendations
- Scope exposure & identify PHP instances: if not already completed, organizations must determine exposure to these vulnerabilities with an emphasis on remotely or internet-accessible applications and systems. Additionally, organizations should determine PHP versions where possible to determine if patching is a viable option for legacy applications.
- Apply patches as soon as possible: Although no public, working exploit code is currently available and no evidence exists of in the wild exploitation at this time, the nature of these vulnerabilities mean they are of great interest to various types of adversary. Organizations should use this window where entities are attempting to create working exploits to patch devices as soon as they are able.
- Identify third-party applications running vulnerable PHP: PHP is widespread and is built into multiple other systems and applications. Organizations should closely review vendor advisories and updates to identify where these vulnerabilities exist within these applications, and apply vendor patches that address this vulnerability as soon as they are available. This is especially the case for external-facing assets and applications.
- Apply mitigations and compensating controls where patching is not possible: If patching is not possible for whatever reason, organizations should apply mitigation strategies to reduce attack surface. As noted by the PHP Foundation, only the patch completely mitigates the vulnerabilities. However, employing web application firewall (WAF) rules, limiting service exposure, or (in extreme cases) removing access from vulnerable applications entirely may be necessary if patching is not an immediate option or possibility.
2026 Mid-Year Cyber Threat Landscape Report
The first half of 2026 was defined by a widening gap between attack speed and defense speed — and AI is accelerating both sides. Dataminr’s 2026 Cyber Threat Landscape Mid-Year Report pulls from 4,500 threat actors tracked, 73,000 vulnerabilities detected, and over 2 million alerts processed per month to surface what actually mattered in H1 and what teams need to prepare for in H2.
Download Report
