{"id":10191,"date":"2026-10-29T08:25:00","date_gmt":"2026-10-29T08:25:00","guid":{"rendered":"https:\/\/cybersecurityinfocus.com\/?p=10191"},"modified":"2026-10-29T08:25:00","modified_gmt":"2026-10-29T08:25:00","slug":"php2shell-will-persist-in-enterprise-environments-for-years","status":"publish","type":"post","link":"https:\/\/cybersecurityinfocus.com\/?p=10191","title":{"rendered":"PHP2Shell will persist in enterprise environments for years"},"content":{"rendered":"
\n
\n
\n
\n
<\/div>\n

Two critical vulnerabilities were announced last week in PHP<\/a>, the internet\u2019s most widely used web application runtime, and they came with the familiar warning to patch immediately. But CISOs will have to deal with the long tail of these flaws for years due to widespread PHP integration into third-party products with patching cycles customers don\u2019t control.<\/p>\n

NAS devices, firewalls, VPN gateways, printers, building management panels, industrial IoT devices, and human-machine interfaces (HMIs) inside operational technology (OT) networks have web panels powered by PHP runtimes that cannot be patched directly. And many of these runtimes have unsupported versions for which upstream patches are not available.<\/p>\n

Vulnerabilities in widely used technologies can linger for years, and some deployments never get patched because they sit inside products that are out of support but still in service. One year after Log4Shell was disclosed in December 2021, nearly three quarters of organizations still had assets vulnerable<\/a> to the critical flaw in the ubiquitous Log4j Java library, which remained a top attack vector in real-world attacks<\/a> throughout 2023.<\/p>\n

PHP2Shell (CVE-2026-109618<\/a> and CVE-2026-109619<\/a>) could be even worse than Log4Shell for enterprises that cannot identify and patch all their assets \u2014 and attacks are already under way. On Monday, CISA added both vulnerabilities to its Known Exploited Vulnerabilities catalog<\/a>, confirming active exploitation. Researchers had previously reported widespread scanning and attempted exploitation<\/a>, but no confirmed compromise of production systems.<\/p>\n

\u201cPHP2Shell has the potential to become a Log4Shell-scale event, but for a different reason,\u201d Sai Molige, senior manager of threat hunting at Forescout, told CSO via email. \u201cWith Log4j, the main problem was finding a library you didn\u2019t know you had. With PHP, much of the forgotten infrastructure will be found, but won\u2019t have an upstream fix.\u201d<\/p>\n

When patches for third-party appliances and software products can take weeks to arrive from vendors, security teams must reduce exposure by other means, both at the internet edge and inside internal networks. And that\u2019s only after building an inventory of impacted assets, which is not straight forward for these flaws.<\/p>\n

The patching challenges<\/h2>\n

The PHP project released PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35 as the official fixed versions, but relying on version numbers alone is not enough due to the way PHP is distributed. Most servers run Linux distributions that deliver application updates through their own package managers, including long-term support (LTS) distributions that bundle older PHP versions. In many cases, patches will have to be manually backported by package maintainers for those specific distros.<\/p>\n

For example, PHP 7.4, 8.0, and 8.1 are officially end-of-life, even though they\u2019re still widely used. The PHP developers published minimal source backports for those versions to help package maintainers, but PHP 7.3 and older were not covered at all. Vulnerability intelligence firm VulnCheck found that 42% of the 2.6 million internet-facing PHP hosts it scanned<\/a> were running end-of-life branches, including 27% on PHP 3.x through 7.3 and 15% on 7.4, 8.0, or 8.1.<\/p>\n

Obtaining the fix on LTS distributions requires different approaches depending on the bundled PHP version. On Ubuntu 22.04 it arrives as a free PHP 8.1 update; on Ubuntu 20.04 the PHP 7.4 fix requires a Pro subscription; on Debian 11 the fix for the bundled PHP 7.4 sits behind a Freexian extended-support contract; and on AlmaLinux 8 it arrives as a backport for the retired PHP 7.2, 7.3, and 8.0. Red Hat Enterprise Linux, SUSE, Alpine, and Amazon Linux each draw their own support boundaries and those determine whether a fix exists at all for different distro versions.<\/p>\n

The version numbers for backported patches can also be inconsistent with upstream versions, adding to the inventory challenges. For example, AlmaLinux\u2019s patched php-8.3.33-1.el10_2.alma.1 is below the upstream\u2019s fixed version number for that branch: 8.3.36. Therefore, a scanner that reads a PHP version banner could flag a host as vulnerable even when the distribution has applied the fix.<\/p>\n

On top of all that, there are pre-built container, virtual machine, and firmware images for all sorts of third-party enterprise products that have their own bundled runtimes and that are much harder to inspect using automated scanners.<\/p>\n

\u201cThe PHP team has done a good job in a horrible situation,\u201d said Eylam Milner, co-founder and CTO at software supply chain security firm Echo. \u201cThe problem for most companies is they don\u2019t know where they\u2019re running PHP. It\u2019s in base images and in components that bundle their own runtime, and a lot of it is on versions older than 8.2 that are past end of life.\u201d<\/p>\n

There are no public estimates on how many enterprise appliances or IoT and OT devices might run vulnerable versions of PHP, but they exist and some are reachable from the internet. Security firm Flare used internet scans from multiple sources that covered 2,220,231 service records from PHP hosts across 224 countries. In a regional sample across a single US state they identified NAS devices, VPN gateways, remote access portals, building automation systems, and physical access controllers<\/a>.<\/p>\n

\u201cOrganizations still view PHP as a basic application dependency, but it\u2019s often embedded deep inside appliances, hosting platforms, and upstream container images where day-one patching simply isn\u2019t an option,\u201d said Tom Kellermann, vice president of AI security and threat research at TrendAI. \u201cThe real battle isn\u2019t just the vulnerability; it\u2019s visibility.\u201d<\/p>\n

PHP is also found inside industrial devices that can be in use for a decade or more and for which firmware patches take time to develop and deploy. Some of these devices need to be isolated until fixes arrive.<\/p>\n

Vulnerability management firm Cogent Security scanned dozens of Fortune 500 customer environments on the PHP2Shell disclosure day and found 2,266 affected assets per company on average<\/a>, with 926 that were running the PHP service actively and 122 that were exposed to the internet.<\/p>\n

The company\u2019s assessment focused on servers and virtual machines, not hardware appliances and OT devices. This highlights that the problem for enterprises won\u2019t be the unavailability of scanners, but their lack of visibility inside all types of assets. As such, organizations will need a combination of strategies to discover all PHP installations in their environments: from versions reported by host-based package managers to network scanners and software bills of materials where available.<\/p>\n

Reducing exposure while waiting for patches<\/h2>\n

Having an up-to-date inventory is important, but a complete map of PHP installations does not solve the issue of runtimes bundled in third-party products, each with its own patching schedule and mitigation instructions that can range from disabling the web management interface to completely isolating the device on the network.<\/p>\n

Just to give a few examples, Palo Alto Networks scheduled updates for some of its PAN-OS devices for this week<\/a> and Siemens advised customers of its RUGGEDCOM APE1808 devices for industrial networks that are also powered by PAN-OS to follow Palo Alto\u2019s advisory. Delta Controls patched its enterprise building management platform enteliWEB<\/a>, but affected HVAC and room controllers are still awaiting firmware patches. Some NetModule IIoT and industrial routers from Belden are confirmed to be vulnerable but patches are still being developed.<\/p>\n

Until patches become available, which could take weeks in some cases, organizations will have to monitor the advisories for the third-party products they use and follow the temporary mitigations instructions for each of them. There will also likely be situations where some products have reached end of life and will never receive a patch, especially those supporting legacy applications organizations still need to keep operational.<\/p>\n

For a system that cannot be updated, the measures fall into three groups:<\/p>\n

Take the vulnerable web application off insecure network segments<\/p>\n

Put firewall controls in front of it<\/p>\n

Assess if a compromise may have already happened<\/p>\n

In some cases, management over HTTP or HTTPS might not be needed and the same functionality could be achieved over SSH or other protocols. For example, both Belden and Delta advise customers to disable the embedded HTTP server until patches become available. NetScaler advises customers to keep the management GUI and API reachable only from trusted administrative networks.<\/p>\n

As far as firewall detection rules go, there are some limitations. At the application layer, Web application firewalls (WAFs) can help, but they cannot block all PHP2Shell exploits that abuse multipart data uploads because they don\u2019t usually inspect the full body of a web request, unlike the PHP engine.<\/p>\n

A WAF can scan for known attack patterns, but it doesn\u2019t parse the internal structure of these form uploads deeply enough to catch all possible variations, so attackers can tweak the request formatting to potentially slip past the rules. For example, if a WAF looks only at the first few kilobytes of a request, an attacker can simply pad the beginning of their payload with junk data to push the malicious exploit code past the inspection limit.<\/p>\n

Furthermore, if an attacker manages to find the direct IP address of a backend system, they could completely bypass the WAF controls. That doesn\u2019t mean that WAF rules are useless, but they are not a silver bullet against exploits. On the cloud side, AWS<\/a>, Cloudflare<\/a>, and Microsoft Azure<\/a> offer WAF protection rules for PHP2Shell already and there are many local enterprise WAFs that have added detection as well.<\/p>\n

The other type of firewall protection is at the network layer via intrusion prevention systems (IPS). The issue with these firewalls is that they could be bypassed if they\u2019re not configured to decrypt HTTPS traffic. IPS vendors have already created detections: Palo Alto has Threat ID 543004; Check Point has IPS protection CPAI-2026-15172; Cisco Talos has Snort rules 67359 and 67360 and Suricata rules 3000650 to 3000652 are also available.<\/p>\n

But deploying patches and alternative mitigations does not help systems that have already been compromised. And the longer it takes to implement these measures the more likely it is that attackers might have compromised a server.<\/p>\n

\u201cThe PHP2Shell flaws went from scanning noise to confirmed remote code execution on a honeypot within days of the October 21 patches, and that gap is where most real damage happens,\u201d said Steve Povolny, vice president of AI strategy and security research at Exabeam. \u201cPlenty of sites weren\u2019t patched on day one. Some of those servers were probably exploited before anyone noticed, and installing the fix now does nothing about an intruder who got in last week. Patching closes the door. It doesn\u2019t tell you who is already inside.\u201d<\/p>\n

Any detection and prevention effort should be accompanied by an investigation of existing logs including web server access and error logs, PHP-FPM logs, WAF and reverse-proxy logs, CDN logs, EDR and process telemetry, DNS and egress logs, authentication logs, file-integrity monitoring, and cloud audit logs.<\/p>\n

How to know if you\u2019ve already been hacked<\/h2>\n

Things to look for in those logs are PHP_SESSION_UPLOAD_PROGRESS and a PHPSESSID cookie, multipart\/form-data sent to endpoints that do not accept uploads, unusually large or malformed multipart bodies, deeply nested field names, repeated POSTs from one source, and spikes in HTTP 500 errors.<\/p>\n

Admins should also look for PHP-FPM, Apache, or httpd worker processes spawning sh, bash, curl, wget, base64, or various code interpreters, unexpected child processes under the web service account, reverse shells, outbound connections from web workers, as well as new or modified .php files in web root directories, upload directories and plugin directories. Abnormal PHPSESSID cookie length or corruption, unusually large session files, and unexplained worker restarts or segmentation faults could also be signs of exploitation, according to researchers from security firm Xint.io<\/a>.<\/p>\n

\n<\/p><\/div>\n<\/div>\n<\/div>\n<\/div>","protected":false},"excerpt":{"rendered":"

Two critical vulnerabilities were announced last week in PHP, the internet\u2019s most widely used web application runtime, and they came with the familiar warning to patch immediately. But CISOs will have to deal with the long tail of these flaws for years due to widespread PHP integration into third-party products with patching cycles customers don\u2019t […]<\/p>\n","protected":false},"author":0,"featured_media":10192,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[],"class_list":["post-10191","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-education"],"_links":{"self":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts\/10191"}],"collection":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=10191"}],"version-history":[{"count":0,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts\/10191\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/media\/10192"}],"wp:attachment":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=10191"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=10191"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=10191"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}