What happened in the PHP2Shell firewall campaign?
PHP2Shell is no longer a theoretical risk. On 29 October, Palo Alto Networks Unit 42 said the two critical PHP flaws are being actively exploited against PAN-OS management interfaces that are reachable from the internet. Unit 42 also said it independently verified the tooling that Dream Research, an Israeli security firm, described in a report published three days earlier.
Dream's account is stark. A suspected China-linked operator built a private exploit for PHP2Shell, chained it with a Linux kernel flaw, and rooted 25 servers. Two of the 24 firewalls belonged to a US government-affiliated organization. The 25th server was that organization's internal firewall management server, reachable only through the first two compromises.
The firm says the chain runs from an unauthenticated HTTPS request to a persistent root shell in “under 15 minutes.” Targets sat in the United States, Japan, Taiwan and South Korea. The Register reported that Dream believes the intruders “likely still” hold remote access to compromised networks.
Palo Alto puts the exposure in context. Unit 42 said only about 0.02% of its global installed base had internet-facing management interfaces configured and was affected, and that its teams contacted each of those customers. The vendor says the management interface is not exposed to the internet by default, and that customers should remove public access where it has been enabled.
The dates matter for anyone tracking patch compliance. PHP published fixed releases and a security advisory on 21 October. CISA added both PHP flaws to its Known Exploited Vulnerabilities catalog on 26 October, and watchTowr says its honeypots logged exploitation on 21 October, the day the fixes appeared.
What is PHP2Shell and why is it so serious?
PHP2Shell is a pair of memory-safety bugs in PHP's core engine, tracked as CVE-2026-109618 and CVE-2026-109619. Both allow an unauthenticated attacker to execute code, and both carry a CVSS 4.0 score of 9.2. The flaws sit in how PHP handles fatal errors, especially out-of-memory conditions.
When those error paths run, PHP can leave corrupted state behind. A later request handled by the same worker may then reuse stale memory. Attackers can exploit that to read process memory, which may hold passwords, tokens, keys and certificates from other requests, or to run their own code.
Reach is the reason this matters. PHP runs WordPress, Drupal, Joomla and the MediaWiki software behind Wikipedia. Wiz Research estimates it powers about 70% of websites, and says every PHP release going back to version 5.4 is affected by at least one of the bugs. That estimate is a vendor assessment, not an independent census.
The bug lives in the interpreter, so a hardened plugin does not help. Vulnerable code runs before most application logic. The PHP project says the risk is highest for mod_php, where one request can trigger the attack before any application code executes, and lists PHP-FPM, php-cgi, FrankenPHP and LiteSpeed as exposed configurations too.
Wiz demonstrated pre-authentication code execution on WordPress, Drupal and Joomla, and published short demo videos for each. It also showed memory disclosure that can expose secrets held by other requests, a pattern it compares to Heartbleed. The comparison is about impact, not about identical mechanics.
Severity scores flatten some nuance. Palo Alto's advisory rates attack complexity as high, because exploitation depends on precise memory layout and version-specific offsets. Public proof-of-concept code still spread quickly: The Register counted “hundreds” of PHP2Shell repositories on GitHub, which lowers the bar for less skilled attackers even when a specific target needs custom work.
There is a compatibility trap underneath the patching advice. PAN-OS 12.1 and 12.2, the branches the attackers targeted, ship PHP 8.0.30 according to Dream. PHP 8.1 and older no longer receive updates from the PHP project, so appliances that bundle an old runtime depend on their vendor, not the language maintainers, for a fix.
How did AI change both sides of this fight?
Frontier models were involved in finding the flaws, which is why the story matters beyond one patching cycle. Wiz says it found the first bug on 19 August using Wiz Atlas, Gemini 4 Argon and GPT-5.6 Sol. It confirmed code execution against Drupal on 20 August, against WordPress on 21 August, and reported to PHP's security team on 24 August.
OpenAI says a researcher at Calif found a critical flaw with GPT-5.6 Sol as part of its Patch the Planet program, and that Wiz independently reported both issues. In OpenAI's words, “frontier AI found these vulnerabilities before attackers did.” That claim is about timing, not proof that models out-research humans.
The same capability cuts the other way. Wiz says frontier models let its own team develop and adapt working exploits across multiple applications in hours, and argues that “complexity may no longer provide a meaningful barrier” to exploitation. That is a defensive research team describing attacker economics, not a hypothetical.
Attackers had model access too, though the evidence is weaker than headlines suggest. Dream found Claude Code installed on the operator's infrastructure. It also found an offensive platform called aiscan configured with the Chinese models DeepSeek and Kimi, plus API keys for FOFA, a Chinese internet asset search engine.
Dream says it has “no direct evidence” that AI wrote the exploit. The inference rests on code structure and consistent commenting across roughly 40 scripts. The firm also says the operation does not appear to be a fully autonomous nation-state attack. Readers should keep that caveat attached to the AI framing.
OpenAI used the response to argue for a repeatable process. It described a five-stage disclosure framework covering validation, advance notice, government coordination, distributor updates and public guidance. It said it engaged the White House's Super Intelligence Force, the Office of the National Cyber Director and CISA, and committed $1 billion in subsidized security tooling access through Daybreak for Frontline Defenders.
Wiz describes a similarly broad industry effort. It says Automattic, Akamai, AWS, Cloudflare, Fastly, Google, Imperva, Microsoft and Vercel helped prepare mitigations for customers who could not patch at once. That coordination is now part of the disclosure story rather than an afterthought, because a fix that takes weeks to deploy needs interim cover.
How did the attackers get from a scan to domain admin?
Dream reconstructed a funnel. Using FOFA, the operator found about 19,000 internet-facing PAN-OS firewalls. A custom scanner with 200 concurrent threads identified roughly 5,000 live devices and their software versions. Filtering to four countries and to the PAN-OS 12.1 and 12.2 branches left 240 targets.
Those branches run PHP 8.0.30 with a high memory limit, which made the memory-corruption stages practical. An automated runner attacked the 240 devices five at a time and rooted 24 of them. A 103-byte PHP webshell was planted in a publicly reachable directory on each device.
The PHP exploit had four stages. It exhausted memory with crafted multipart uploads, leaked a pointer through a forged stale session ID, created a fake reference with a second out-of-memory trigger, then forged a table entry that calls PHP's system() function. Commands ran as the nobody user, not as root.
Fragnesia, tracked as CVE-2026-46300, closed that gap. The Linux kernel flaw let the attacker overwrite the pam.d/su file with a permissive policy, so su root stopped asking for a password. CISA added Fragnesia to its catalog on 28 October and noted that it can be chained with the PHP flaws to plant webshells and run commands as root.
The operator prepared carefully. Dream recovered 11 JSON version profiles, one per tested PAN-OS build, each holding memory offsets, library hashes and heap-tuning values. The 11.1 branch, which uses PHP 7.4.33, had only provisional profiles; just one of the 12.1 and 12.2 profiles was calibrated against a live virtual machine.
On the government-linked target the timeline was tight. The first firewall was rooted on 23 October at 18:14 UTC, crashed under roughly 900 MB of exploit traffic, and never recovered. The second fell on 24 October at 10:09 UTC. The internal management server followed at 11:35 UTC, less than 90 minutes later.
The firewall's own configuration handed over a map. Dream says it listed domain controllers, a central firewall management server, a Keycloak single sign-on server, a GitLab instance and GlobalProtect VPN gateways. Smart-card authentication and government-style naming suggested the environment's affiliation, and the internal topology made a second attempt worthwhile.
Persistence came next. The attacker built an eight-port reverse SSH tunnel, wrapped it in a systemd service and a boot hook, and used it to reach domain controllers, the management server and VPN gateways. Only two of the 24 firewalls saw this kind of activity; the rest were parked with webshells, which still means remote access.
Who is affected, and what should they do now?
Any PHP installation that serves web requests is in scope, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. Fixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1 and older get no official release, though the project published minimal source backports for 7.4, 8.0 and 8.1.
PHP is blunt about workarounds: “only an update is a complete solution.” Interim settings can close specific attack paths, such as disabling session upload progress for the confirmed CVE-2026-109619 route, but they do not remove the flaw or cover every variant.
Palo Alto says its patches interrupt the observed exploit chain, and Unit 42 says its threat-prevention signatures add coverage for customers who cannot update immediately. Those are compensations. The advisory still marks exploit maturity as attacked, which is vendor shorthand for exploitation observed in the wild.
CISA's catalog sets deadlines for US federal agencies and a reference point for everyone else. The two PHP flaws were added on 26 October with a remediation date of 29 October. Fragnesia was added on 28 October with a deadline of 31 October. That PHP deadline has now passed, so the useful question is no longer whether to patch but whether you can prove you did.
The entry asks agencies to follow BOD 26-04 and to retain forensic triage data. Patching is therefore not the only obligation: evidence preservation is part of the response, which matters when access may have predated the fix by days.
One more wrinkle: PHP published an informational advisory on 23 October about a third, related issue, CVE-2026-115560. It requires an unusual configuration where an application changes its session serializer at runtime. PHP says it will handle that one in its next regular release rather than an emergency patch.
- •Patch PHP to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, then restart every worker so stale processes cannot persist.
- •If you cannot patch yet, set memory_limit=-1 and lower post_max_size, as PHP advises, and enforce request size limits at the proxy.
- •Set session.upload_progress.enabled=0, which PHP recommends until its next regular bugfix release.
- •On PAN-OS, install the fixed build for your branch; 12.2.4-h1 and later are fixed on the 12.2 branch, with equivalent hotfixes on 12.1, 11.2, 11.1 and 10.2.
- •Remove internet access from firewall management interfaces, restrict them to trusted addresses, and check logs for the webshell path Dream published.
- •Confirm your hosting provider and any appliance vendor have applied their own fixes, since patches for bundled runtimes arrive on their schedule.
What the numbers do and do not tell us
Some figures in circulation describe exposure, not compromise. Unit 42 said Cortex Xpanse counted more than 22.6 million exposed instances potentially vulnerable to the PHP flaws. That is a measure of internet-facing software that may run affected versions, not a count of victims, and it will fall as patching proceeds.
The 70% figure is Wiz's estimate of PHP's share of websites. The 0.02% figure is Palo Alto's description of how much of its own installed base had internet-facing management and was affected. A small share of a very large base still includes consequential organizations, as the government-linked intrusions show.
Attribution is another soft spot. Dream says the activity is part of a Chinese-nexus operation but has not named an actor or a country's agency. Its geographic argument is inferential: it describes the four targeted countries as primary intelligence targets for Chinese state-aligned operations in the Pacific.
Some outcomes remain unknown. Dream could not recover whether the password spray succeeded, whether backdoor accounts were created, or whether SAML signing keys were extracted. Those results stayed on a management server filesystem the researchers did not obtain, so the absence of evidence is not evidence of containment.
The AI evidence deserves the same care. Installed developer tools and model API keys show intent and capability around the campaign. They do not show which code a model wrote. Dream's own wording separates the two, and defensive teams should read vendor summaries that blur them with caution.
What to watch next
The immediate test is patch uptake. A 29 October deadline has passed for the PHP bugs, and regulated organizations will need evidence that they met it. Firewall teams face a later deadline for Fragnesia, and parked webshells may surface in incident response for months.
Watch the appliance supply chain. Products that bundle an old PHP branch cannot rely on the language project for fixes, and their customers often do not know which runtime they run. The PAN-OS case is a template: a firewall's management web server was enough to reach Active Directory.
Watch disclosure norms too. OpenAI's proposed framework, the $1 billion in subsidized access, and its PHP version checker published as a Codex skill are attempts to industrialize the defender's side of AI-assisted bug hunting. OpenAI says it expects similar findings to increase sharply; the test is whether patch distribution keeps pace.
For developers, the lesson is unglamorous. Check which PHP build your stack actually runs, including inside appliances and control panels you did not write. Then treat “we patched the app” as an incomplete answer, because this flaw never lived in the app.