PHP2Shell (CVE-2026-109618 & CVE-2026-109619): What It Means for Your Servers, Fortinet, Cisco and Palo Alto

Most vulnerability stories are about one application. PHP2Shell is different: the bugs sit in the language runtime that powers roughly seven out of ten websites, from WordPress and Drupal to Laravel back-ends and the management consoles embedded in network appliances. That is why, within 48 hours of disclosure, government portals went offline as a precaution, three of the largest security vendors published advisories, and every IT team that owns even one PHP install had a new emergency on its plate. This article explains what the flaws are, who has confirmed what, and the order in which to act.

What Is PHP2Shell?

PHP2Shell is the name Wiz Research gave to two memory-safety vulnerabilities in PHP’s core request handling. They were discovered independently in August 2026 by Wiz, OpenAI and Calif, reported to the PHP security team on 11 August, and scheduled for coordinated disclosure on 22 October. When details leaked on 20 October — including a video with a working proof of concept — the PHP Foundation pulled the release forward by a day.

CVE-2026-109618 — out-of-memory corruption

A crafted multipart request can push PHP into an out-of-memory condition while internal request data is only partly initialised. The clean-up code then treats that half-built data as valid. On Apache mod_php, the attack succeeds before any application code runs, with default limits, which is why PHP rates this configuration as the highest risk.

CVE-2026-109619 — stale state across requests

Request-owned internal state can outlive the memory it points to. The next request handled by the same worker reaches that stale data before normal initialisation resets it — a classic use-after-free. Session upload progress (enabled by default) and the PHP 8.5 fatal-error backtrace feature are two confirmed paths.

Timeline: From Private Report to Public Exploitation

How Severe Is It, Really?

Both CVEs carry a CVSS v4.0 score of 9.2 (Critical); Fortinet rates CVE-2026-109618 at 9.8 on CVSS v3. Wiz described the pair as “among the most severe vulnerabilities discovered in PHP, and arguably in software history.” Three facts temper the panic without removing the urgency:

• Public exploits are still unreliable on x86-64 Good news
  VulnCheck reproduced both bugs and reports that most GitHub proof-of-concept code does not work yet; none of it bypasses ASLR on x86-64 on its own. Exploitation is more practical on ARM64 and on systems without ASLR.
• Attack traffic is widespread anyway Watch
  Hadrian reports exploitation “at scale” through the session upload-progress path; watchTowr’s honeypots saw attempts the hour the patches landed. Log volume alone will not tell you whether a given server is at risk.
• Memory disclosure works even without RCE Act now
  Wiz demonstrated reading PHP worker memory — passwords, tokens, API keys — without achieving code execution. If a server was exposed and unpatched during the attack window, treat its secrets as potentially compromised.

Fortinet, Cisco and Palo Alto: Who Has Confirmed What

Security appliances and management consoles frequently embed PHP, so the three largest network-security vendors published advisories within a day. Their positions differ sharply.

Fortinet — FortiGate not affected, five products under review

Fortinet’s PSIRT advisory FG-IR-26-186 (published 21 October, updated 22 October) lists 34 products as confirmed not impacted, including FortiOS (the FortiGate firewall operating system), FortiGate Cloud, FortiManager, FortiAnalyzer, FortiWeb, FortiMail, FortiProxy, FortiSandbox, FortiSIEM, FortiSASE, FortiAuthenticator, FortiSwitch, FortiNAC and all FortiClient endpoint agents and EMS. Still under investigation: FortiDDoS, FortiDDoS-F, FortiClient Cloud Services, FortiSOAR and FortiSOAR PaaS. No fixed versions or workarounds are listed for those yet. On the detection side, FortiGuard released IPS signatures 10009977 and 10009978 in definition version 37.316, and FortiCNAPP flags both CVEs in Linux PHP packages.

Cisco — nothing confirmed yet, 31 products and services in scope

