On October 21, 2026, the PHP security team released emergency updates for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, collectively known as PHP2Shell. The flaws sit in the PHP runtime itself rather than in any specific application, exposing a broad range of PHP-based applications. Depending on the vulnerability and the conditions required for exploitation, an unauthenticated attacker could execute arbitrary code on an affected server or access sensitive information from its memory. As of October 26, multiple security organizations have reported exploitation attempts, and public proof-of-concept exploits are available.
Nozomi Networks products are not affected by either CVE because they do not use PHP. We are tracking the vulnerabilities and updating our security content to help customers identify potentially affected assets and investigate suspicious network activity. Customers can use Nozomi Networks Vantage and their deployed sensors to review asset inventory, vulnerability information and relevant security alerts.
PHP2Shell Is Not Log4Shell
The name invites comparison, but the two differ in an important way. Log4Shell could be exploited through a relatively simple malicious string. PHP2Shell involves complex memory-corruption vulnerabilities, where successful exploitation depends on the targeted component, PHP configuration, memory layout, and security protections. Critical severity doesn’t always mean straightforward exploitation, and building a reliable exploit can be significantly more challenging than exploiting Log4Shell. That said, public exploit code continues to circulate, so exposed, vulnerable PHP installations should be treated as an urgent priority.
What CVE-2026-109618 and CVE-2026-109619 Do
Both flaws involve how PHP manages memory during request processing, particularly when an unexpected error interrupts normal execution. This can leave memory in an unsafe state that an attacker can exploit with specially crafted HTTP requests.
- CVE-2026-109618 involves improper memory handling during out-of-memory conditions and request cleanup and could lead to remote code execution or disclosure of sensitive process memory. Patches for CVE-2026-109618 fixes different weaknesses in PHP's out-of-memory handling.
- CVE-2026-109619 occurs when previously allocated memory remains referenced after it has been released and could lead to remote code execution through corrupted internal state. Patches for CVE-2026-109619 fixes multiple instances of a recurring pattern, in which request-scoped state is trusted beyond its valid lifetime, affecting error handling, session management, serialization, and other components.
Depending on the vulnerability and the PHP configuration.an attacker could run code with the permissions of the PHP service, read memory containing credentials, tokens or API keys, modify application files, install malicious code, or use the server’s network connectivity to reach other systems. Notably, the application itself doesn’t need a coding error. An otherwise secure application is exposed if it runs on a vulnerable PHP runtime.
Affected and Fixed PHP Versions
The vulnerabilities affect PHP versions dating back to PHP 5.4. The PHP security team has released fixes for supported branches:
Two caveats matter here:
- Linux vendors including Debian, Ubuntu and Red Hat often backport security fixes without changing the upstream version number, so an asset may report a version that looks vulnerable even though the package is already fixed. Check installed package versions against your OS vendor’s advisory before drawing conclusions.
- PHP 8.1 and earlier no longer receive normal security updates. The PHP security team has published minimal source backports for 7.4, 8.0 and 8.1 for organizations that maintain their own builds, but these don’t restore full support. Migrate to a supported version or obtain fixes through a maintained distribution or long-term support vendor.
Why This Matters for OT and IoT Environments
PHP is usually associated with websites, but it also shows up in industrial and operational environments: device and appliance web-management interfaces, manufacturing execution system portals, historian reporting interfaces, building and facility management applications, network management platforms, remote maintenance portals, and legacy web applications supporting operations. These can run on servers, embedded Linux devices, virtual machines, or vendor-managed appliances.
An affected system doesn’t need a direct connection to industrial controllers to create risk. A compromised management server can give an attacker credentials, operational data, or a path to additional systems. We recommend prioritizing by exposure and operational impact:
- Critical: Internet-facing PHP services, especially those with access to OT networks. Patch immediately and restrict external access until remediated.
- High: PHP applications in industrial DMZs or management networks. Patch urgently and review network communications.
- Medium: Internal PHP services with limited network access. Schedule expedited remediation.
- Review: Assets with unknown PHP versions or vendor-managed software. Verify versions and obtain vendor guidance.
For critical industrial systems, coordinate updates with operations teams and equipment vendors to avoid unintended service interruptions.
Finding Potentially Affected Assets with Nozomi Networks
Identification matters as much as detection, because for every active exploit there may be many vulnerable systems that haven’t been touched yet. Nozomi Networks vulnerability content includes both CVEs along with affected and fixed PHP versions. Where enough software-version information is available, Vantage automatically tags assets with the relevant vulnerability, so you can easily identify affected assets, prioritize exposure and importance, and track remediation.
NOTE: Software version data can come from several sources. Nozomi Guardians passively identify PHP versions from network traffic, most commonly the HTTP X-Powered-By response header (for example, X-Powered-By: PHP/8.4.2). However, relying solely on network visibility has limitations as fields like: the header are optional and often disabled, proxies and gateways may strip or alter them, encrypted traffic hides could mask them unless decrypted, and a server may run multiple PHP versions. A reported version also doesn’t tell you whether a vendor backported the fix. In addition to network monitoring, agents such as Nozomi Arc can read installed software, including PHP versions, directly from the host, and supported integrations with endpoint management tools, vulnerability scanners, and asset inventory systems can supply further detail. In every case, a missing PHP version doesn’t mean an asset is unaffected and installed-software details should be validated against the vendor’s advisory.
Customers with Vantage IQ can also run the /php2shell-scan slash command to assess potential exposure across their Vantage environment. See the Security Advisory, PHP2Shell Exposure Assessment with Vantage IQ, for details.
Detecting and Hunting for Exploitation
Different detection methods provide complemntary visibility into potential exploitation activity. Combining software inventory, network monitoring, server logs, and endpoint telemetry helps build a more comprehensive picture. Two scenarios may benefit from different types of evidence.
- If an attacker achieves remote code execution, look for PHP or web-server processes launching command shells, unexpected commands run by the web-service account, downloads of scripts or executables, attempts to read credentials or sensitive configuration files, and connections from web servers to unfamiliar external destinations or into restricted networks.
- Memory disclosure is harder to catch. One demonstrated attack path exposes PHP process memory without launching a process or running an operating system command, so detections that depend on malicious process creation may miss it. Network and web application monitoring may still offer clues, such as unusual HTTP POST or multipart requests, repeated abnormal requests to PHP applications, malformed responses and spikes in HTTP 500 errors. Unexpected outbound connections or new communication paths between web servers and internal systems are also worth investigating.
These behaviors can have legitimate explanations, so evaluate them together rather than treating any one as proof of compromise. Detection coverage depends on deployed sensors, enabled content, traffic visibility and the PHP configuration involved, H2: Remediation
Updating PHP remains the recommended fix:
- Apply the update. Move to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or install the applicable package update from your distribution or application vendor.
- Restart everything that loads PHP. That includes Apache, PHP-FPM, long-running workers and application containers. For containerized environments, rebuild and redeploy using an updated PHP runtime.
- Reduce exposure where you can’t patch yet. Restrict access to affected services, remove unnecessary internet-facing services, limit access to administrative interfaces, apply web application firewall protections, and review segmentation between web applications and OT networks.
- Consider temporary PHP mitigations. For CVE-2026-109618, set memory_limit=-1, restrict request sizes and file-upload limits, and avoid RLIMIT_AS and RLIMIT_DATA. For CVE-2026-109619, set session.upload_progress.enabled=0, set fatal_error_backtraces=0 on PHP 8.5, and restart workers. These settings can affect behavior, resource use, and availability, so test them first, and see the PHP security advisory for details and limitations. They do not fully eliminate the vulnerabilities.
- Validate. Confirm that installed packages include the fix, that active processes are running the patched runtime, that containers and images were rebuilt, that vendor-managed devices received firmware or software updates and that previously identified assets have been reassessed. Review logs for signs of earlier exploitation.
Because public exploit code is circulating, avoid running unverified proof-of-concept or mitigation scripts from unknown sources.
Staying Ahead of PHP2Shell
The Nozomi Threat Intelligence subscription helps customers identify affected assets and prioritize remediation, and our researchers are using advanced AI capabilities to investigate exploitation scenarios and expand detection coverage as new findings emerge. As a founding partner of Anthropic’s Critical Infrastructure Defense Program, we’re committed to turning AI-driven security research into practical protection for critical infrastructure.
Customers who need help reviewing asset information, vulnerability results or alerts can contact Nozomi Networks Support through their normal channels. For suspected compromise, follow your incident response procedures and engage your security response team. We’ll continue to update this post as we learn more.
