PHP2Shell and Cisco products: security status and actions

As of 22 October 2026, 14:34 CEST / 12:34 UTC. Cisco classifications refer to interim advisory version 1.1, last updated on 22 October at 01:24 UTC.

Two critical PHP vulnerabilities disclosed on 21 October 2026 also matter to network and security teams. CVE-2026-109618 and CVE-2026-109619, collectively called PHP2Shell, can allow unauthenticated execution of attacker-controlled code. The PHP project has released security updates. Operators of Cisco environments must also establish which embedded components and services are affected. PHP security notice of 21 October 2026 [2]

Cisco now confirms that AI Defense in hybrid on-premises deployments and Umbrella are not vulnerable. Investigations into other products continue; the interim advisory does not yet identify any confirmed vulnerable products. Cisco PSIRT, version 1.1 of 22 October 2026 [1]

What causes the two PHP vulnerabilities

Both flaws are rated critical with a CVSS 4.0 score of 9.2. Neither authentication nor user interaction is required; exploitability depends on the runtime, configuration and processing path. PHP advisory for CVE-2026-109618 [3], PHP advisory for CVE-2026-109619 [4]

Apache with mod_php deserves particular attention: for CVE-2026-109618, PHP describes demonstrated exploitation before application code executes. An application login check cannot protect that early processing path. PHP-FPM must not be categorically excluded either: the second advisory documents validated session lifecycle RCE under FPM. The two vulnerabilities have different prerequisites; findings about one attack path cannot be applied to every installation. Technical details of the OOM flaw [3], technical details of stale global state [4]

The privileges of the web process also matter to risk assessment. Code execution under that account initially grants access within its permissions. Whether an attacker can then reach other systems depends on factors such as stored credentials, file permissions and network segmentation. The CVSS score alone does not establish automatic compromise of the entire corporate network.

Which Cisco products are under investigation

Selected entries from “Products Under Investigation”, not confirmed vulnerable products:

Cisco does not yet specify product-level fixed releases or a complete workaround. For products absent from the investigation list, Cisco says initial data indicates they are not affected; this differs from an explicit confirmation. Further platforms appear in the complete Cisco product list [1].

Explicitly excluded: Cisco AI Defense (hybrid on-premises deployment) and Cisco Umbrella. Version 1.1 also still includes Umbrella in its investigation list. The specific statement under “Products Confirmed Not Vulnerable” is therefore the relevant confirmation; this editorial overlap should not be read as confirmed vulnerability.

Operators need to connect the current vendor status to their actual inventory. An entry saying “Cisco installed” is insufficient. Record the product, complete software build, operating model and web interfaces that are actually reachable. Include every node in a cluster and independently operated instances across sites.

Prioritisation should also reflect potential harm. An administrative service can be critical even when few people use it. Establish which configurations, identities and connections depend on each instance. This operational assessment complements the vendor status without prejudging an unresolved technical investigation.

Which PHP updates are available

The following fixed releases have been published for supported PHP branches:

These are versions of PHP itself. They are neither Cisco firmware versions nor proof that a particular appliance has already been fixed. Official PHP releases of 21 October 2026 [2]

PHP 8.1 and older branches are outside regular upstream support. Because of the severity, the PHP team has provided minimal source backports for 7.4, 8.0 and 8.1. Distributions and LTS vendors may also supply corrected packages. An exceptional fix does not restore general support for an obsolete branch. PHP guidance on updates and backports [2]

For vendor packages, the version string alone is therefore insufficient. A backported fix may be included without changing the PHP major version. Conversely, updating a host does not automatically update every embedded runtime or container image. Reliable evidence maps the package or product build actually deployed to both CVEs. NCSC-NL guidance on embedded runtimes and vendor backports [5]

For Cisco appliances, follow the documented vendor update path. Replacing PHP inside an appliance yourself is not a sound operational strategy: dependencies, integrity checks and subsequent updates would require separate assessment. If the mapping is unavailable, obtain a statement for the specific product release from the responsible support team.

How Cisco Talos and Snort support protection

The coverage section of the Cisco Talos post lists Snort SIDs 67359, 67360 and 67375. Its introduction explicitly identifies 67359 and 67360 as available in the Community Ruleset too. Check the installed ruleset and active policy to establish which rules are available and effective in your deployment. Cisco Talos on PHP2Shell and Snort coverage [6]

For a suitable Cisco Secure Firewall or Snort deployment, use the following acceptance checks:

1. 01

   Check the ruleset

   Does the installed package contain the required SIDs?

