PHP2Shell Attacks: Patch PHP, Hide Admin Panels

This article explains what PHP2Shell actually is, why it matters far beyond one vendor, which PHP and PAN-OS versions fix it, and what to do if you run either. It also separates what is confirmed from what is still attributed or unproven, because in a fast-moving incident, that distinction matters more than speed.

What PHP2Shell is, in plain language

PHP2Shell is the name given to two critical PHP vulnerabilities, tracked as CVE-2026-109618 and CVE-2026-109619. Each carries a CVSS 4.0 score of 9.2, which puts them in the critical range. The important part is not the score itself, but what it means in practice: they can allow unauthenticated remote code execution on systems running affected versions of PHP. In other words, an attacker does not need a username or password to run their own code on the system. That is about as serious as a web vulnerability gets.

The two flaws are related but different. According to coverage of the PHP advisory, both involve unsafe memory handling when PHP stops processing a request after an error. CVE-2026-109618 affects out-of-memory handling through a function called longjmp, which jumps out of the current operation. CVE-2026-109619 leaves shared internal state pointing to memory that PHP has already freed, so a later request handled by the same worker can reach those stale references before normal setup resets them.

You do not need to understand every detail of memory handling to grasp the consequence. When a program mishandles memory in this way, an attacker who can send carefully crafted requests may be able to turn that confusion into control. That is why these flaws were patched urgently, and why proof-of-concept exploits and real exploitation followed quickly.

The PHP Group's security advisory identifies PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, and LiteSpeed deployments as exposed. That list matters, because PHP is not just a language used for websites. It is also used inside device web interfaces, including firewall management pages. That is the bridge between a PHP flaw and a Palo Alto Networks incident, and it is why this story is bigger than a single web server patch.

The patched PHP versions

The PHP Foundation patched these flaws upstream on 21 October 2026. The fixed releases are:

If you run PHP, the first question is not whether you have heard of PHP2Shell. It is which PHP version you are actually running, and whether it is at or above the fixed release for your branch. Older branches that are no longer supported will not receive a simple patch in the same way, and that is a conversation to have with your hosting provider or platform vendor, not a detail to ignore.

What happened with Palo Alto Networks

Palo Alto Networks' story is more specific, and more instructive, than a generic PHP patch notice. In an update on 29 October 2026, its Unit 42 team said it had independently verified attacker tools used to combine the PHP flaws with a Linux kernel vulnerability and gain root access, in attacks against PAN-OS management interfaces exposed to the internet.

The Hacker News reported the same update, quoting Palo Alto's advisory: active exploitation has been observed targeting the Palo Alto Networks management interface exposed to the internet. Palo Alto also said that customers who have applied the available patches are not affected, and customers who follow its standard recommendation not to expose the management interface to the public internet are also not affected. Those two sentences are the whole mitigation story in miniature: patch, and do not expose management.

The affected surface, according to Palo Alto, is strictly the management web interface. That includes the HTTPS web user interface and the XML API service. It covers PA-Series and VM-Series firewalls and Panorama, in both virtual and M-Series appliance forms where applicable. It does not affect GlobalProtect portals, gateways, Clientless VPN, or Captive Portal, according to the advisory summaries. It affects the dataplane interface only if a management profile is attached to it. Those distinctions matter, because they tell an administrator where to look, and where not to panic.

Palo Alto's fixed options cited in coverage include PAN-OS 12.2.4-h1, 12.1.10-h3, 11.2.16-h1, 11.1.16-h4, and 10.2.18-h13, with additional fixes for other maintenance releases. If you run PAN-OS, you should check the official Palo Alto advisory for your exact branch and build, rather than assuming a nearby version is close enough. Hotfix numbering matters here, and guessing is not a patch strategy.

Palo Alto also said roughly 0.02 percent of its global installed base had public management interfaces configured and was impacted, and that its teams had contacted those customers individually, according to Unit 42 coverage. That percentage sounds small, and it is, in relative terms. In absolute terms, for a vendor of Palo Alto's size, even a small percentage can mean a meaningful number of organisations, and the organisations affected are exactly the ones whose firewalls are most exposed.

The attack chain researchers described

Research firm Dream reported that an attacker it suspects is linked to China weaponised the flaws in conjunction with a Linux kernel flaw, Fragnesia, tracked as CVE-2026-46300, to root 25 servers across the United States, Japan, Taiwan, and South Korea. The chain, as described, used a custom PHP2Shell implementation aimed at the PAN-OS management web server, then Fragnesia, a local privilege-escalation flaw in the Linux kernel, to gain root access. Once inside, researchers found evidence of webshell placement, internal tunnelling, LDAP credential extraction, and Active Directory enumeration, among other post-exploitation activity.

