PHP2Shell is a pair of critical PHP remote code execution (RCE) flaws, CVE-2026-109618 and CVE-2026-109619, that let an attacker run their own commands on a web server. PHP patched them on October 21, 2026, and the Cybersecurity and Infrastructure Security Agency (CISA) added both to its Known Exploited Vulnerabilities (KEV) catalog five days later. On November 3, Singapore’s Cyber Security Agency (CSA) warned that attackers are now using PHP2Shell against the management interfaces of vendor firewalls, and the list of affected appliances kept growing through last week.
The short version: PHP2Shell started as a web server problem and has become a third-party risk management (TPRM) problem. PHP runs inside firewalls, VPN gateways, hosting panels and SaaS back ends that your organization doesn’t patch itself, so your exposure depends on how fast dozens of third parties ship and deploy fixes.
Key takeaways
- PHP2Shell lets an unauthenticated attacker run code on a server through crafted HTTP requests, before any application login is checked.
- Exploitation began on October 17, 2026, four days before public disclosure, according to Amazon Threat Intelligence.
- Attackers have chained PHP2Shell with a Linux kernel flaw to root firewalls and then move into Active Directory.
- Of 55 vendors tracked by Eclypsium as of early November, only 15 had fully fixed their affected products.
- Third-party risk teams should identify which vendors embed PHP in internet-facing products and ask for patch status in writing.
What happened with PHP2Shell?
PHP2Shell is the name given to two memory-safety bugs in the PHP interpreter, versions 5.4 through 8.5. Both carry a Common Vulnerability Scoring System (CVSS) 4.0 score of 9.2. Datadog Security Labs explains the common pattern: a fatal error interrupts an operation partway through, and PHP later treats the incomplete state as valid.
Because the attack runs while PHP parses the request, application-level authentication can’t stop it. Fixed builds are PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. PHP 7.4, 8.0 and 8.1 received source patches only, since those branches are end of life.
What has been confirmed
- October 17: Amazon Threat Intelligence saw an exploitation attempt against its honeypots four days before disclosure.
- October 21: PHP released the fixes. The UK’s national cyber security agency (NCSC) told organizations to inventory every PHP installation, not only outdated ones.
- October 26: CISA added both CVEs to the KEV catalog, with a federal deadline of October 29.
- October 29: Palo Alto Networks reported active exploitation of internet-exposed management interfaces on PAN-OS, its firewall operating system.
- November 3: Singapore’s CSA listed affected products from Palo Alto Networks, Cisco, Citrix, F5, Siemens and Fortinet.
What researchers report but vendors haven’t confirmed
Researchers at security firm Dream reported 25 servers rooted across the US, Japan, Taiwan and South Korea, three of them in a US government-affiliated environment. The attacker reportedly chained PHP2Shell with CVE-2026-46300, a Linux privilege escalation flaw known as Fragnesia, then extracted credentials and enumerated Active Directory. Dream didn’t name the firewall vendor, and that link hasn’t been confirmed.
Palo Alto Networks’ Unit 42 threat research team tracks the activity as CL-UNK-1280 and attributes it to a Chinese-speaking actor. No ransomware use has been reported so far.
Who is affected by PHP2Shell?
PHP powers roughly 70% of websites, and internet scanning firm Censys estimated that more than 32.5 million PHP services were still running an affected version after the patch. That includes WordPress, Drupal and Joomla sites, hosting panels such as cPanel and Plesk, and a long list of commercial appliances.
The vendor picture is the part that matters most for third-party risk. A vendor status tracker published by security firm Eclypsium counted the following across 55 vendors:
| Status | Vendors |
|---|---|
| Fixed | 15 |
| Partially fixed | 13 |
| Not affected | 15 |
| Fix scheduled or investigating | 4 |
| Affected, no fix | 1 |
| No public statement | 7 |
Some products will never be fixed, including Synology’s PHP 7.3 package and HPE System Management Homepage. Check Point, Cisco, Extreme and Hillstone had fixes scheduled for November.
Why does PHP2Shell matter for third-party risk management?
The PHP2Shell vulnerability is a third-party risk story more than a patching story. Most organizations will patch their own web servers within days. The harder question is what their vendors have done.
Your vendor’s runtime is your attack surface
A firewall, a VPN gateway or a hosted portal may run PHP internally without listing it anywhere you would see. The PAN-OS exploitation shows the result: the vulnerable code sat in a security product’s management interface. Your team can’t patch it. Only the vendor can ship the fix, and only someone on your side or theirs can deploy it.
Edge devices turn one bug into domain access
Network edge devices, meaning firewalls, VPN concentrators and load balancers that sit at the network perimeter, hold credentials and trust relationships. In the reported campaign, the attacker went from a rooted firewall straight to Active Directory. A vendor appliance compromise becomes an identity compromise in a few steps, a pattern seen across the most exploited vulnerabilities of the past year.
Silence is not a patch status
Seven vendors in the Eclypsium tracker had said nothing publicly, and 33 hadn’t said whether their products were exploited. “No advisory” can mean not affected, still investigating or not paying attention. Each answer calls for a different response.
Concentration multiplies the impact
Hosting providers and managed service providers run PHP for thousands of customers. One slow patch cycle at a shared provider exposes every tenant on that platform. Infrastructure vendors often get the lightest review, yet they carry the widest blast radius.
What can continuous monitoring do here, and what can’t it?
Continuous vendor monitoring can show which vendors expose PHP-based services or management interfaces to the internet, flag when a vendor’s external attack surface changes, and surface threat intelligence that names a vendor or its products. That turns a list of 200 vendors into a short list worth calling first, much faster than a point-in-time review cycle.
There are limits. Monitoring can’t see PHP running inside a vendor’s private network or confirm that a patch was deployed. Outside-in signals tell you where to look. The vendor’s written answer, and evidence behind it, closes the question.
Sling was built for this kind of outside-in view. The Sling Score combines darknet and criminal intelligence with attack surface mapping, and an assessment starts from a domain name, with no agent, and returns results within 24 hours.
What should risk teams do about PHP2Shell this week?
- List the vendors that embed PHP. Begin with your critical vendors in firewall, VPN, load balancer, hosting and web platform categories, then add SaaS providers that run customer-facing portals.
- Cross-check the public advisories. Compare each vendor against the CSA and NCSC-NL product lists and the vendor’s own advisory page.
- Ask critical vendors for patch status in writing. Ask which products are affected, which fixed version is deployed and when, and whether they have checked for compromise.
- Escalate the silent vendors. A critical vendor with no public statement three weeks after disclosure needs a direct call, not another questionnaire.
- Confirm management interfaces are off the internet. Both Palo Alto Networks and CSA recommend restricting management access to trusted networks.
- Record end-of-life products as accepted risk or replace them. Products that will never be patched belong in your risk register with an owner and a date.
Bottom line
PHP2Shell will be fixed on most web servers within weeks. The long tail sits inside vendor products, where patch timing is someone else’s decision. Teams that know which vendors depend on PHP, and ask them early, will close this exposure faster than teams waiting for the next annual review.
CTA: Want to see which of your vendors expose PHP-based services to the internet? Sling maps their external exposure and darknet signals starting from a single domain. Request a vendor risk assessment
FAQ
What happened in the PHP2Shell attacks? PHP disclosed and patched two critical flaws, CVE-2026-109618 and CVE-2026-109619, on October 21, 2026. Attackers had already tried them four days earlier, and by early November they were hitting the management interfaces of vendor firewalls.
What is PHP2Shell? PHP2Shell is the name for two memory-safety bugs in PHP versions 5.4 through 8.5. They let an unauthenticated attacker run code on a server through crafted HTTP requests.
Has PHP2Shell led to stolen data? That hasn’t been confirmed. Researchers at Dream reported credential extraction from Active Directory after firewalls were rooted, but the scope of any data theft hasn’t been disclosed.
Why is PHP2Shell a third-party risk issue? PHP runs inside firewalls, VPN gateways, hosting panels and SaaS platforms that customers can’t patch themselves. Your exposure depends on how fast each vendor ships and deploys the fix.
Could continuous vendor monitoring have prevented this? Monitoring can’t prevent an attack on a vendor’s product. It can show which vendors expose PHP-based services or management interfaces to the internet, so you know whom to call first.
What should companies do about PHP2Shell now? Patch your own PHP servers, then ask critical vendors in writing which products are affected and when the fix was deployed. Escalate vendors with no public statement and keep management interfaces off the internet.
Sources
- Datadog Security Labs, PHP2Shell: Critical vulnerabilities in PHP, October 21, 2026
- Amazon Web Services, Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot, October 21, 2026
- UK NCSC, Critical security issue affecting PHP, October 21, 2026
- The Hacker News, CISA Confirms Active Exploitation of Two PHP2Shell Flaws, October 2026
- The Hacker News, Attackers Exploit PHP2Shell Flaws in PAN-OS, October 29, 2026
- Cyber Security Agency of Singapore, Active Exploitation of PHP2Shell Vulnerabilities Affecting Network and Security Products, November 3, 2026
- Eclypsium via Security Boulevard, PHP2Shell: A Network Edge Risk Playbook, November 10, 2026