Two critical remote code execution (RCE) vulnerabilities, CVE-2026-109618 and CVE-2026-109619, were disclosed in PHP, a widely used server-side programming language that powers websites and web applications, including WordPress, Drupal, and Joomla. [2][3]
Collectively known as PHP2Shell, these vulnerabilities were discovered by researchers from Calif, OpenAI, and Wiz. Both carry a critical CVSS v4.0 score of 9.2 and can allow unauthenticated attackers to execute code on vulnerable servers. Exploitability depends on the PHP version, configuration, and application behavior. [2][3]
Depending on process permissions and access to connected resources, a successful compromise could allow attackers to:
Targets and Impact:
PHP-based services across sectors may be affected. Government websites in several European countries were reportedly taken offline as a precaution following disclosure. These protective shutdowns do not establish successful compromise. [1] Successful exploitation can expose sensitive information or compromise application integrity. Unit 42 subsequently confirmed exploitation against internet-exposed PAN-OS management interfaces in its October 29 update; this finding does not establish widespread compromise across PHP deployments. [3][11]
Recommended Actions:
Organizations should identify affected PHP installations, apply security updates, and investigate exposed systems for evidence of compromise. Web application firewall protections can reduce risk while updates are applied but do not replace patching. Assess potentially exposed passwords, API keys, authentication tokens, and session data; rotate or revoke affected secrets and invalidate sessions where warranted by the investigation. [3][8][17]
On October 21, 2026, the PHP project released emergency security updates for two critical remote code execution vulnerabilities, CVE-2026-109618 and CVE-2026-109619, collectively known as PHP2Shell. Both carry a CVSS v4.0 score of 9.2 and can allow unauthenticated attackers to execute code on vulnerable servers. The underlying weaknesses had existed for more than a decade, with affected releases dating back to PHP 5.4. Their disclosure brought renewed attention to longstanding memory-safety issues in software used across the web. [2][3]
PHP (a recursive acronym for PHP: Hypertext Preprocessor) is an open-source, server-side programming language used primarily for web development. It serves as a foundational piece of the internet's "invisible digital infrastructure," running behind the scenes on a web server to assemble and deliver dynamic content to web browsers. According to W3Techs, PHP was used by 69.1% of websites whose server-side programming language it could identify as of November 4, 2026. This adoption estimate does not measure exposure to or compromise through PHP2Shell. [4] PHP supports various websites and applications, including WordPress, Drupal, and Joomla. PHP2Shell affects the PHP engine itself, meaning applications may be exposed even when their own code does not contain a security flaw. Wiz demonstrated unauthenticated code execution against deployments of all three platforms, as well as a separate ability to read sensitive PHP process memory. Exploitability depends on the PHP version, configuration, and application behavior. [3]
The vulnerabilities involve PHP’s handling of memory and error state. CVE-2026-109618 can leave partially initialized internal data in an unsafe state following an out-of-memory error. CVE-2026-109619 can leave internal references pointing to memory released after an earlier request. Reusing this invalid state can lead to memory corruption and code execution. On affected Apache deployments using mod_php, attacks were demonstrated before application code runs, limiting the protection provided by application-level authentication. [2]
PHP developers identified signs of the out-of-memory problem in 2024, but remediation stalled amid compatibility concerns, competing technical approaches, and limited resources. Calif reported a working remote code execution attack on August 11, 2026, while OpenAI and Wiz also reported findings and additional attack paths. [2] Wiz described using AI tools to help analyze the weaknesses, test changes, and adapt exploits across applications, reducing the specialist effort required. [3]
The coordinated disclosure was disrupted on October 20, when the vulnerability identifiers circulated publicly ahead of the planned release. A mistakenly published demonstration video subsequently revealed additional information. The PHP project moved the security release forward from October 22 to October 21. [2] Separately, Amazon Threat Intelligence identified an exploitation attempt against its MadPot honeypot infrastructure dating to October 17 and observed further attempts as proof-of-concept exploits circulated. Amazon cautioned that it remained unclear whether the observed attempts would have succeeded against real-world systems. [5] These findings establish active targeting before public disclosure, rather than confirmed widespread compromise.
Technical Details
CVE-2026-109618: Remote Code Execution Through Out-of-Memory Corruption
PHP can encounter an out-of-memory error while preparing or processing a web request. Its error-handling mechanism can abruptly exit an operation before internal request data has been fully initialized, leaving that data in an invalid state. During request shutdown, PHP may read or act on this invalid data. Carefully crafted HTTP requests can exploit this behavior to corrupt memory and achieve unauthenticated remote code execution under exploitable conditions. [6][8]
On Apache with mod_php, the demonstrated attack can occur during automatic request-body parsing, before application code runs. PHP-FPM handles failed request startup differently. PHP’s advisory identifies susceptibility through later, application-dependent processing but does not report a complete demonstrated PHP-FPM exploit for this vulnerability. [6]
CVE-2026-109619: Remote Code Execution Through Stale Global State
A persistent PHP worker can retain internal state referencing memory allocated for an individual request. A fatal interruption can prevent that reference from being reset. Nonfatal diagnostics can also recreate request-owned error state after cleanup has cleared it. Consequently, the worker may retain a reference after the underlying request memory has been freed. [7]
Successful exploitation requires a reachable operation that leaves the reference behind, called the producer, and another operation that later acts on it, called the consumer. In the demonstrated cross-request paths, both requests must be handled by the same worker, and the consumer must access the freed memory before normal initialization resets the reference. With suitable memory manipulation, this use-after-free can lead to remote code execution. Exploitability depends on the reachable operations, PHP version, and configuration; it is not an automatic result of every warning or fatal error. [7]
PHP2Shell threatens the confidentiality, integrity, and availability of vulnerable PHP deployments. Researchers have demonstrated unauthenticated remote code execution and sensitive process-memory disclosure. Public reporting also documents exploitation attempts, attacker preparation, and precautionary service shutdowns. However, the overall extent of successful compromise remains uncertain, and exposure estimates should not be interpreted as confirmed victim counts.
Amazon Threat Intelligence identified an exploitation attempt against its MadPot honeypot infrastructure dating to October 17, four days before PHP released security updates. Amazon subsequently observed additional attempts as proof-of-concept exploits circulated. [5] Separately, watchTowr reported exploitation activity through its Attacker Eye honeypot network. [9] These observations demonstrate active targeting but do not independently establish successful compromise of production systems.
Sophos also observed attempts to deploy Potassium, a Mirai-derived botnet payload. On October 22, Sophos corrected an earlier successful-exploitation assessment, stating that its customer telemetry showed scanning and failed attempts. The payload was blocked and was not delivered. [10] The activity demonstrates an attacker objective of recruiting vulnerable systems into botnet infrastructure, rather than a confirmed successful PHP2Shell infection.
In an October 29 update, Unit 42 confirmed exploitation targeting internet-exposed PAN-OS management interfaces. Attackers chained PHP2Shell with a Linux kernel privilege-escalation vulnerability to gain root access. This demonstrates successful exploitation in a specific deployment context rather than widespread compromise across PHP applications. [11]
SOCRadar identified PHP2Shell exploit tooling on an exposed attacker-controlled server, alongside scripts that screened websites for PHP versions, server behavior, and other exploitation requirements. Its investigation found no evidence of shell access on the screened sites as of October 22. [12] This establishes attacker preparation and reconnaissance rather than successful compromise.
The practical difficulty of exploitation is important when assessing impact. In its October 22 update, Sansec revised its initial assessment, stating that mass exploitation was less likely than first expected because attacks required target-specific knowledge and conditions. It reported limitations in the public proof-of-concept exploits it discussed, including dependencies on additional application weaknesses. [13] This assessment should not be generalized to every possible exploit variant.
Datadog independently reproduced exploitation and explained that reliable command execution requires valid memory addresses. Address space layout randomization complicates this requirement, while memory disclosure can supply information that improves reliability. [8] Exploitation constraints therefore affect the likelihood of compromise but do not eliminate the demonstrated technical risk.
The vulnerabilities exist in PHP’s core engine rather than in a single application, plugin, or theme. A deployment may therefore be exposed even when its application code is secure. Wiz demonstrated exploitation against WordPress, Drupal, and Joomla deployments. [3] Sansec also highlighted the relevance to PHP-based e-commerce platforms. [13] These examples illustrate potential exposure across different applications rather than equal exploitability across every installation.
The scope also extends beyond conventional websites. Datadog recommends including containers and applications that bundle their own PHP interpreter when assessing exposure. [8] Managed hosting and vendor-provided products can therefore introduce dependencies that are not apparent from an organization’s main web server inventory. Product-specific impact must be established from the relevant vendor advisory.
Unit 42 reported more than 22.6 million exposed instances potentially vulnerable according to Cortex Xpanse telemetry. [11] This is an exposure estimate, not a count of compromised systems, unique organizations, or deployments individually confirmed to be exploitable.
Successful exploitation can allow an unauthenticated attacker to execute code with the privileges of the web server or PHP worker account. [14] This does not automatically provide root or administrator access. The attacker’s capabilities depend on filesystem permissions, process isolation, available credentials, and access to connected resources.
Wiz separately demonstrated disclosure of sensitive PHP process memory, including passwords, authentication tokens, and API keys, without first requiring remote code execution. [3] The information exposed depends on the contents of the affected process’s memory.
Depending on the application account’s permissions, code execution could also allow an attacker to read configuration files and stored secrets, modify application files or database records, introduce malicious content, or install a web shell for continued access. Stolen credentials could potentially enable account impersonation or access to connected databases, cloud services, and internal applications. These are potential consequences rather than outcomes established across all PHP2Shell attacks. Further access depends on credential privileges and network connectivity; exploitation alone does not establish unrestricted access to the organization’s network.
Availability can be affected by technical failures and by protective action. PHP’s disclosures describe memory-handling failures and worker crashes. [2] Emergency updates, process restarts, and temporary isolation can also interrupt otherwise functioning services.
The Wikimedia Foundation provides a documented example of operational disruption. Beginning October 20, it took Wikimedia Cloud Services and other supporting services offline as a precaution. Affected infrastructure included community tools, Phabricator, documentation services, and continuous integration services. [15] Wikimedia also acknowledged wiki outages during its response. [16] These statements describe protective shutdowns and remediation activity rather than attributing the outages to a successful attack.
For organizations operating online stores, public portals, or internal applications, similar interruptions could delay transactions, restrict access to information, or disrupt staff workflows. Business impact depends on the affected service, outage duration, and available alternatives.
Response may require emergency maintenance, application compatibility testing, coordination with service providers, and verification that every affected runtime has been updated. Shared environments can complicate restoration: Wikimedia explained that independently maintained instances prevented it from centrally guaranteeing that all affected services were patched. [15]
Older PHP deployments can create additional work. Source backports exist for PHP 7.4, 8.0, and 8.1, and some distributors provide patched packages for older versions. Availability depends on the package source and vendor support. [13][8] Legacy or unmanaged systems may remain exposed where ownership or patch coverage is unclear.
Patching addresses the vulnerabilities but does not remove changes an attacker may already have made. Installed backdoors, modified files, or stolen credentials could remain relevant after updating. The UK NCSC advises assessing exposed systems for evidence of compromise and attacker-installed backdoors. [17] Potential response costs include investigation, restoration, and replacement of potentially exposed secrets.
The reviewed sources do not establish a reliable total of successfully compromised organizations, stolen records, or financial losses. Honeypot activity, reconnaissance, failed exploitation, vendor-reported incidents, exposure measurements, and precautionary shutdowns represent different forms of evidence.
The available findings support an urgent response to a serious vulnerability. They do not support claims that PHP2Shell compromised or took down a fixed proportion of the internet.
The following table maps documented PHP2Shell exploitation attempts and relevant detection coverage to MITRE ATT&CK techniques. Observed requests included attempts to execute commands, identify the executing account and operating system, and download additional payloads. Request content demonstrates intended behavior but does not, by itself, confirm successful exploitation or execution. [19] Detection coverage is identified separately from observed activity. [18]
Table 1. MITRE ATT&CK Technique Mapping
|
TACTIC |
TECHNIQUE |
MITRE ATT&CK ID |
DESCRIPTION |
|
Initial Access |
Exploit Public-Facing Application |
T1190
|
Attempts targeted PHP request-processing vulnerabilities using crafted HTTP requests. Arctic Wolf observed multipart requests and exploitation-validation payloads, while Splunk provides detection coverage for related suspicious request patterns. Not every PHP2Shell-themed request necessarily targets the underlying CVEs. [18][19] |
|
Execution |
Unix Shell |
T1059.004 |
Splunk provides detection coverage for web or application servers spawning shells. This represents behavior to investigate following possible exploitation, rather than confirmation that a shell executed in a particular PHP2Shell incident. [18] |
|
Discovery |
System Owner/User Discovery |
T1033 |
Arctic Wolf observed payloads attempting to run the id command to identify the PHP worker’s executing account. The presence of this command in a request does not establish successful execution. [19] |
|
Discovery |
System Information Discovery |
T1082 |
Arctic Wolf observed payloads attempting to run uname -a and PHP system-information checks to identify the operating system or hostname. These observations establish attempted discovery. [19] |
|
Command and Control |
Ingress Tool Transfer |
T1105 |
Arctic Wolf observed command sequences attempting to retrieve additional files using wget. Its available telemetry did not establish that the associated malware samples were downloaded or executed. [19] |
|
Persistence |
Server Software Component: Web Shell |
T1505.003 |
Potential post-exploitation behavior. Splunk provides detection coverage for suspicious child processes spawned by web servers that may indicate web-shell activity. A suspicious child process alone does not confirm web-shell installation or persistence through PHP2Shell. [18] |
PHP2Shell involves critical vulnerabilities in the PHP runtime that can allow unauthenticated remote code execution and disclosure of sensitive process memory. If exploitation is suspected, security teams should preserve and review web-server access and error logs, PHP application and runtime logs, and endpoint telemetry for suspicious requests, memory errors, unexpected process execution, and file changes. [5][8] Wiz published detection patterns associated with the vulnerabilities. [3] Amazon Threat Intelligence identified exploitation attempts in its MadPot honeypot network beginning October 17, 2026. [5]
Table 2. Reported Indicators of Compromise for PHP2Shell
|
Indicator |
Data |
Description |
|
IP Address |
103[.]216[.]220[.]92 |
Source IP observed by AWS on October 17, 2026. [5] |
|
IP Address |
31[.]223[.]184[.]166 |
Source IP observed by AWS on October 21, 2026. [5] |
|
IP Address |
37[.]19[.]200[.]5 |
Source IP observed by AWS on October 21, 2026. [5] |
|
IP Address |
134[.]209[.]159[.]64 |
Source IP observed by AWS on October 21, 2026. [5] |
|
IP Address |
103[.]114[.]163[.]188 |
Source IP observed by AWS on October 21, 2026. [5] |
|
IP Address |
95[.]217[.]98[.]37 |
Source IP observed by AWS on October 21, 2026. [5] |
|
HTTP Request Pattern |
PHP_SESSION_UPLOAD_PROGRESS |
Legitimate PHP functionality also present in suspicious multipart POST requests. Requires correlation with other evidence. [5] |
|
IP Address |
92[.]118[.]112[.]100
|
Payload-hosting infrastructure referenced in attempted downloads. [19] |
|
IP Address |
45[.]198[.]224[.]169
|
Listed in Arctic Wolf’s indicator set; specific role and observation date are not stated. [19] |
|
IP Address |
5[.]175[.]189[.]76
|
Listed in Arctic Wolf’s indicator set; specific role and observation date are not stated. [19] |
|
User Agent |
Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/130.0.0.0 Safari/537.36
|
Reported in associated activity; common browser identifier with low standalone detection value. [19] |
|
URL |
hxxp://92.118.112[.]100/mountpoint
|
Reported payload-hosting URL. [19] |
|
URL |
hxxp://92.118.112[.]100/nfs-setup
|
Download URL appearing in an observed exploitation attempt. [19] |
|
SHA-256 |
0c5486f06620e26e316f4b33f318b0d646d5e1133789331aa2fed012360d1486
|
Reported Potassium-associated malware sample; exact filename and hash-to-file mapping are not specified. [10][19] |
|
SHA-256 |
e2529d4afa39ae4db2eb05d5176317c906289abf09660c75bdeec43e54c55aa3
|
Reported Potassium-associated malware sample; exact filename and hash-to-file mapping are not specified. [19] |
Sources: AWS-reported indicators are cited as [5]. Additional infrastructure and malware indicators are cited as [10] and [19]. Arctic Wolf’s report was published on October 22, 2026; exact observation dates are not specified for every listed indicator. Its telemetry did not establish that the observed requests downloaded or executed the associated malware samples. [19] Indicator matches require investigation and do not independently confirm compromise.
Additional Detection and Monitoring Opportunities
Security teams can review the following patterns when investigating possible PHP2Shell exploitation. These are investigation leads rather than standalone proof of compromise and should be correlated with request details, PHP configuration, and endpoint activity. The post-exploitation checks are broader monitoring opportunities, not evidence that these behaviors occurred in every PHP2Shell incident.
|
Indicator |
Data |
Description |
|
HTTP Requests |
Unusual multipart requests |
Investigate unusual multipart requests followed by memory-limit errors or repeated HTTP 500 responses. These events alone do not establish successful exploitation. [3] |
|
HTTP Response Cookies |
PHPSESSID |
Check for unexpectedly large or malformed PHP session response cookies that may indicate memory disclosure attempts. [3] |
|
PHP Worker Activity |
Unexpected PHP worker failures or restarts |
Review unexplained PHP worker churn, especially alongside unusual requests or memory errors. [3] |
|
Process Execution |
php-fpm, php-cgi, httpd, apache2
|
Monitor PHP and web server processes for unexpected child processes, including shells or interpreters. Investigate process ancestry, command lines, and the executing account. [8][18]. |
|
Command Execution |
sh, bash, cmd.exe, powershell.exe, curl, wget |
Investigate unexpected shell execution or download-tool activity associated with PHP or web server processes. Account for the server’s operating system and legitimate application behavior. [11][18] |
|
File Activity |
Unexpected files or changes in application directories
|
Review unexplained file modifications and investigate suspected web shells or other unauthorized files. [5][17] |
|
Persistence Activity |
Unexpected cron jobs, scheduled tasks, or user accounts |
Investigate unauthorized persistence changes. These are general post-exploitation checks and are not specific proof of PHP2Shell exploitation. [11] |
|
Behavioral Detection |
Web-server, endpoint, and network telemetry
|
Correlate suspicious requests and PHP errors with process execution, network connections, and file changes. Validate the affected PHP version and configuration before drawing conclusions. [8][18] |
The AWS-reported IP addresses include shared anonymization infrastructure that may also be used for unrelated traffic. Any matches should be reviewed with the available HTTP requests, PHP version information, server logs, and endpoint activity. AWS recommends investigating connections involving these addresses and provides additional guidance for identifying suspicious process execution and file changes [5].
1. Upgrade PHP to a Patched Release
2. Identify and Restrict Exposed Systems
3. Investigate Potential Compromise
4. Review and Rotate Potentially Exposed Credentials
[1] eBuilder Security. “PHP2Shell Forces Government Websites Offline Across Europe.” https://ebuildersecurity.se/en/cyber-news/php2shell-government-websites-offline-europe/
[2] The PHP Foundation. “Today’s PHP Security Release, and How We’re Strengthening PHP Security.” https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/
[3] Wiz Research. “PHP2Shell: AI Uncovers Critical RCE Vulnerabilities Affecting 70% of the Internet.” https://www.wiz.io/blog/php2shell-php-rce
[4] W3Techs. “Usage Statistics of PHP for Websites.” Accessed November 4, 2026. https://w3techs.com/technologies/details/pl-php
[5] Amazon Threat Intelligence. “Amazon Threat Intelligence Identifies PHP2Shell Exploitation Prior to Public Disclosure in MadPot.” https://aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/
[6] PHP Project. “RCE via OOM Corruption.” GitHub Security Advisory GHSA-w8hw-w9fx-j79w, CVE-2026-109618. https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w
[7] PHP Project. “RCE via Stale Global State.” GitHub Security Advisory GHSA-6wmf-4rv5-p3rp, CVE-2026-109619. https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp
[8] Datadog Security Labs. “PHP2Shell: Critical Vulnerabilities in PHP (CVE-2026-109618, CVE-2026-109619): Detection, Analysis, and Remediation.” https://securitylabs.datadoghq.com/articles/php2shell-critical-vulnerabilities-in-php/
[9] watchTowr. “Frequently Asked Questions About PHP Remote Code Execution (PHP2Shell CVE-2026-109618 and CVE-2026-109619).” https://watchtowr.com/intelligence/php-cve-2026-109618-faq/
[10] Sophos. “Proof-of-Concept Exploit Released for PHP Vulnerabilities (CVE-2026-109618, CVE-2026-109619).” https://www.sophos.com/en-us/blog/proof-of-concept-exploit-released-for-php-vulnerabilities-109618-109619
[11] Palo Alto Networks Unit 42. “Threat Brief: Critical Vulnerabilities in PHP: CVE-2026-109618, CVE-2026-109619.” Updated October 29, 2026. https://unit42.paloaltonetworks.com/cve-2026-109618-cve-2026-109619/
[12] SOCRadar. “PHP2Shell Exploit Tooling Found on Exposed Attacker Server.” https://socradar.io/blog/php2shell-exploit-tooling-attacker-server/
[13] Sansec. “PHP2Shell: PHP RCE (CVE-2026-109618, CVE-2026-109619).” https://sansec.io/research/php2shell
[14] Sophos. “Advisory: PHP2Shell Vulnerabilities (CVE-2026-109618, CVE-2026-109619).” https://www.sophos.com/en-us/security-advisories/sophos-sa-20261021-php2shell
[15] Wikimedia Foundation. “Impact of PHP Vulnerabilities on Wikimedia Cloud Services.” https://diff.wikimedia.org/2026/10/21/impact-of-php-vulnerabilities-on-wikimedia-cloud-services/
[16] Wikimedia Foundation. “Impact of PHP Vulnerabilities on Wikimedia Tools and Services.” https://diff.wikimedia.org/2026/10/21/impact-of-php-vulnerabilities-on-wikimedia-tools-and-services/
[17] UK National Cyber Security Centre. “Critical Security Issue Affecting PHP.” https://www.ncsc.gov.uk/news/critical-security-issue-affecting-php
[18] Splunk Threat Research Team. “PHP2Shell.” https://research.splunk.com/stories/php2shell/
[19] Arctic Wolf. “PHP2Shell: Critical PHP Vulnerabilities Enable Unauthenticated Remote Code Execution.” https://arcticwolf.com/resources/blog/php2shell-critical-php-vulnerabilities-enable-unauthenticated-remote-code-execution/
Threat Advisory created by The Cyber Florida Security Operations Center.
Contributing Security Analysts: Taylor Alvarez, Sneha Lama, Michael Maldonado Cruz, Karishma Tallreja