That description should be read with care. The attribution to a China-nexus actor comes from Dream's research, not from Palo Alto's confirmation of the exploitation itself. Palo Alto has not said who is behind the attacks or how many devices were hit, according to advisory summaries. The 25-server figure comes from Dream's observed campaign, not from a Palo Alto count of all affected customers. Treating a researcher's attribution as a vendor-confirmed fact would be a mistake, and this article does not do that.

There is also an important correction in the timeline. Palo Alto's earlier update on 23 October linked activity at a European government agency to PHP2Shell, but investigators could not establish that these specific flaws provided initial access, and that earlier account was retracted. The 29 October update separately confirms the PAN-OS campaign. That sequence is a useful reminder: early reports in a fast incident can be wrong, and later, verified updates matter more than first headlines.

The US Cybersecurity and Infrastructure Security Agency added CVE-2026-109618 and CVE-2026-109619 to its Known Exploited Vulnerabilities catalog on 26 October, with a due date of 29 October for federal civilian agencies, and marked both for forensic triage. That last phrase is important. Forensic triage means agencies should check for compromise, not just patch. CISA later added Fragnesia, CVE-2026-46300, with a due date of 31 October, and said it can be chained with PHP2Shell to implant PHP webshells and run commands as root. The message is consistent: patching is necessary, but if a system was exposed, patching alone does not prove it was never compromised.

What to do if you run PHP

Start by inventorying where PHP runs in your environment, not just on your main website. Check your web servers, your applications, your hosting platform, and any devices or appliances that use PHP in a web interface. If you do not know where PHP is running, you cannot patch it, and that unknown is itself a risk.

Next, check versions against the fixed releases: 8.2.35, 8.3.36, 8.4.27, and 8.5.12, depending on your branch. Update to the fixed release for your branch, and test that your applications still work. PHP updates can break old code, especially code that relies on deprecated behaviour, so testing matters. But testing should not become an excuse for indefinite delay, especially for internet-facing systems.

Then, look at exposure. Is PHP reachable from the internet in ways it does not need to be? Are there test pages, debug endpoints, or old applications still live that no one maintains? Those are the kinds of surfaces that turn a vulnerability into an incident. Removing what you do not need is often more effective than adding another layer of monitoring on top of it.

Finally, if a system was running an affected PHP version and was internet-facing, treat it as potentially compromised until you have checked. Look for unexpected files, especially webshells, unexpected processes, unusual outbound connections, and changes to user accounts or credentials. If you find something suspicious, preserve evidence and get help from someone experienced in incident response, rather than simply deleting the file and moving on.

What to do if you run Palo Alto Networks

If you run PAN-OS, the order of operations is slightly different, because the immediate risk is not just PHP in general, but a specific management interface.

First, remove public internet access to management interfaces if it is enabled. This is Palo Alto's own first recommendation, and it is the single most effective step. Management should be reachable only from trusted internal IP addresses, ideally through a secure, controlled path, not from anywhere on the internet. If you are not sure whether your management interface is public, check now, rather than assuming it is not. Many exposures happen because a temporary change becomes permanent and is forgotten.

Second, apply the available PAN-OS fixes for your branch, using the official advisory to confirm the correct hotfix. Do not assume that because you updated PHP on a web server, your firewall is fixed. PAN-OS is a separate product with its own patch path, and the hotfix list above is specific to PAN-OS branches.

Third, check for compromise, not just patch status. CISA's forensic triage note applies here with full force. If your management interface was public and running an affected version, look for signs of unauthorised access, new accounts, configuration changes, webshells, and unusual outbound traffic. Palo Alto's guidance and your own logs are the starting point, but if you find evidence of compromise, treat it as an incident, not as a patching task.

Fourth, review your management access controls more broadly. Who can reach management, from where, with what authentication, and how is that access logged and reviewed? A firewall that protects everyone else but leaves its own management open is a contradiction, and this incident is a concrete example of why that contradiction matters.

Bottom line

PHP2Shell is two critical PHP flaws, CVE-2026-109618 and CVE-2026-109619, with a CVSS score of 9.2, allowing unauthenticated remote code execution. They were patched in PHP 8.2.35, 8.3.36, 8.4.27, and 8.5.12. Palo Alto Networks has confirmed active exploitation against internet-exposed PAN-OS management interfaces, with PAN-OS hotfixes available for affected branches. The fix is straightforward in principle: update PHP, apply the PAN-OS hotfix for your branch, remove public management access, and check exposed systems for compromise. The hard part is doing all of that quickly, and doing it for every system that runs PHP, not just the ones you remember.