Issuu

Threat Analysis Report November 5, 2026

PHP2Shell Critical PHP Vulnerabilities and their Operational Impact Taylor Alvarez | Sneha Lama | Michael Maldonado Cruz | Karishma Tallreja

Table of Contents I. II. III. IV. V. VI. VII.

Executive Summary.............................................................................................................2 Introduction..........................................................................................................................2 Impact..................................................................................................................................4 Tactics and Techniques........................................................................................................7 Indicators of Compromise....................................................................................................9 Recommendations..............................................................................................................12 References..........................................................................................................................14

Executive Summary

Two critical remote code execution (RCE) vulnerabilities, CVE-2026-109618 and CVE-2026109619, 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: · · · · · ·

Execute malicious code remotely without authentication. Access application files and data available to the PHP worker account. Extract sensitive information, including passwords, authentication tokens, API keys, and session data. Deploy web shells or additional payloads to maintain access. Disrupt website availability or modify hosted applications. Use compromised credentials to access connected systems where permissions and network connectivity allow. [3][14]

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]

II.

Introduction

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]

III.

Impact

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. a. Current Threat Activity and Reported Compromise 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] b. Attacker Preparation and Exploitation Constraints 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. c. Scope of Exposure 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. d. Code Execution and Sensitive Information Exposure 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. e. Availability and Documented Service Disruption 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.

f. Recovery Burden and Continued Exposure 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. g. Assessment Limitations 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.

IV.

Tactics and Techniques

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

Initial Access

TECHNIQUE

Exploit PublicFacing Application

Execution

Unix Shell

Discovery

System Owner/User Discovery

Discovery

System Information Discovery

Command Ingress Tool and Control Transfer

Persistence Server Software Component: Web Shell

MITRE DESCRIPTION ATT&CK ID

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]

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]

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]

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]

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]

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]

Indicators of Compromise

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 Indicato Data r

Description

IP Address

103[.]216[.]220[.]92

Source IP observed by AWS on October 17, 2026. [5]

IP Address

31[.]223[.]184[.]166