PHP administrators are facing an urgent security update after maintainers announced an out-of-cycle release addressing two critical vulnerabilities. The flaws, tracked by security researchers as CVE-2026-109618 and CVE-2026-109619, have each received a CVSS v4.0 score of 9.2 from the PHP security team. Researchers at watchTowr describe both issues as remote code execution vulnerabilities.
The emergency release is scheduled for October 21, 2026, at 14:00 UTC. PHP moved the disclosure forward after information about the vulnerabilities reportedly leaked ahead of the coordinated release date. At the time of writing, PHP has not disclosed the vulnerable components, exploitation requirements, affected releases, or technical root causes and says those details will accompany the security updates.
Researchers have informally dubbed the vulnerability pair “PHP2Shell,” although this name does not come from the PHP Project. The early leak claimed the flaws could affect PHP releases dating back to PHP 5 and assigned them CVSS 10.0 scores. However, PHP’s official rating is 9.2, and the claimed version range has not yet been confirmed by an official vendor advisory.
The potential impact is nevertheless significant. PHP powers a massive number of websites, web applications, content management systems, e-commerce platforms, APIs, hosting panels, and custom enterprise services. If remote code execution is confirmed across commonly deployed configurations, successful exploitation could give attackers a direct route from an exposed web application to server-level compromise.
Security teams seeking CVE-2026-109618 detection opportunities should prioritize behavior-based monitoring while exploit-specific signatures remain unavailable. Suspicious activity includes PHP or web-server processes unexpectedly launching shells, interpreters, command-line utilities, or download tools.
SOC Prime customers can leverage the AI-Native Detection Intelligence Platform to access continuously updated detection content for vulnerability exploitation and associated post-compromise behavior. Detection rules can be applied across multiple SIEM, EDR, and Data Lake environments and aligned with the MITRE ATT&CK® framework.
Click Explore Detections to access relevant SOC content for emerging vulnerabilities. To Detect CVE-2026-109619 and associated exploitation attempts, defenders should combine behavioral analytics with web-server, endpoint, and network telemetry as technical intelligence becomes available.
Security teams can also use Prime Architect to turn emerging vulnerability intelligence into Sigma rules and custom hunting queries, validate detection logic, visualize potential Attack Flows, and rapidly translate detection content across supported security platforms.
CVE-2026-109618 and CVE-2026-109619 Analysis
On October 20, 2026, the PHP security team issued an advance warning that two critical vulnerabilities would be addressed through an exceptional security release the following day. Both received a CVSS v4.0 rating of 9.2, and administrators were urged to prepare for immediate upgrades. PHP also reserved the option to release fixes earlier if technical information became public or active exploitation was detected.
The announcement followed an information leak concerning two embargoed vulnerabilities. The leaked material identified CVE-2026-109618 and CVE-2026-109619 and characterized both as remote code execution flaws. watchTowr subsequently confirmed to BleepingComputer that the vulnerabilities are real and said its researchers believe they successfully reproduced one of them.
However, there are important differences between the leaked information and what PHP has officially confirmed.
PHP assigned both vulnerabilities a CVSS v4.0 score of 9.2 rather than the CVSS 10.0 rating circulated in the leak. PHP has also not confirmed which branches are vulnerable, whether exploitation requires a particular PHP deployment model or configuration, or whether authentication is necessary.
The claim that CVE-2026-109618 affects PHP versions 5, 6, 7, and 8 comes from researcher and leaked information rather than PHP’s official advisory. watchTowr itself notes that this scope has not yet been confirmed by the vendor.
A careful CVE-2026-109618 analysis therefore needs to separate confirmed facts from preliminary research. What is currently confirmed is that PHP considers two vulnerabilities critical, rates both at 9.2, and believes the risk warrants an emergency out-of-cycle security release. Researchers characterize the flaws as RCE vulnerabilities, but their underlying mechanisms remain embargoed.
This distinction also matters when assessing legacy PHP environments. The PHP Project currently provides security updates only for supported branches 8.2 through 8.5. PHP 8.2 and 8.3 are receiving security fixes, while 8.4 and 8.5 remain under active support. Older branches, including PHP 8.1, 8.0, PHP 7.x, and PHP 5.x, are end of life and will not receive upstream patches if they ultimately prove vulnerable.
This could create a particularly challenging remediation scenario for organizations operating old applications that cannot easily be migrated. Internet-facing legacy PHP systems would represent a significant concern if the reported broad version exposure is confirmed.
No public CVE-2026-109618 PoC is available at the time of writing. watchTowr says it believes it successfully reproduced the issue but is intentionally withholding technical information until security patches become available. Huntress had also not reproduced the vulnerabilities and was unaware of publicly available exploit code.
No active exploitation had been observed by the researchers cited in either report as of October 21. The vulnerabilities were also not listed in CISA’s Known Exploited Vulnerabilities catalog at the time of The Hacker News report.
Consequently, CVE-2026-109619 IOCs have not yet been published. There are currently no confirmed malicious IP addresses, domains, payload hashes, exploit request patterns, or other campaign-specific indicators directly associated with exploitation of this vulnerability.
Until exploit details become available, defenders should instead monitor for generic signs of PHP server compromise. High-value behaviors include php-fpm, php-cgi, httpd, or apache2 spawning shells, scripting engines, download utilities, or other unexpected executables. New web shells, unexplained modifications in the web root, cron jobs, scheduled tasks, newly created accounts, and anomalous outbound connections should also trigger investigation.
The precise details for CVE-2026-109619 are expected to clarify the vulnerable PHP component, attack prerequisites, affected branches, configuration dependencies, and fixed versions once PHP publishes the security release.
CVE-2026-109618 and CVE-2026-109619 Mitigation
PHP administrators should first build an accurate inventory of every PHP deployment in the environment. This includes conventional Linux and Windows web servers as well as PHP runtimes embedded in appliances, third-party applications, hosting platforms, and administration products such as cPanel or Plesk.
For immediate CVE-2026-109619 mitigation, organizations should prepare to deploy PHP’s emergency security update as soon as the patched releases become available. Internet-facing applications should receive the highest priority because remotely reachable systems typically present the greatest opportunity for exploitation.
Organizations using distribution-supplied PHP packages should check their Linux vendor or hosting provider for backported security updates rather than assuming the upstream PHP version number alone determines exposure.
Legacy PHP installations require special attention. If a vulnerable application runs an end-of-life PHP release for which no official patch becomes available, organizations should prioritize migration to a supported branch. Where immediate migration is impossible, exposure should be reduced by restricting external access, placing the application behind appropriate network controls, or temporarily isolating the system.
CERT-EU guidance referenced by The Hacker News recommends considering isolation of internet-facing applications from public networks when a fix cannot immediately be applied.
Defenders should additionally strengthen monitoring around PHP execution. Alert when PHP workers or web-server processes spawn utilities such as shells, PowerShell, Bash, Python, Perl, curl, wget, or other programs that are unexpected for the application.
If exploitation is suspected, isolate the affected server and preserve evidence before remediation. Relevant artifacts include:
- Web-server access and error logs
- PHP application and runtime logs
- Endpoint and process telemetry
- Recently created or modified files
- Web-root content
- Cron jobs and scheduled tasks
- Newly created accounts or SSH keys
- Outbound network connections
- Authentication and administrative activity
Security teams should also hunt retrospectively after technical indicators are released. If exploit-specific HTTP request patterns or payload characteristics become public, historical web and proxy telemetry could identify compromise attempts that occurred before patches were applied.
Organizations should avoid relying solely on a WAF as a permanent substitute for patching. Until the technical root causes are disclosed, there is no confirmed generic WAF rule that can reliably block both vulnerabilities without knowing their exploitation mechanisms.
By leveraging SOC Prime’s AI-Native Detection Intelligence Platform, security teams can continuously strengthen their detection posture as new intelligence on these PHP vulnerabilities emerges.
Disclaimer: Detection content may not be available for every CVE. Check the SOC Prime Platform for current coverage. If relevant detections are not available yet, check back as new threat intelligence and detection content are continuously added.
FAQ
What are CVE-2026-109618 and CVE-2026-109619 and how does it work?
CVE-2026-109618 and CVE-2026-109619 are two critical PHP vulnerabilities that researchers at watchTowr describe as remote code execution flaws. PHP has officially confirmed two critical issues with CVSS v4.0 scores of 9.2 but has not yet disclosed their technical root causes or exploitation mechanisms. At the time of writing, it is therefore not possible to reliably describe the exact attack flow. PHP is expected to publish the technical information with its emergency security release.
When were CVE-2026-109618 and CVE-2026-109619 first discovered?
Information about the vulnerabilities became public on October 20, 2026, after details of two embargoed PHP vulnerabilities reportedly leaked ahead of their planned disclosure. PHP issued its official advance warning later that day and scheduled an emergency security release for October 21, 2026, at 14:00 UTC.
What is the impact of CVE-2026-109618 and CVE-2026-109619 on systems?
Security researchers characterize both vulnerabilities as remote code execution issues. If that assessment is confirmed by PHP, successful exploitation could potentially enable an attacker to execute code on a vulnerable PHP server and proceed with malware deployment, credential theft, persistence, lateral movement, or data access depending on the privileges of the affected service. PHP has not yet published the precise exploitation conditions, so the exact impact and prerequisites remain subject to the forthcoming vendor advisory.
Can CVE-2026-109618 and CVE-2026-109619 still affect me in 2026?
Yes. At the time of writing on October 21, 2026, the emergency security release is scheduled for 14:00 UTC and the vulnerabilities remain unpatched in currently deployed releases. Researchers have claimed that PHP versions dating back to PHP 5 may be affected, but PHP has not officially confirmed this version range. Organizations should inventory all deployments and use the forthcoming vendor advisory to determine actual exposure.
How can I protect myself from CVE-2026-109618 and CVE-2026-109619?
Prepare to install the PHP security updates immediately when they are released, prioritizing internet-facing servers. Inventory PHP installations, including runtimes bundled with applications and appliances, and identify systems running end-of-life branches. Until fixes are deployed, increase monitoring for unusual PHP child processes and server-side command execution. Systems that cannot be patched promptly should have external exposure reduced or, where operationally possible, be temporarily isolated. If suspicious activity is found, isolate the server and preserve web, PHP, endpoint, and network telemetry for forensic investigation.