PHP2Shell: Critical PHP Flaws Put Web Servers at Risk

Two critical vulnerabilities in PHP have created a high-priority exposure for organizations that operate internet-facing web servers, applications or content-management systems. Palo Alto Networks Unit 42 identifies the flaws as CVE-2026-109618 and CVE-2026-109619 and says they are collectively being referred to as “PHP2Shell.” Both vulnerabilities carry a CVSS 4.0 score of 9.2.

Unit 42 reports that it has seen proof of concept for the vulnerabilities and observed exploitation followed by credential-access and Active Directory activity in at least one incident involving a European government entity. The organization also says Cortex Xpanse telemetry identified more than 22.6 million potentially exposed instances. That figure represents exposure identified through Palo Alto Networks telemetry, not a confirmed count of vulnerable or compromised organizations.

The immediate priority is to identify systems running affected PHP versions, apply the PHP Group’s security updates, and investigate whether web-server processes have launched unexpected commands. The research indicates that exploitation can move quickly from a vulnerable public-facing service to host reconnaissance and attempts to access enterprise identity infrastructure.

What the two vulnerabilities do

The vulnerabilities are related to PHP’s handling of fatal and out-of-memory conditions involving longjmp(), a control-flow mechanism used when execution must recover from an error.

According to Unit 42, CVE-2026-109618 can leave request memory uninitialized when PHP handles an out-of-memory condition. An attacker can use out-of-memory triggers to reach a state in which remote code execution becomes reliable.

CVE-2026-109619 involves a different memory-lifetime failure. Unit 42 says fatal-error handling can leave global memory pointing to regions that have already been freed. Those regions may later be read or used in control-flow decisions during subsequent requests, creating a path to arbitrary code execution.

These descriptions explain the core technical risk, but the supplied research does not define a single universal exploit request, identify every prerequisite for successful exploitation, or specify which PHP versions and deployment configurations are affected. Administrators should therefore use the PHP Group’s advisory and their vendors’ security guidance to determine exact version exposure rather than relying on assumptions about a particular web framework or CMS.

How exploitation can develop into an enterprise incident

The reported activity illustrates a possible progression rather than a guaranteed sequence for every compromise:

1. Exposure: An internet-reachable service runs a vulnerable PHP deployment. Unit 42’s exposure research focuses on publicly accessible instances, including systems supporting web servers and content-management deployments.
2. Initial code execution: The attacker exploits one of the PHP memory-management flaws to execute code in the context of the web application or PHP worker.
3. Host discovery: Commands run through the compromised service enumerate the operating system, users, processes, network configuration and related host details.
4. Credential and secret access: In the government-entity case described by Unit 42, attackers accessed password hashes and multifactor-authentication secrets within two hours of initial exploitation.
5. Identity-environment activity: The attackers established an NTLM-relay tunnel into Active Directory and attempted to escalate privileges to Domain Admin.

Unit 42 does not state that every PHP2Shell exploitation attempt includes all of these stages. The report describes a specific observed case and uses it to demonstrate how a web-server compromise can become an identity-infrastructure incident in a short period.

The source also says that at least one European government temporarily took its website offline as a precaution. The organization is not named in the supplied research, and the report does not claim that all affected public websites have been compromised.

Post-exploitation behavior and the “agentic” assessment

Unit 42 researchers observed what they describe as agentic-AI attack platforms being used during post-exploitation activity. Their assessment is based on the structure and timing of the commands, rather than on a publicly identified threat actor.

One notable behavior was the use of machine-readable section markers around command batches. Examples cited by Unit 42 include delimiters such as ==SHELLUSER== and ==PASSWD==. The researchers assessed that these markers were intended to organize output for an AI model. They also observed short, serially spaced tasks and rapid pivots after unsuccessful actions, which they considered strong behavioral indicators of an agentic attacker.

This is an assessment of observed behavior, not an attribution to a named group. The supplied research does not identify the operators, their nationality, a malware family, or a specific command-and-control domain or IP address. It also does not establish that the AI-assisted workflow was responsible for the original vulnerability exploitation itself; the observation concerns post-exploitation activity.

Detection priorities for defenders

The most useful detection opportunities are likely to appear at the boundary between a web-facing PHP process and operating-system activity. A PHP worker, web-server process or IIS worker launching a shell or administrative utility should receive careful review, particularly when the activity occurs outside the application’s expected behavior.

