The security nightmare continues: what followed PHP2Shell

The PHP2Shell emergency releases arrived on 21 October. That same day, Node.js released security updates and Cisco disclosed eight grouped communications CVEs. On 22 October, Arista warned of a VeloCloud flaw it says attackers are already exploiting. PHP added a further warning about a narrower, unpatched issue on 23 October. Each demands a different fix. The immediate challenge is knowing which runtime or management plane is actually exposed, and getting the right update into service.

What will you learn from this article?

• What has changed since the original PHP2Shell disclosure.
• How the Node.js, Cisco and Arista flaws differ technically and in who can exploit them.
• What reports of exploit attempts do, and do not, establish.
• Which systems to check and what action each vendor recommends.

PHP’s third warning is still unpatched

The 21 October PHP update fixes CVE-2026-109618 and CVE-2026-109619, the two critical runtime flaws discussed in the earlier PHP2Shell article. PHP’s 23 October notice introduces CVE-2026-115560. The earlier emergency releases do not claim to fix this new issue, PHP says a full advisory and fix will come with its next regular bugfix release.

The new condition is specific. An application must configure session.serialize_handler as php_binary or php_serialize, switch it to php at runtime with ini_set() before session_start(), and still have session upload progress enabled. PHP describes a possible remote code execution path under that combination, but considers the setup unlikely in practice. It has not yet published a severity score or a full technical account. Applications that never change the serializer at runtime do not meet the stated condition.

For applications that do, PHP recommends session.upload_progress.enabled=0 until the next release. Operators who already disabled it as an interim PHP2Shell measure should leave it off. That setting addresses the newly described path, it is not a substitute for installing the 21 October fixes for the original two CVEs. PHP identifies 8.2.35, 8.3.36, 8.4.27 and 8.5.12 as the fixed releases for those flaws. The Dutch NCSC’s 23 October update likewise says the new issue appears unlikely to yield RCE in practice while continuing to urge prompt patching of the original pair.

Node.js: compressed data reaches memory it should not

The Node.js project released security updates on 21 October for its 22.x, 24.x and 26.x lines. The most direct code execution concern is CVE-2026-111497. In the bundled Brotli decoder, an invalid block switch was treated as a temporary need for more input instead of a permanent format error. The streaming decoder could then keep appending bytes to an eight-byte internal buffer and write beyond it. The project says this memory corruption can lead to a crash, memory disclosure or remote code execution.

There is an important boundary: merely running a Node.js server does not mean an attacker can send it a Brotli stream and reach this bug. An affected application must decompress attacker-controlled Brotli data using node:zlib or a path that invokes that decoder. A reported laboratory demonstration achieved code execution on one official Node.js 24 Linux arm64 build after several attempts, it does not establish exploitation across every architecture or a real-world compromise. Node.js rates the issue high and provides fixes in 22.23.4, 24.22.1 and 26.12.1. Its 24.22.1 release notes confirm the Brotli fix in that line.

The same release also fixes high-severity DNS and TLS verification problems. For example, dns.resolve*() could truncate a hostname at a NUL byte, so software that validated one string might resolve another. Other flaws involve noncanonical IP spellings and certificate hostname checks. Those paths need particular application behavior, but they make the update relevant beyond services that accept compressed uploads.

Cisco: eight CVEs

Cisco’s 21 October Unified Communications advisory covers eight CVE identifiers grouped by weakness class. The highest scores are 9.8 under CVSS v3.1 for groups involving resource lifetime and improper authentication. The list also covers cross-site scripting, input validation, SQL injection, access control, path traversal and exception handling. Cisco says each score is the maximum potential severity of the most impactful underlying issue in that group. It would be misleading to call all eight independent, proven remote code execution exploits.

The affected family includes Unified CM, its IM & Presence and Session Management editions, Unity Connection, Emergency Responder and Prime Collaboration Deployment. Cisco says Release 15SU5 is the first fixed release for the 15 line, operators on Release 14 must migrate to a fixed release. It lists no workaround that addresses the vulnerabilities, and says it is not aware of malicious use. That is still a reason to plan the upgrade: these systems sit close to an organization’s calling and collaboration infrastructure, where a rushed change can itself interrupt service.

Arista: vendor-confirmed exploitation

Arista’s 22 October advisory is the clearest active-attack story in this roundup. CVE-2026-114625 is a SQL injection issue in VeloCloud Orchestrator (VCO). On an affected system, someone with a valid portal session, even the lowest built-in Enterprise Read Only role, can gain operator privileges and impersonate a local “superuser operator.” Arista says the issue is known to be actively exploited. It rates it 9.9 under CVSS v3.1 and 9.4 under CVSS v4.0.

