{"id":31035,"date":"2026-11-03T14:00:25","date_gmt":"2026-11-03T14:00:25","guid":{"rendered":"https:\/\/www.kaspersky.co.uk\/blog\/php2shell-two-weeks-after-patches\/31035\/"},"modified":"2026-11-03T14:00:25","modified_gmt":"2026-11-03T14:00:25","slug":"php2shell-two-weeks-after-patches","status":"publish","type":"post","link":"https:\/\/www.kaspersky.co.uk\/blog\/php2shell-two-weeks-after-patches\/31035\/","title":{"rendered":"PHP2Shell: what we know about the threat two weeks later"},"content":{"rendered":"

Late October brought several unsettling cybersecurity stories all at once. Among these were two critical vulnerabilities in PHP, which potentially affected about 70% of websites<\/a> worldwide. CVE-2026-109618<\/a> and CVE-2026-109619<\/a> \u2014 dubbed PHP2Shell \u2014 could let attackers execute code on a server remotely, without authentication.<\/p>\n

On October 21, PHP\u2019s developers released emergency patches for the supported PHP 8.2\u20138.5 branches and for the unsupported PHP 7.4, 8.0, and 8.1. Experts predicted that attacks on vulnerable servers would start within 15 minutes of the updates going public. Amazon even reported<\/a> exploitation attempts four days before the patches came out. With all this in the news, some organizations sounded the alarm early. For example, in several countries, government service websites were taken offline<\/a> as a precaution. Even Wikipedia\u2019s project management and bug-tracking system suspended service.<\/p>\n

Nearly two weeks have passed since the updates came out, but according to Censys data<\/a>, of the 46 million scannable servers running a vulnerable PHP version, 29 million still contain the flaws. Right after the patches were published, we broke down each flaw in detail<\/a> and explained what companies<\/a> and everyday users<\/a> should do. In this post we cover what\u2019s known about the threat today, and what extra steps businesses need to take.<\/p>\n

What happened after the PHP2Shell patches<\/h2>\n

The news about critical PHP vulnerabilities set off a flurry of reactions. Researchers noted<\/a> a large number of exploitation attempts, and fresh exploits kept appearing in batches\u00a0\u2014 courtesy of AI. A Palo Alto Networks unit even reported a PHP2Shell attack on a government agency in Europe, though it later retracted<\/a> that statement. Solid evidence of how these vulnerabilities can actually be exploited only emerged later. On top of that, a third, unpatched one turned up.<\/p>\n

A vulnerability with no patch<\/h3>\n

On Friday, October 23, the PHP team warned about a new vulnerability \u2014 CVE-2026-115560<\/a> \u2014 which can be used for remote code execution. But attackers can only pull this off on systems with an \u201cunusual combination of configuration and application code\u201d. That configuration is so exotic that the developers decided against an emergency patch, and will close the vulnerability on the regular schedule. In the meantime, they advised users to disable the session.upload_progress.enabled<\/code> INI option.<\/p>\n

First signs of PHP flaws being exploited<\/h3>\n

Let\u2019s get back to the more serious threats. The most substantial confirmation of PHP2Shell exploitation in real-world attacks only came on October 24. Honeypot servers run by Adel Karimi of Perplexity running PHP 8.4.26 and presenting ordinary web pages recorded<\/a> successful attacks from two IP addresses. The observed exploit chain was consistent with CVE-2026-109618. There\u2019s an important caveat, though: the researcher\u2019s honeypot ran the Apache mod_php module, which is the configuration most convenient for attackers.<\/p>\n

Later, on October 26, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) added<\/a> both CVE-2026-109618 and CVE-2026-109619 to its Known Exploited Vulnerabilities (KEV) catalog. That confirmed the threat isn\u2019t just theoretical.<\/p>\n

Real-world breaches with PHP2Shell<\/h3>\n

On October 26, the technology company Dream reported that 25 firewalls and management servers had been compromised in the U.S., Japan, Taiwan, and South Korea. Three of them were in an environment presumed to be linked to U.S. government agencies. The attackers combined PHP2Shell with a Linux kernel vulnerability dubbed Fragnesia (CVE-2026-46300<\/a>). Upon gaining full administrative control, they were able to extract the password of an LDAP service account and steal the listing of users and groups, full network configuration, and private keys.<\/p>\n

Dream initially didn\u2019t name the device vendor. In its October 29 update, though, the company stated<\/a> that the systems were Palo Alto Networks devices running certain versions of PAN-OS. The vendor confirmed<\/a> attacks on management interfaces exposed to the internet. It urged customers to close public access to those interfaces, limit it to trusted internal IP addresses, and install patches.<\/p>\n

Why there are so few incidents<\/h2>\n

Exploits are multiplying, but no wave of breaches has materialized, and the possibility of mass compromise of PHP servers remains unconfirmed. Even in the Palo Alto case, the scale of the attack was minimal: out of about 19\u00a0000 devices found, the attackers picked just 240, which were running software versions their exploit could handle.<\/p>\n

As it turns out, the existing PHP2Shell exploits aren\u2019t one-size-fits-all. To exploit the vulnerabilities in a given environment, attackers have to account for the exact PHP build, memory settings, request handling, and application specifics. Still, the danger remains, so don\u2019t neglect protective measures.<\/p>\n

How to stay safe<\/h2>\n

The key advice stays the same: update. You can find the latest versions of the language on the PHP website<\/a>. But installing patches isn\u2019t enough. You also need to run a thorough audit of your systems and check every component that runs on PHP for signs of compromise.<\/p>\n

Why install the second round of PHP updates?<\/strong><\/h3>\n

Five days after releasing the emergency patches, the PHP developers published another round of fixes. The reason is that the updates that fixed PHP2Shell didn\u2019t cover the CVE-2026-111497<\/a> vulnerability in Brotli, a third-party library. Exploiting this flaw can lead to code execution when PHP processes a specially crafted compressed response from an external server. The builds from October 25 include a patched version of the library. The latest PHP versions are 8.2.35-1, 8.3.36-1, 8.4.27-1, and 8.5.12-1. The first attack exploiting this vulnerability was recorded<\/a> on October 26, so don\u2019t put off installing the updates.<\/p>\n

Threat detection<\/h3>\n

Possible signs of a PHP2Shell compromise include unusual POST requests that contain multipart\/form-data<\/code> media type, suspicious combinations of PHP_SESSION_UPLOAD_PROGRESS<\/code> and upload parameters, atypical request sizes and request bursts, and HTTP 500 errors accompanied by PHP out-of-memory messages.<\/p>\n

Kaspersky solutions can help you spot the threat at different stages of an attack.<\/p>\n