Active PHP2Shell attacks target exposed PAN-OS management interfaces

Active PHP2Shell exploitation means publicly reachable PAN-OS administration must be handled as a potential security incident rather than a normal patch cycle. A management-plane compromise can expose credentials, configuration backups, security policy and network topology, making the exposure far more consequential than an ordinary web-service flaw.

Take management access off the public internet immediately, or limit it to a tightly controlled administrative route such as a jump host, a controlled system used to access other administrative systems. Then install the relevant PAN-OS hotfix and assess whether the appliance was targeted while it was exposed. The vendor says both PHP flaws require no authentication or user interaction, and risk is greatest where external IP addresses can reach the management interface.

The wider PHP remediation effort remains urgent, as PHP2Shell flaws demand urgent updates to web-facing PHP explains. But a firewall or central management appliance isn’t just another web server. A management-plane compromise, affecting the services used to administer the appliance, can expose security policy, credentials, configuration backups, network topology and the controls used to administer much of the estate.

What happened

Palo Alto Networks’ advisory, updated on 29 October 2026, says it has observed active exploitation of CVE-2026-109618 and CVE-2026-109619 against internet-exposed PAN-OS management interfaces. CVE, or Common Vulnerabilities and Exposures, is the identifier system used to track publicly disclosed security flaws. The vulnerabilities are collectively known as PHP2Shell.

Both are memory-corruption issues in PHP’s error handling. CVE-2026-109618 concerns handling after an out-of-memory condition interrupts a request while internal memory is incompletely initialised. CVE-2026-109619 concerns stale state that survives after its backing memory has been freed and is then used by another request. The PHP project and Palo Alto Networks confirm that the practical consequence can be unauthenticated remote code execution.

Confirmed fact: Palo Alto Networks says the affected PAN-OS surface is the management web interface: the HTTPS web UI and XML API. A normal dataplane interface, which carries ordinary network traffic, is affected only if a management profile is attached to it. GlobalProtect portal, gateway and Clientless VPN (virtual private network) are not affected by this issue; neither is Captive Portal.

Analysis: scope matters more than the product label. Many organisations avoid exposing a dedicated management port but still allow HTTPS administration on a dataplane interface for convenience. That is exposure in this case. A management profile doesn’t become harmless because it sits on an interface carrying ordinary traffic.

Timeline: the risk has changed, not merely the patch list

• 21 October 2026: the PHP project issued fixed releases for the supported PHP branches, while the UK National Cyber Security Centre (NCSC) urged organisations to identify PHP installations and prioritise internet-facing systems.
• 21–22 October: Palo Alto Networks deployed remediations for the previously affected Cortex XCORE SaaS and WildFire Cloud services.
• 29 October: Palo Alto Networks updated its product advisory to state that active exploitation targeting internet-exposed management interfaces had been observed.

There is an important limit to what has been publicly confirmed. Palo Alto Networks has confirmed attacks against exposed management interfaces, but its advisory does not publicly attribute the activity, identify victims, quantify compromises or publish appliance-specific indicators of compromise. Don’t fill that gap with reassuring assumptions. An exposed, unpatched management interface should be assessed as potentially targeted.

Root cause and affected PAN-OS estate

Exposure determines the practical urgency: a reachable management service provides the unauthenticated attack path that matters.

The underlying weakness is in the bundled PHP component, not a conventional PAN-OS authentication bypass. Palo Alto Networks says a vulnerable supported PAN-OS build needs no special configuration to be affected. Exposure determines the practical urgency: a reachable management service provides the unauthenticated attack path that matters.

The issue applies to PAN-OS on PA-Series and VM-Series firewalls, and to Panorama virtual and M-Series appliances. Palo Alto Networks lists affected versions below the following fixed hotfixes:

There is a timing caveat worth noticing. As of the 29 October advisory update, Palo Alto Networks marked PAN-OS 11.1.7-h12 with an estimated availability date of 30 October 2026. Administrators on that train shouldn’t leave public management access in place while waiting: restrict access now, then either use an already available supported fixed route where operationally viable or install the announced hotfix once released and validated. Unsupported PAN-OS versions need an upgrade to a supported fixed release.