This is not an unauthenticated flaw. The attacker needs network access to the VCO web interface and a valid login. That boundary matters, but so does the destination: the orchestrator manages the SD-WAN environment. Arista says on-premises VCO 5.2.x before 5.2.3.18, 6.1.x before 6.1.3.10, and 6.4.x before 6.4.2.12 are affected. Hosted and Dedicated instances were affected but have already been patched by Arista, VeloCloud Edge and Gateway are listed as unaffected. On-premises operators should install the fixed release and review VCO web, application, system and database logs for suspicious activity. Restricting management access to trusted networks is an interim control, not the repair.

What does public exploit code prove?

Wiz and Calif describe working PHP2Shell chains against selected applications and configurations. A Node.js Brotli demonstration achieved code execution on one official build after repeated attempts. These results establish technical feasibility under the tested conditions. They do not tell us how reliably an arbitrary internet-facing service can be attacked, or whether a particular organization was breached. Public repositories and exploit videos should be assessed on that same basis.

Are attacks actually succeeding?

The answer depends on the product and on what “succeeding” means. Amazon’s MadPot sensors recorded a PHP2Shell attempt on 17 October, four days before the patch, and more attempts on 21 October. Amazon says the early payloads’ ability to compromise real systems was unclear. Cloudflare also observed attack traffic, while the Dutch NCSC said on 23 October that one report of a possible successful exploit abroad remained unconfirmed and that large-scale exploitation looked less likely than first estimated. Scanning, a blocked request, a crashing worker and a verified intrusion are different findings.

The Node.js code execution result above is a researcher demonstration, not a reported production breach. Cisco reports no known malicious use of its communications CVEs. Arista explicitly reports active exploitation of its VCO flaw, although its advisory does not identify a victim or describe a completed intrusion. None of those distinctions weakens the case for applying the vendor fixes. They tell incident responders where evidence exists and where it still needs to be gathered.

Why might a website be taken offline?

For an internet-facing PHP service that cannot yet be patched or meaningfully mitigated, the UK NCSC advises considering a temporary shutdown. That decision trades availability for reduced exposure while operators update, restart and verify the runtime. A precautionary shutdown does not establish that an intrusion occurred. It should have a clear owner and a testable path back online, especially for public services whose availability matters to users.

What should organizations do now?

Start with exposed VCO. Check whether you operate on-premises VeloCloud Orchestrator, what release it runs, who can reach its web interface and whether the log indicators in Arista’s advisory appear. Preserve evidence if compromise is suspected, then move to the fixed train release.

Finish the PHP2Shell deployment. Confirm the running PHP version on every web host, container and managed service, then restart long-lived workers after updating. For the new CVE-2026-115560, check the precise serializer-switch condition and disable session upload progress where it applies. Investigate suspicious activity back to at least 17 October where logs exist, do not mark a server compromised solely because a scanner touched it.

Find Node.js decoders, not just Node.js packages. Identify services that decode untrusted Brotli data, including request-body middleware and code that consumes compressed remote responses. Update affected 22.x, 24.x and 26.x runtimes to the project’s fixed releases, then verify the process was restarted. Review the other DNS and TLS fixes against code that validates or allowlists hostnames.

Schedule the Cisco upgrade as a service change. Inventory the six affected communications products, confirm whether they run Release 14 or 15, and plan the move to 15SU5 or another fixed release with a tested recovery path. Cisco’s advisory provides no configuration workaround.

The larger lesson

The disclosures span different attack surfaces. PHP’s new issue needs a rare session setup, Node.js needs attacker-controlled compressed data to reach its decoder, Cisco’s advisory groups internally discovered flaws without reported abuse, Arista’s management-plane flaw is already being exploited, but requires a login. A single severity number hides those differences.

The PHP Foundation and Cisco both describe AI-assisted work in their security processes. Faster discovery may shorten the time available to respond. Exposure still has to be established service by service. The proof is specific: the running version, a restarted process, the input path that was reachable, and logs covering the period before the fix. Without those, a closed CVE ticket records an intention, not a verified repair.

Sources

• PHP, October 2026 security notices
• Node.js, 21 October security releases
• Cisco, Unified Communications security hardening advisory
• Arista, VeloCloud Orchestrator security advisory 0199
• Amazon Threat Intelligence, PHP2Shell attempt timeline
• Dutch NCSC, 23 October PHP update