Unit 42 provides Managed Threat Hunting queries for Cortex XDR and network-focused queries for Palo Alto Networks NGFW Threat Logs. The endpoint logic looks for processes associated with PHP and common web-server stacks, including PHP-FPM, PHP-CGI, Apache, IIS and LiteSpeed, followed by suspicious child processes or command lines. It groups activity into one-hour windows and looks for combinations of reconnaissance and follow-on behaviors.

Relevant behavioral categories in the supplied query include:

• Host, user and network reconnaissance launched by a PHP or web-server context.
• Downloading files to disk or staging executables in temporary or memory-backed directories.
• Reverse-shell constructs or remote content piped directly into an interpreter.
• Encoded execution and inline interpreter use.
• Persistence attempts involving scheduled tasks, service or systemd configuration, new accounts, SSH authorized keys or other startup mechanisms.
• Access to credential files, environment variables, cloud credentials, container secrets or application .env files.

The query is not specific to CVE-2026-109618 or CVE-2026-109619. Unit 42 explicitly warns that it can identify exploitation of other web-application vulnerabilities and may generate false positives. Security teams should validate each alert against the application’s documented behavior, deployment tooling and maintenance processes.

Network teams using the referenced Palo Alto Networks telemetry can review vulnerability threat logs for inbound activity from publicly routed sources, using the relevant PHP and PHP2Shell detection signatures where available. The report identifies Threat ID 543004 and additional signatures 97622, 97623, 97624 and 97625 in the context of Palo Alto Networks protections. These are vendor-specific detections, not universal indicators that can be applied to every security platform.

What organizations should do now

1. Inventory PHP exposure. Identify PHP versions across production servers, development systems, containers, registry images and managed hosting environments. Include legacy and externally managed systems that may not appear in standard asset inventories.
2. Prioritize internet-facing assets. Use external attack-surface monitoring to locate public PHP services, then confirm whether each instance is necessary, patched and protected by appropriate network controls.
3. Patch using authoritative guidance. Apply the PHP Group’s security updates and follow application or platform vendor instructions. Where immediate patching is not possible, reduce exposure and use available virtual-patching or intrusion-prevention controls as a temporary risk-reduction measure.
4. Review process execution. Investigate shells, scripting interpreters, download utilities, temporary-directory execution and credential-access commands whose parent or causality chain leads back to PHP, Apache, IIS or another web worker.
5. Examine identity systems. If exploitation is suspected, review access to password hashes, multifactor-authentication material and Active Directory. Investigate unusual NTLM-relay-related activity and attempted privileged-group changes.
6. Preserve evidence before rebuilding. Retain web-server, PHP, endpoint, firewall, authentication and Active Directory logs. Coordinate containment and forensic review before deleting suspicious files or restarting affected services.
7. Check supply-chain paths. For containerized or CI/CD environments, scan images and registries for vulnerable PHP components and ensure corrected images cannot be reintroduced into runtime environments.

Palo Alto Networks says its product portfolio includes protections and exposure-identification capabilities across Cortex XDR and XSIAM, Cortex Cloud and Prisma Cloud, Cortex Xpanse, and Next-Generation Firewall services. Organizations should verify product coverage, content versions and configuration in their own environments rather than assuming that a licensed product is automatically providing protection.

What remains unknown

The supplied Unit 42 research does not provide named victims, a named threat actor, malware-family attribution, command-and-control infrastructure, exploit code or a complete list of affected PHP releases. It also does not provide a universal exploitation prerequisite or confirm that all publicly exposed instances are exploitable in the same way.

Those gaps do not reduce the urgency of remediation. They do mean that incident responders should avoid treating the reported government case, the agentic-activity assessment or the exposure estimate as a complete description of every PHP2Shell incident.

Conclusion

PHP2Shell combines two serious PHP remote-code-execution vulnerabilities with a broad deployment footprint and evidence that successful compromise can lead rapidly to credential and directory-service activity. Unit 42’s findings support an immediate, risk-based response: locate vulnerable PHP systems, patch them, monitor web-worker process chains, and investigate identity-system access where exploitation may have occurred. Detection should focus on behavior and parent-child process relationships, while conclusions about attackers and AI assistance should remain aligned with the source’s stated assessment.

Sources

• Palo Alto Networks Unit 42: Critical Vulnerabilities in PHP — CVE-2026-109618 and CVE-2026-109619