Impact: why management-plane exposure is the central issue

Firewall management interfaces are sometimes left publicly reachable for small IT teams, managed-service arrangements or emergency access. It may be understandable, but it is a poor trade-off during active exploitation of an unauthenticated code-execution flaw in the management stack. A VPN, bastion host or tightly restricted private administrative network adds friction. It also removes the broad anonymous reachability that makes this incident dangerous.

Palo Alto Networks rates product impact as critical where the management interface is internet-accessible, with a CVSS-BT score of 9.2. CVSS-BT refers to the Common Vulnerability Scoring System’s Base and Threat metrics. It says restricting access to a jump box reduces the assessed severity. That isn’t a substitute for patching, but it is a useful prioritisation signal: access restriction can reduce risk faster than a firmware change window can be arranged.

Detection and response: patching is necessary, but not the whole response

Start with an exposure inventory, not just a version report. Identify every PA-Series, VM-Series and Panorama management endpoint; determine whether the dedicated management port or any dataplane interface with a management profile is internet-reachable; and record the exact PAN-OS build. Include disaster-recovery, lab and dormant appliances. Public management access often survives longest in those corners.

Before and during remediation, preserve relevant logs. Review management-plane access records, administrative account activity, configuration changes, API activity, unexpected reboots and unusual outbound connections from the appliance or its management network. Compare the running configuration with a known-good version, particularly administrator accounts, authentication settings, service routes, certificates, log forwarding and management profiles. Don’t tidy away an unexpected change as configuration drift; investigate it as a potential security event.

Threat Prevention can provide additional protection, but only under specific operational conditions. Palo Alto Networks says relevant protections require management traffic to be routed through a dataplane port, decrypted for inspection and subject to threat prevention policy. Its advisory lists Threat ID 543004 and a set of later IDs in Applications and Threats content versions 9162, 9163, 9164 and later. This is defence in depth, not a reason to leave the dedicated management port publicly exposed or defer the hotfix.

The broader PHP estate needs attention too. The PHP project’s fixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1 and earlier are out of normal project support, although some operating-system and long-term-support suppliers may backport the corrections. The NCSC advises UK organisations to discover PHP across infrastructure, prioritise internet-facing systems and consider taking systems offline if they cannot be updated or accept the temporary exposure-reduction measures.

Those temporary PHP measures are not a complete fix. The PHP project is clear that updating is the only safe choice. The same applies to appliance owners: containment buys time and narrows exposure, but it does not remove vulnerable code.

What organisations should change after this incident

The immediate lesson is straightforward: public firewall administration should be exceptional, short-lived and heavily controlled, not a permanent convenience feature. Put management interfaces on private administrative networks wherever possible. Where remote access is essential, use a managed jump host or VPN with strong authentication, source restrictions and monitoring. Make external exposure testing part of regular control validation, not a one-off architecture review.

The less comfortable lesson concerns product inventories. PHP is not only something web-development teams run deliberately; it is embedded in appliances, control panels, management systems and bundled application stacks. The NCSC specifically warns organisations to monitor third-party products that bundle PHP. Cisco’s contemporaneous product review shows how uneven appliance impact can be: some named Cisco products required fixes or workarounds, while a long list was confirmed unaffected. Asset discovery has to extend beyond servers labelled “PHP”.

For Channel Islands and UK organisations relying on a small internal team or an external provider, establish who is responsible for checking management-plane exposure, applying PAN-OS hotfixes and conducting compromise assessment. “The network provider manages the firewall” isn’t an answer unless it comes with a current version, an exposure statement and an agreed remediation time.

This is urgent, but it isn’t mysterious. Remove public reachability, patch to the exact fixed PAN-OS build for the maintained train, enable compensating protections where the traffic path supports them, and investigate exposed appliances for signs that the incident began before the maintenance window.