2. 02

   Check policy assignment

   Does the relevant web traffic actually traverse the intended intrusion policy?

3. 03

   Check the action

   Are detections only logged, or blocked in the intended operating mode?

4. 04

   Check visibility

   Is the content needed by the signature visible at the inspection point, particularly for HTTPS?

5. 05

   Check exceptions

   Do bypass, trust or other rules divert traffic around inspection?

6. 06

   Check operation

   Do legitimate requests still work after the change, and do relevant events reach monitoring?

These checks assess traffic protection. The patch level of the firewall and its management components remains a separate question. Operations teams should retain evidence for both the protection mechanism and the correction in each target system. The presence of a signature alone does not close the patch task.

What organisations should prioritise now

The joint statement by ENISA, CERT-EU and other European bodies calls for immediate action, prioritising internet-facing systems. It also recommends coordination with hosting and service providers. Joint European warning of 21 October 2026 [7]

A practical workflow for Cisco environments connects that guidance to operational dependencies:

Start with a reliable inventory. Collect the relevant instances in one working register. Each entry should include the complete version, reachable interfaces, technical owner, current vendor status and next review date. An “unknown” category is useful: it exposes missing information and prevents an unresolved case from being mistaken for a completed one.

Then reduce unnecessary reachability. Restrict administrative access to the sources that actually need it. Include paths from internal client networks, partner access and VPN connections. Before imposing a restriction, prepare a working administrative recovery path. Otherwise, a well-intended block can make subsequent updates or recovery harder.

Create a specific update task. Name the target release, vendor evidence for both CVEs, prerequisites, backup, maintenance window and functional checks. For multiple nodes, include the documented update sequence. A ticket saying only “update PHP” is too vague for an integrated network platform.

Track cloud services separately. Record which components the provider operates and which your team operates. Closure requires a traceable provider statement. Self-hosted connectors, agents or adjacent systems may need additional assessment; a cloud status notice does not automatically cover them.

Treat recovery as a security decision. If an update fails, the fallback plan must account for the reopened risk. Rolling back to a vulnerable version can restore service, but also requires a fresh decision about reachability and temporary isolation. Include that condition in the change plan from the start.

Why temporary measures do not replace the update

PHP describes measures that restrict individual attack paths without providing complete protection. These include session.upload_progress.enabled=0 and, for PHP 8.5, fatal_error_backtraces=0, followed by restarting every worker. Hiding error messages does not eliminate the underlying memory flaw. PHP advisory on the limits of configuration measures [4]

The OOM guidance also changes memory limits alongside additional request and resource controls. These adjustments affect availability and capacity. They require a considered operational decision and are not blanket instructions for Cisco appliances. For self-managed PHP servers, follow the complete upstream guidance. PHP advisory on OOM mitigation [3]

If timely remediation is impossible, consider isolating an exposed service. The UK NCSC identifies temporary removal from service as an option until the risk can be effectively mitigated. Weigh the impact of an outage, remaining exposure and time to a fix for the specific service. NCSC warning on PHP [8]

How to assess a possible security incident

As of 21 October 2026, 14:00 UTC, Cisco Talos reported that it had not observed exploitation in the wild. This time-bound statement does not establish that any individual system is uncompromised. Cisco Talos on observed activity [6]

Review web, process and system events on a shared timeline. Unusual requests alone do not prove compromise. The assessment becomes more meaningful when unexpected processes, file changes, new outbound connections or unauthorised configuration changes appear in the same period. Account for normal operations: a legitimate import might explain high memory use without disproving other suspicious events.

Where there is concrete suspicion, preserve available logs and support data, record timestamps and coordinate further intervention with incident response and product support. An update corrects the vulnerability; it does not establish whether credentials were stolen or changes were made beforehand. Restoring access should consider both remediation and potential consequences.

When the task can be closed

Each instance should end with a documented decision: either applicable vendor confirmation that it is not affected, or a demonstrably installed fix for both CVEs. Temporarily isolated or unresolved systems remain open with an owner and review date.

After an update, acceptance includes the actual build on every relevant node, service status and checks of required functions. Record which temporary protections remain in place and the conditions for removing them. This produces a traceable technical state and a clear operational decision.

PHP2Shell illustrates why component risks must also be tracked in network environments. Organisations now need an accurate inventory, targeted access restrictions and a verified update path. Cisco’s evolving product assessment provides the vendor basis; implementation and evidence in the deployed environment remain the responsibility of the operating teams.