CVEs: CVE-2026-109618, CVE-2026-109619
Severity: Critical
Executive Summary
Two critical vulnerabilities in the PHP runtime, tracked as CVE-2026-109618 and CVE-2026-109619 and collectively dubbed PHP2Shell, could allow unauthenticated attackers to execute arbitrary code on vulnerable web servers, including systems hosting WordPress, Drupal, and Joomla applications. Security researchers have reported exploitation attempts surrounding the October 21 emergency security release, including activity observed before public disclosure, while VulnCheck documented automated scanning and an unsuccessful attempt to deploy a web shell through PHP session-handling functionality. With millions of internet-facing PHP deployments potentially exposed and a substantial proportion running unsupported versions, organizations face an urgent need to remediate vulnerable systems and investigate suspicious activity preceding the security release.
Key Takeaways
- Critical PHP vulnerabilities CVE-2026-109618 and CVE-2026-109619 affect PHP memory handling and can enable unauthenticated remote code execution, with both receiving CVSS v4.0 scores of 9.2.
- Security researchers reported attempts preceding public disclosure, while VulnCheck documented PHP2Shell scanning and an unsuccessful web shell deployment attempt from a China-based IP address on October 21.
- VulnCheck identified approximately 2.6 million internet-facing PHP hosts, including more than 1.1 million running end-of-life branches without official patched releases.
- PHP released versions 8.2.35, 8.3.36, 8.4.27, and 8.5.12, although organizations using unsupported branches face additional remediation challenges.
Background
On October 21, 2026, the PHP development team released emergency security updates addressing two critical vulnerabilities in the language's core runtime. The flaws, collectively known as PHP2Shell, affect memory management during request initialization, error handling, and cleanup, potentially allowing unauthenticated attackers to execute arbitrary code or disclose sensitive information from affected servers.
The vulnerabilities were identified through independent AI-assisted security research conducted by Calif and Wiz, followed by coordinated disclosure and remediation efforts involving the PHP security team and other industry participants. Although emergency patches were scheduled for October 21, technical details leaked ahead of their release, creating a period during which potential attackers had access to vulnerability information before official fixes became available. Subsequent reporting also revealed that Amazon had observed an attempted exploit against a decoy system on October 17, indicating that suspicious activity preceded public disclosure.
Recorded Future reported that Patchstack received notifications of multiple exploitation incidents from hosting partners before the security release, while Cloudflare also observed early attacks targeting the vulnerabilities. These reports indicate that PHP2Shell attracted attacker interest before organizations had an opportunity to deploy official patches, although the available evidence does not establish widespread successful compromise.
VulnCheck subsequently documented scanning and attempted exploitation through its Canary Intelligence infrastructure. Observed activity included automated HTTP requests designed to identify potentially vulnerable PHP installations, multipart file uploads targeting PHP's session upload-progress functionality, and an unsuccessful attempt to deploy a web shell through a server-side session file.
The potential attack surface extends across applications that depend on PHP, including WordPress, Drupal, Joomla, Laravel, and Magento. Because the vulnerabilities originate in the PHP runtime rather than the applications themselves, secure application code does not necessarily prevent exploitation. VulnCheck identified 2,608,039 internet-facing PHP hosts, including approximately 1.1 million running unsupported PHP branches, underscoring the challenges organizations face in remediating legacy deployments.
The disclosure also prompted precautionary service disruptions as organizations moved to limit exposure while applying security updates. Government agencies, healthcare providers, educational institutions, and online platforms temporarily suspended services, while gaming platforms were also affected. Square Enix confirmed that Final Fantasy XIV temporarily disabled new logins across all worlds while securing its patch servers, illustrating how vulnerabilities in widely deployed infrastructure can disrupt services even without confirmed compromises.
Technical Analysis
PHP2Shell Vulnerability Mechanisms
Both PHP2Shell vulnerabilities involve memory-safety failures that can occur when PHP encounters abnormal conditions while processing HTTP requests. These conditions can leave internal data structures partially initialized or retain references to memory that has already been released, creating opportunities for memory corruption, information disclosure, and remote code execution.
CVE-2026-109618 - Remote Code Execution via Out-of-Memory Corruption
CVE-2026-109618 arises when an out-of-memory condition interrupts PHP while internal request structures are only partially initialized. During subsequent cleanup, the runtime may treat invalid or freed memory as legitimate data, potentially allowing an attacker to manipulate memory structures and execute arbitrary code.
Wiz demonstrated exploitation involving PHP's session upload-progress unserializer, including unauthenticated remote code execution against WordPress, Drupal, and Joomla. Researchers also identified a related memory-disclosure flaw capable of exposing information from PHP worker memory, including authentication tokens, passwords, API keys, and other sensitive data associated with separate requests.
CVE-2026-109619 - Remote Code Execution via Stale Global State
CVE-2026-109619 involves request-owned internal state that remains accessible after its underlying memory has been freed. When a PHP worker processes a subsequent request, stale references may be accessed before normal initialization resets them, potentially resulting in use-after-free conditions and memory corruption.
Wiz identified exploitation paths involving fatal-error backtraces and OPcache type confusion, demonstrating unauthenticated remote code execution against Drupal and WordPress. These mechanisms illustrate how abnormal request termination can affect subsequent requests or shared runtime state, creating exploitation opportunities beyond the original triggering request.
Exploit Development and Reliability
VulnCheck independently reproduced what it assessed to be both vulnerabilities on October 20 and initially reported successful remote code execution conditions on ARM64 systems and x86 systems without address space layout randomization (ASLR). The researchers cautioned that many publicly available proof-of-concept exploits were unreliable and that the implementations they reviewed did not independently bypass ASLR on x86-64 systems.
Separately, Datadog demonstrated that CVE-2026-109618 could be exploited using a calibrated memory layout without requiring ASLR brute forcing or PHP worker crashes. These findings indicate that exploit reliability depends on the implementation and target environment, and that ASLR should not be treated as sufficient protection against PHP2Shell.
Numerous public GitHub repositories have advertised PHP2Shell proof-of-concept exploits, but their effectiveness varies. Recorded Future highlighted proposed exploits whose underlying cached-pointer theory was subsequently invalidated, emphasizing that publicly available exploit code should not automatically be considered functional.
Observed Scanning and Exploitation Activity
VulnCheck Canary Intelligence recorded PHP2Shell-related activity from multiple source IP addresses on October 21, 2026. Initial scanning began at 08:37 UTC, when one source sent HTTP requests to PHP endpoints using the user-agent string php2shell-scan/109618, followed by multipart POST requests containing uploaded files. A second source exhibited similar behavior beginning at 14:15 UTC, shortly after PHP's emergency security release. The requests appeared designed to exercise the session upload-progress functionality associated with CVE-2026-109618, although the observed uploads did not produce sufficient memory exhaustion to demonstrate successful exploitation.
At 17:22 UTC, VulnCheck recorded a more explicit exploitation attempt originating from a China-based IP address. The attacker submitted a multipart POST request containing PHP code intended to establish a web shell through the PHP_SESSION_UPLOAD_PROGRESS mechanism. The activity was followed by ten HTTP GET requests attempting to retrieve the resulting session file through a file-disclosure path. All retrieval attempts returned HTTP 404 responses, and VulnCheck did not observe successful web shell execution.
Other activity included requests targeting common PHP information endpoints, vulnerability verification paths, and additional PHP2Shell-specific user-agent strings. These observations indicate that both automated vulnerability discovery and attempted exploitation were underway on the day of disclosure, although the available telemetry does not establish whether the sources were connected or operating under a common threat actor. Note that the geographic location of the observed source IP addresses does not establish attacker nationality, organizational affiliation, or state sponsorship.
Internet-Facing Exposure
VulnCheck identified approximately 2.6 million internet-facing hosts running PHP across its monitored population. Of these, roughly 1.47 million advertised versions below the relevant patched releases, while another 1.13 million did not disclose their PHP versions. VulnCheck classified nearly all identified hosts as vulnerable or likely vulnerable based on the limited time available for remediation, but these estimates do not represent independently confirmed exploitable systems. More than 1.1 million identified hosts were running end-of-life PHP branches without official patched releases. This includes substantial populations using PHP 7.4 and older versions, highlighting the persistence of legacy software across publicly accessible infrastructure.
Recorded Future also cited separate exposure measurements from VirusTotal and Modat. VirusTotal identified approximately 5.1 million IP addresses associated with PHP, while Modat observed approximately 4.38 million PHP services across 1.89 million unique hosts. These datasets use different discovery methods and measurement units and should not be interpreted as directly comparable vulnerability counts.
The scale of potentially affected infrastructure is particularly significant because PHP frequently operates behind applications that do not explicitly advertise the underlying runtime. Organizations relying exclusively on HTTP version headers or application inventories may therefore overlook affected systems. Additionally, Linux distributions may backport security fixes without changing publicly reported version strings, complicating efforts to identify vulnerable deployments through external scanning alone.
PolySwarm Analyst Commentary
PHP2Shell illustrates the risks associated with vulnerabilities in foundational software components rather than individual applications. Researchers demonstrated exploitation paths that execute within PHP's request-processing and cleanup routines before application code is reached, potentially bypassing application-level authentication and security controls. As a result, organizations cannot rely on secure application code, updated CMS plugins, or authentication requirements to protect vulnerable PHP runtimes.
The early exploitation activity documented by security researchers suggests that attackers rapidly incorporated vulnerability information into scanning and exploitation workflows. Reports of attempted exploitation before public disclosure further raise concerns about the potential for attacker access to technical information ahead of coordinated releases. However, the distinction between reconnaissance, attempted exploitation, and confirmed compromise remains important. Although researchers have demonstrated working remote code execution techniques, the available reporting does not establish widespread successful exploitation or attribution to a coordinated threat campaign.
The prevalence of unsupported PHP versions further complicates remediation. Organizations maintaining legacy applications may be unable to apply the newly released fixes without upgrading underlying runtimes, replacing dependencies, or obtaining vendor-supported backports. Temporary configuration changes and web application firewall protections may reduce exposure to specific attack paths, but they do not address the underlying memory-safety vulnerabilities. Datadog's research demonstrates that disabling session upload-progress functionality alone is insufficient to eliminate exploitation risk, reinforcing the need for comprehensive patching.
From a defensive perspective, PHP2Shell warrants attention beyond conventional web application monitoring. Exploitation can occur during request initialization or cleanup, potentially leaving limited evidence in application logs. Correlating suspicious multipart requests, PHP memory errors, worker instability, and unexpected process execution may provide additional visibility into exploitation attempts. Successful exploitation does not necessarily cause a worker crash, making the absence of PHP failures an unreliable indicator of safety.
The use of AI-assisted research in identifying and developing exploits for these vulnerabilities also highlights an emerging challenge for vulnerability management. Advanced analysis capabilities can make previously impractical exploitation techniques more accessible, potentially shortening the time between vulnerability discovery and the development of functional exploits. While these capabilities also provide defenders with opportunities to identify and remediate longstanding security weaknesses, PHP2Shell demonstrates the importance of preparing for vulnerabilities that affect widely deployed infrastructure components rather than isolated applications.
PolySwarm analysts are continuing to monitor the situation.
Don’t have a PolySwarm account? Go here to sign up for a free Community plan or subscribe.
Contact us at hivemind@polyswarm.io | Check out our blog | Subscribe to our reports.
