A critical PHP security crisis has entered a more dangerous phase. Two vulnerabilities known as PHP2Shell are now being actively exploited against internet-facing Palo Alto Networks management interfaces, with security researchers reporting attacks that combine the flaws with a separate Linux privilege-escalation vulnerability.
The development is a serious warning for organisations running exposed infrastructure and web services. The vulnerabilities, tracked as CVE-2026-109618 and CVE-2026-109619, were initially disclosed on October 21, 2026. Both carry a CVSS 4.0 severity score of 9.2 and can potentially allow unauthenticated remote code execution.
The latest update from Palo Alto Networks’ Unit 42 research team, published October 29, confirms active exploitation against exposed PAN-OS management interfaces. Researchers also verified tooling associated with an attack chain that can turn an initial compromise into root-level access on vulnerable Linux systems.
This is no longer simply a warning to install a routine security update. It is an active security incident that infrastructure administrators need to take seriously.
What Is PHP2Shell?
PHP2Shell is the name being used for two critical vulnerabilities in PHP’s request-handling and memory-management processes.
PHP is one of the most widely deployed server-side programming languages. It powers websites, content management systems, online services and numerous enterprise applications.
The problem is that the vulnerabilities exist in PHP itself rather than in a particular WordPress plugin or website application.
That means updating a website’s plugins or changing its theme does not resolve the underlying vulnerability. The PHP runtime must be patched.
The two vulnerabilities are:
- CVE-2026-109618: A memory-handling flaw involving out-of-memory conditions that can leave request memory in an unsafe state.
- CVE-2026-109619: A memory-management flaw involving stale references to freed memory, potentially allowing subsequent requests to access unsafe memory states.
Under vulnerable conditions, attackers may be able to exploit these weaknesses to execute arbitrary code remotely without authenticating first.
The risk is particularly serious for internet-facing PHP services, where an attacker may be able to send a malicious request directly to the exposed system.
Attackers Are Now Exploiting the Vulnerabilities
The most important development came in Unit 42’s October 29 threat intelligence update.
Palo Alto Networks reported that PHP2Shell vulnerabilities were being actively exploited against PAN-OS management interfaces exposed to the internet.
Researchers also described a campaign in which attackers chained PHP2Shell with a separate Linux kernel privilege-escalation vulnerability to obtain root access.
Unit 42 independently verified the attacker’s tooling and confirmed the reported results.
This distinction matters: the confirmed exploitation described in the latest update concerns exposed Palo Alto Networks management interfaces. It should not be interpreted as proof that every vulnerable WordPress website or PHP server has been compromised.
However, the incident demonstrates how a vulnerability in a widely used technology can become an entry point into more sensitive infrastructure.
From Remote Code Execution to Root Access
Remote code execution is already a serious security problem. It can allow attackers to run commands and potentially access data or services available to the compromised process.
But attackers do not always stop there.
Privilege escalation is the process of obtaining higher permissions after gaining an initial foothold.
In the reported attack chain, PHP2Shell was combined with a separate Linux kernel vulnerability to escalate privileges and obtain root access.
Root access gives an attacker extensive control over a Linux system. Depending on the environment, this can allow access to sensitive files, system configurations, credentials and other resources.
The combination illustrates why organisations must consider both application vulnerabilities and operating-system security when investigating a possible compromise.
More Than 22.6 Million Potentially Exposed Instances
One of the most concerning figures comes from Palo Alto Networks’ Cortex Xpanse exposure telemetry.
The company identified more than 22.6 million potentially exposed instances that could be vulnerable to the two PHP flaws.
It is important to understand what this number represents.
It does not mean that 22.6 million websites have been hacked, nor does it establish that every identified instance is exploitable. It represents potentially vulnerable internet-exposed instances identified through the company’s telemetry.
Nevertheless, the scale highlights how widely PHP is deployed and how difficult it can be for organisations to maintain visibility over every system running it.
A company may know which software powers its main website while overlooking older applications, secondary domains, development servers or services running on the same infrastructure.
Those forgotten systems can become attractive targets.
Which PHP Versions Are Affected?
The PHP development team released security updates on October 21, 2026.
The patched versions for the affected supported branches are:
| PHP branch | Patched version |
|---|---|
| PHP 8.5 | 8.5.12 |
| PHP 8.4 | 8.4.27 |
| PHP 8.3 | 8.3.36 |
| PHP 8.2 | 8.2.35 |
Administrators should verify that their hosting provider has installed the appropriate security release.
Older unsupported PHP branches require special attention because they may not receive official fixes through the normal PHP release process.
WordPress Websites Are Also in Scope
WordPress relies on PHP to execute its core software, themes and plugins.
Because PHP2Shell affects the underlying PHP runtime, WordPress websites using vulnerable PHP installations may also be exposed.
Updating WordPress alone is not enough.
Website administrators should:
- Check the PHP version assigned to every website.
- Upgrade to a patched PHP release.
- Verify that the correct PHP handler is using the updated runtime.
- Review server logs for unusual requests and unexpected activity.
- Check for unauthorised files, scheduled tasks and modified website code.
- Make sure backups are available and have not been compromised.
Patching reduces exposure to the vulnerabilities, but it does not establish whether a system was compromised before the update.
A Separate PHP Vulnerability Has Also Emerged
The PHP security situation has another complication.
On October 23, additional information was published about CVE-2026-115560, a separate remote code execution vulnerability involving session upload progress and certain runtime configuration conditions.
This issue is not covered by the October 21 security releases listed above.
The Canadian Centre for Cyber Security has highlighted the additional vulnerability and reported that exploitation requires an uncommon combination of PHP configuration and application behaviour.
One temporary mitigation recommended for this separate issue is disabling session upload progress:
session.upload_progress.enabled=0
Administrators should review the official PHP guidance and vendor-specific advisories before applying configuration changes. This mitigation is not a replacement for patching the original PHP2Shell vulnerabilities.
The appearance of another issue shortly after the original emergency releases reinforces the importance of following PHP security announcements rather than assuming that one update resolves every related problem.
What Should Server Administrators Do Now?
Organisations running PHP should treat this as a high-priority security issue.
1. Identify every PHP installation
Check production websites, secondary domains, development environments and internal applications. Do not assume that every service uses the same PHP version.
2. Install the appropriate security updates
Upgrade supported PHP branches to the patched releases. If you rely on a hosting provider, request confirmation that the actual PHP runtime and handler have been updated.
3. Restrict management interfaces
Palo Alto Networks specifically recommends removing public internet access to management interfaces and restricting administration to trusted internal IP addresses.
Management interfaces should never be exposed unnecessarily.
4. Investigate suspicious activity
Review web server logs, authentication records, firewall events and system processes. Look for unusual requests, unexpected outbound connections, unfamiliar accounts and unauthorised modifications.
5. Check operating-system security
The reported attack chain involved a separate Linux kernel privilege-escalation vulnerability. Keeping PHP updated is not enough if the underlying operating system remains vulnerable.
6. Prepare for incident response
If there are signs of a successful compromise, preserve relevant logs, isolate affected systems where appropriate and investigate the extent of access before returning services to normal operation.
Do not assume that installing a PHP patch automatically removes an attacker’s existing access.
Why This Matters Beyond PHP
PHP2Shell is another example of how vulnerabilities in common infrastructure can have consequences far beyond individual applications.
Modern organisations depend on layers of software: operating systems, web servers, programming runtimes, databases, management interfaces and third-party services.
A weakness in one layer can provide an attacker with a route into another.
The incident also demonstrates why asset visibility and patch management are essential. Organisations cannot protect systems they do not know exist, and a forgotten internet-facing service can become an entry point into a much larger environment.
For smaller website owners, the lesson is equally important: server security does not end with WordPress updates, strong passwords or security plugins. The underlying software must be maintained as well.
Final Verdict: PHP2Shell Has Become an Active Infrastructure Threat
The PHP2Shell vulnerabilities were already serious when the emergency patches were released on October 21. The latest October 29 findings make the situation even more concerning.
Security researchers have now reported active exploitation against exposed PAN-OS management interfaces and verified an attack chain involving Linux privilege escalation.
The reported 22.6 million potentially exposed instances demonstrate the scale of the technology’s footprint, although they should not be confused with confirmed compromises.
For server administrators, the priorities are clear: patch vulnerable PHP installations, restrict exposed management interfaces, update operating systems and investigate suspicious activity.
If your infrastructure is still running an unpatched PHP version, this is not an update to postpone.
Official and technical sources
- Palo Alto Networks Unit 42 — PHP2Shell Threat Brief, updated October 29, 2026
- Canadian Centre for Cyber Security — PHP vulnerability advisory
- NCSC Netherlands — PHP2Shell operational information
- PHP official security releases
- Red Hat — PHP2Shell security advisory
Information in this article reflects security reporting available on October 30, 2026. Vulnerability status and vendor remediation guidance may change as investigations continue.
