Cisco’s advisory cisco-sa-php-october26-Jj384Daq rates the flaws critical but, at the time of writing, names no product as vulnerable and none as confirmed safe. Eighteen products and thirteen cloud services are under investigation, among them Identity Services Engine (ISE), Catalyst Center, Catalyst SD-WAN Manager, Nexus Dashboard Insights, Expressway Series, AppDynamics On-Premises, Secure Access, Umbrella and Webex. Cisco states no workarounds exist and will add bug IDs and fixed releases to the advisory as products are assessed.

Palo Alto Networks — all PAN-OS and Panorama versions affected

Palo Alto is the outlier: its advisory states that “all versions of PAN-OS and Panorama are affected” and that no special configuration is needed to be exposed. Bridgecrew, Cloud NGFW, Cortex XDR Agent, Cortex XSOAR, Cortex Xpanse and Prisma Access are not affected. Palo Alto scores the risk to its own products at CVSS-B 8.7 with high availability impact only, and 7.1 if management access is restricted to a jump host. Fixed PAN-OS releases had not shipped when this article was written. Interim protection relies on restricting management-interface access to trusted internal IPs and on Threat Prevention: Frontier Virtual Patching customers received Threat ID 543004 on the evening of 20 October, and Advanced Threat Prevention added IPS signatures 543004, 97622, 97623, 97624 and 97625 on 21 October.

Patch Checklist for Enterprise IT Teams

Rapid7 recommends treating this as an emergency, out-of-cycle update. The sequence below is the one we apply with customers.

• 1. Inventory every PHP installation. Not just web servers: containers, staging environments, CI runners, monitoring dashboards, internal wikis, and third-party appliances that bundle PHP. Unsupported branches (7.x, 8.0, 8.1) belong on the list; they are affected in all versions.
• 2. Prioritise internet-facing systems running Apache mod_php. That is the configuration where exploitation succeeds before application code runs.
• 3. Update to a fixed release — PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 — or your distribution’s patched package (Ubuntu, Debian and Alpine shipped fixes on day one; check RHEL, Amazon Linux and SUSE separately). For 8.1 and older, use a vendor backport or upgrade the branch.
• 4. Restart every PHP worker. PHP-FPM pools, Apache processes, container replicas. A patched binary that is not loaded protects nothing; confirm with php -v inside the running context.
• 5. Apply interim hardening where patching must wait — and treat it as exposure reduction, not a fix: set session.upload_progress.enabled=0; on PHP 8.5 set fatal_error_backtraces=0; cap request size, multipart part counts and nesting depth at the web server or WAF; do not use RLIMIT_AS or RLIMIT_DATA, which trigger the vulnerable allocation path. Do not rely on error_reporting, display_errors or @ suppression.
• 6. Check your security appliances against the vendor advisories above, and keep management interfaces off the public internet regardless of vendor status.
• 7. Hunt for signs of targeting: bursts of multipart requests followed by memory-limit errors or HTTP 500s, malformed or unusually large PHPSESSID cookies, unexplained PHP worker restarts. Their absence is not proof of safety. If a server was exposed during the attack window, rotate the credentials it held.
• 8. Avoid unofficial “fix” plugins and copied snippets. Patchstack warns that several circulating fixes are unverified and break sites.

The Lesson Beneath the Headline

PHP2Shell will be remembered for its scale, but the operational lesson is older and simpler. The organisations that handled 21 October calmly were the ones that could answer three questions within an hour: Where do we run PHP? Which version? Who owns each instance? Everything after that — the update, the restart, the verification — is routine when patch management is automated and asset inventory is current, and chaotic when it is not. A zero-day in a universal runtime does not create new weaknesses in your estate; it illuminates the ones already there.

Frequently Asked Questions

Sources: Patchstack · Help Net Security · Fortinet PSIRT FG-IR-26-186 · SecurityWeek · watchTowr · Rapid7. Vendor status reflects advisories as of 23 October 2026 and may change.