❌

Normal view

PHP2Shell: what we know about the threat two weeks later | Kaspersky official blog

3 November 2026 at 14:58

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 worldwide. CVE-2026-109618 and CVE-2026-109619 β€” dubbed PHP2Shell β€” could let attackers execute code on a server remotely, without authentication.

On October 21, PHP’s developers released emergency patches for the supported PHP 8.2–8.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 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 as a precaution. Even Wikipedia’s project management and bug-tracking system suspended service.

Nearly two weeks have passed since the updates came out, but according to Censys data, 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 and explained what companies and everyday users should do. In this post we cover what’s known about the threat today, and what extra steps businesses need to take.

What happened after the PHP2Shell patches

The news about critical PHP vulnerabilities set off a flurry of reactions. Researchers noted a large number of exploitation attempts, and fresh exploits kept appearing in batchesΒ β€” courtesy of AI. A Palo Alto Networks unit even reported a PHP2Shell attack on a government agency in Europe, though it later retracted 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.

A vulnerability with no patch

On Friday, October 23, the PHP team warned about a new vulnerability β€” CVE-2026-115560 β€” which can be used for remote code execution. But attackers can only pull this off on systems with an β€œunusual combination of configuration and application code”. 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 INI option.

First signs of PHP flaws being exploited

Let’s 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 successful attacks from two IP addresses. The observed exploit chain was consistent with CVE-2026-109618. There’s an important caveat, though: the researcher’s honeypot ran the Apache mod_php module, which is the configuration most convenient for attackers.

Later, on October 26, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) added both CVE-2026-109618 and CVE-2026-109619 to its Known Exploited Vulnerabilities (KEV) catalog. That confirmed the threat isn’t just theoretical.

Real-world breaches with PHP2Shell

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). 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.

Dream initially didn’t name the device vendor. In its October 29 update, though, the company stated that the systems were Palo Alto Networks devices running certain versions of PAN-OS. The vendor confirmed 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.

Why there are so few incidents

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Β 000 devices found, the attackers picked just 240, which were running software versions their exploit could handle.

As it turns out, the existing PHP2Shell exploits aren’t 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’t neglect protective measures.

How to stay safe

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

Why install the second round of PHP updates?

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’t cover the CVE-2026-111497 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 on October 26, so don’t put off installing the updates.

Threat detection

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

Kaspersky solutions can help you spot the threat at different stages of an attack.

To learn more about how our solutions detect attempts to exploit PHP vulnerabilities, read our expert blog, Securelist.

The web’s having a rough week. Here’s how to browse safely

27 October 2026 at 13:22

You recognize the website. You’ve visited it before. You may even have it bookmarked. Then it asks you to do something unusual: install an update, allow notifications, or run a command to prove you’re human.

Stop and check first. A website you trust can still display instructions you shouldn’t follow. Our researchers have documented attacks in which criminals hacked legitimate websites and used them to deliver fake verification pages that trick visitors into installing malware.

Within the same week, serious problems emerged in several parts of the web’s security infrastructure. Attackers were exploiting two flaws in PHP, researchers disclosed a critical flaw in Brotli software used by Node.js, and eight compromised security certificates raised concerns about how browsers and apps verify websites. The incidents have different causes and levels of risk, but their timing makes this an unusual cluster.

PHP is used by about 7 in 10 websites whose underlying programming language is known. Node.js is used by 7.4% of websites with an identified web-server technology, according to W3Techs. Both run websites behind the scenes, so flaws in them can put the sites that rely on them at risk. Most browsers have blocked the certificates, though updates may still be needed for other software and devices.

These problems don’t mean you need to stop browsing. But keep your software and security protection up to date, and be wary of unexpected requests.

How to stay safe when browsing

Check the website’s address, but remember that even the genuine site may have been compromised. The important question is whether the page’s instructions make sense. A familiar website may earn your visit, but that doesn’t mean you should automatically let it run software on your device.

In documented campaigns, malicious instructions appeared on legitimate, hacked WordPress websites, not just lookalike domains.


Safer. Cleaner. Ad-free browsing.


A secure connection doesn’t guarantee that a page is safe, either. HTTPS protects the connection between your browser and the site. Browser protections against dangerous content are a separate layer. A page asking you to install software or enter sensitive information still deserves scrutiny, even when the connection is encrypted.

Ask yourself: β€œDoes this request make sense for what I came here to do?”

Reading an article shouldn’t require opening PowerShell. Watching a video shouldn’t require following a website’s instructions to β€œrepair” your computer. These are familiar themes in ClickFix attacks, which disguise malicious commands as routine verification or troubleshooting steps.

You can’t patch someone else’s web server, but you can keep the software on your own device updated. Turn on automatic updates for your operating system, browser, and applications where available, and don’t repeatedly postpone installing them. Updates fix security flaws that criminals could otherwise use to access your files or accounts.

Keep your browser’s phishing and malware protection enabled, too. Free browser extensions like Malwarebytes Browser Guard warn about known dangerous websites, malicious downloads, and clipboard hijacking. Treat those warnings as a reason to leave, not as another obstacle to get round. These checks are a useful layer of protection, but they can’t certify that every unflagged page is safe.

Use strong, unique passwords stored in a password manager, and enable multifactor authentication on important accounts. These measures help protect your accounts from unauthorized access.

If a request involves running code or making changes to your device, verify it independently. If a website claims your browser needs updating, close the prompt and check through the browser’s own settings. If it says an account or service needs attention, check through the official app, help page, or support channel that you open yourself.

Criminals often present the harmful step as the thing that will let you do what you came to do: fix the connection, enable the player, or complete the security check. The frustration of being blocked can make it tempting to follow their instructions.

Use up-to-date, real-time anti-malware protection on your devices to help stop malware from wreaking havoc or stealing your information.

Watch for unexpected content, downloads, redirects, and repeated login requests, even on familiar sites. If something looks wrong, leave the page. If you’re unsure, use Malwarebytes Scam Guard to check whether a request may be a scam and get possible next steps.


From reporting threats to removing them.

Cybersecurity risks should never spread beyond a headline. Keep threats off your devices byΒ downloading Malwarebytes today.

The web’s having a rough week. Here’s how to browse safely

27 October 2026 at 13:22

You recognize the website. You’ve visited it before. You may even have it bookmarked. Then it asks you to do something unusual: install an update, allow notifications, or run a command to prove you’re human.

Stop and check first. A website you trust can still display instructions you shouldn’t follow. Our researchers have documented attacks in which criminals hacked legitimate websites and used them to deliver fake verification pages that trick visitors into installing malware.

Within the same week, serious problems emerged in several parts of the web’s security infrastructure. Attackers were exploiting two flaws in PHP, researchers disclosed a critical flaw in Brotli software used by Node.js, and eight compromised security certificates raised concerns about how browsers and apps verify websites. The incidents have different causes and levels of risk, but their timing makes this an unusual cluster.

PHP is used by about 7 in 10 websites whose underlying programming language is known. Node.js is used by 7.4% of websites with an identified web-server technology, according to W3Techs. Both run websites behind the scenes, so flaws in them can put the sites that rely on them at risk. Most browsers have blocked the certificates, though updates may still be needed for other software and devices.

These problems don’t mean you need to stop browsing. But keep your software and security protection up to date, and be wary of unexpected requests.

How to stay safe when browsing

Check the website’s address, but remember that even the genuine site may have been compromised. The important question is whether the page’s instructions make sense. A familiar website may earn your visit, but that doesn’t mean you should automatically let it run software on your device.

In documented campaigns, malicious instructions appeared on legitimate, hacked WordPress websites, not just lookalike domains.


Safer. Cleaner. Ad-free browsing.


A secure connection doesn’t guarantee that a page is safe, either. HTTPS protects the connection between your browser and the site. Browser protections against dangerous content are a separate layer. A page asking you to install software or enter sensitive information still deserves scrutiny, even when the connection is encrypted.

Ask yourself: β€œDoes this request make sense for what I came here to do?”

Reading an article shouldn’t require opening PowerShell. Watching a video shouldn’t require following a website’s instructions to β€œrepair” your computer. These are familiar themes in ClickFix attacks, which disguise malicious commands as routine verification or troubleshooting steps.

You can’t patch someone else’s web server, but you can keep the software on your own device updated. Turn on automatic updates for your operating system, browser, and applications where available, and don’t repeatedly postpone installing them. Updates fix security flaws that criminals could otherwise use to access your files or accounts.

Keep your browser’s phishing and malware protection enabled, too. Free browser extensions like Malwarebytes Browser Guard warn about known dangerous websites, malicious downloads, and clipboard hijacking. Treat those warnings as a reason to leave, not as another obstacle to get round. These checks are a useful layer of protection, but they can’t certify that every unflagged page is safe.

Use strong, unique passwords stored in a password manager, and enable multifactor authentication on important accounts. These measures help protect your accounts from unauthorized access.

If a request involves running code or making changes to your device, verify it independently. If a website claims your browser needs updating, close the prompt and check through the browser’s own settings. If it says an account or service needs attention, check through the official app, help page, or support channel that you open yourself.

Criminals often present the harmful step as the thing that will let you do what you came to do: fix the connection, enable the player, or complete the security check. The frustration of being blocked can make it tempting to follow their instructions.

Use up-to-date, real-time anti-malware protection on your devices to help stop malware from wreaking havoc or stealing your information.

Watch for unexpected content, downloads, redirects, and repeated login requests, even on familiar sites. If something looks wrong, leave the page. If you’re unsure, use Malwarebytes Scam Guard to check whether a request may be a scam and get possible next steps.


From reporting threats to removing them.

Cybersecurity risks should never spread beyond a headline. Keep threats off your devices byΒ downloading Malwarebytes today.

How new PHP vulnerabilities threaten home users | Kaspersky official blog

22 October 2026 at 22:39

Yesterday, two critical vulnerabilities were disclosed in PHP, the scripting language used by many websites and online services: CVE-2026-109618 and CVE-2026-109619. Attackers can exploit them to remotely execute commands on any server running PHP, with no authentication required. The exploit has been dubbed PHP2Shell.

The PHP security team announced an upcoming emergency update on October 20 and released patches fixing the vulnerabilities the following day.

We’ve already covered the technical details of these vulnerabilities and explained what companies and server administrators should do. You may have safely skipped that news because you don’t run any servers β€” but unfortunately, the issue is not limited to businesses.

Nearly 70% of websites run on PHP, including services we use every day: wikis, online stores, smart devices with web interfaces, home network-attached storage (NAS), smart-home controllers, and much more.

Today, we explain how these vulnerabilities could affect you personally and what you can do to reduce the risks.

How the vulnerabilities can affect home users

Account and personal-data theft

The vulnerability allows an attacker to steal authentication tokens from server memory. These tokens essentially act like electronic passes β€” telling a website that the user has already signed in. As a result, an attacker may be able to access someone else’s account without entering a password or two-factor authentication code, putting messages, documents, delivery addresses, order histories, and other confidential information at risk.

Loss of files on home devices

If you have network-attached storage (NAS) or a video surveillance system at home that uses a vulnerable PHP version, it may also be at risk. Depending on what level of access they gain, attackers could potentially copy, delete or encrypt files they can access.

Malware infection

If an attacker gains access to a vulnerable website, they can use it in virtually any way they want: trick visitors into downloading a malicious file or clicking on a phishing link, display dangerous instructions, replace payment forms or login pages with malicious ones β€” the list goes on and on. As a result, someone visiting a legitimate website could not only lose access to their account, but also lose money or accidentally infect their device with malware.

Below are examples of services directly affected by the vulnerabilities.

Which services are affected by the PHP vulnerabilities

Jeedom

Jeedom is a smart-home platform that lets users control lighting, sensors, heating, blinds and home IoT devices. Attackers could abuse this in many ways: they could disable the alarm, track when the homeowner is away, access video from the door intercom, and more.

The developers confirmed that the new vulnerability affects their application, and have already released an emergency update β€” Jeedom 4.6.2. Users need to run the update twice for it to work. The developers say a fully fixed version for home users will be released in the coming days.

Websites we use every day

As mentioned above, PHP is used by roughly 70% of websites. This doesn’t mean every one of them is vulnerable: it depends on the PHP version in use and whether the site owners have already updated it. Many government websites in Europe have already suspended operations because of the new vulnerability.

Unfortunately, a website may still be vulnerable even if it appears to be working normally. An attacker could potentially take control of any legitimate website whose server hasn’t been patched yet. They could fake payment or login pages, host malicious files, or persuade users to download an β€œurgent update” that is actually malware.

Ordinary users have no reliable way to check whether such instructions or files are safe, so be sure to use reliable anti-phishing and antivirus protection. If you suspect that your data may have been stolen, check the active sessions in your account settings. If you spot suspicious activity or devices you don’t recognize, sign out of all active sessions and change your password. Use a password managerΒ β€” it can generate a truly strong, unique password that you won’t have to memorize yourself.

Computer games

Bad news for gamers: some video games whose servers use PHP are also at risk. If you don’t want attackers to get hold of your accounts, be sure to update the passwords for your gaming platforms, stores and accounts.

To buy time for updates, some developers temporarily took their services offline. Final Fantasy XIV, Pokemon Champions, games from Bandai Namco Entertainment, Uma Musume: Pretty Derby, Granblue Fantasy, Shadowverse: Worlds Beyond, and many others went into emergency maintenance. Nintendo Switch Online and the GOG and Steam stores were also affected.

Unfortunately, there’ve also been more drastic consequences. Yesterday, the developers of World Quest announced that the game would shut down permanently after 15 years: it relied on outdated infrastructure that would have been extremely difficult and costly to fix. For the same reason, the mobile game Please Save My Pandemonium! shut down after more than ten years of operation.

Home network-attached storage (NAS)

β€œHome clouds” have become popular in recent years for good reason: many users prefer to keep backups of their data at home rather than online. A number of companies make NAS devices, and at least three β€” QNAP, Synology and ASUSTOR β€” have said the vulnerabilities affect their products. An update has also been released for Unraid, an operating system for home servers, network storage and media servers.

QNAP

The manufacturer confirmed that the vulnerabilities affect several versions of its NAS operating systems β€” QTS and QuTS hero β€” as well as applications including QuMagie, Note Station 3 and certain versions of QVR Surveillance. A successful attack could put photos, documents, notes and camera recordings at risk.

At the time of publication of this blogpost, QNAP is still preparing updates, so the main priority is to temporarily disconnect NAS from the internet. QNAP recommends disabling port forwarding on the router β€” to prevent NAS from automatically opening ports β€” and allowing access to the management panel only from the home network orΒ through a VPN.

Synology

Both vulnerabilities have been officially confirmed in PHP packages 7.3, 7.4, and 8.0–8.4, as well as in Mail Station and Synology Calendar. Fixes have already been released for PHP, starting from version 7.4, as well as for Mail Station and Synology Calendar. PHP 7.3 won’t be fixed. The company separately notes that the PHP component built into its operating system cannot be reached from outside the device, so the risk of attack is very low.

ASUSTOR

ASUSTOR also officially confirmed both vulnerabilities, and immediately removed PHP 7, 7.3, 7.4, and 8.1 packages from App Central. The company recommends immediately backing up your data, removing older PHP packages, and using PHP 8.3 or 8.4.

Unraid

In today’s operating-system update, PHP was upgraded to version 8.4.27 with fixes for the vulnerabilities. The developers recommend that all users update to Unraid 7.3.4. Containers with their own PHP installation must be updated separately: the new PHP version in the operating system doesn’t replace PHP inside containers.

At the time of publication, we haven’t found public confirmation from other major manufacturers (such as TerraMaster, UGREEN, Buffalo, or Western Digital) that their devices are affected by these vulnerabilities β€” only user discussions on forums.

But the fact that only some NAS manufacturers have confirmed the problem so far doesn’t guarantee that your devices are safe β€” especially if they’re fairly old or come from a lesser-known or defunct manufacturer. In that case, first disconnect the devices from the internet while keeping them accessible only on the local network, and then investigate whether they’re vulnerable.

Nextcloud cloud storage

Nextcloud is a free, open-source platform for creating your own cloud storage, serving as an alternative to Google Drive, Dropbox, and Microsoft OneDrive. It lets you store and synchronize files across devices, share them with other users, and work with documents, photos, calendars and contacts. The data can be stored on your own server or NAS rather than on a third-party company’s servers.

If you store important data in Nextcloud, check how your cloud instance is configured. If you use Nextcloud All-in-One, update to version 14.4.1 where the vulnerability has already been fixed.

If your Nextcloud installation is configured differently, you need to update PHP yourself on the device or server.

How to protect your devices and data

  • Use phishing and malware protection. Our security solutionΒ automatically blocks phishing pages and malware, even when attackers place them on legitimate websites.
  • Keep an eye on updates. If you have network-attached storage, a smart-home system, a home server, a media server, or any other device with a web interface, first check the manufacturer’s website and install all available updates. If no update is available yet, temporarily disable internet access to the device.
  • Use strong passwords. Most people reuse the same password, or variations of it, across multiple websites. If an attacker finds one of those passwords on a vulnerable server, they may be able to compromise your other accounts as well. We recommend generating and storing strong, unique passwords in Kaspersky Password Manager so you don’t have to remember your credentials yourself. Be sure to enable two-factor authentication on all important accounts β€” ideally using one-time codes generated by the same password manager.
  • Keep an offline backup of important files. Don’t rely on cloud storage alone β€” make sure you keep a backup of all important documents on both a hard drive and an external device. For more information on how to make backups properly, see our article The internet remembers not quite everything.

What other risks can your home devices face? Read our articles:

PHP2Shell: Log4Shell at AI Speed β€” A CISO’s Perspective

22 October 2026 at 20:09
Redefining CISO Contract Blog Banner

When the PHP2Shell vulnerabilities became public, my thoughts went back to Log4Shell.Β  Five years ago, Log4Shell showed how difficult it can be to respond to a critical vulnerability in software used across countless applications and services. PHP2Shell presents a similar challenge. The technical details are different, but the need to quickly understand where you’re exposed and take action is very familiar.Β  I believe we should expect more incidents like this. AI is making it possible to discover vulnerabilities in widely used software at a speed and scale we haven’t seen before. As these capabilities become more accessible, we are likely […]

The post PHP2Shell: Log4Shell at AI Speed β€” A CISO’s Perspective appeared first on Check Point Blog.

PHP2Shell: Why many websites had to go offline

21 October 2026 at 18:14

If you’ve encountered websites in maintenance mode today, it may be a security precaution. Reports of attacks targeting two critical PHP vulnerabilities have prompted warnings to install emergency updates and consider temporarily taking affected services offline until they can be patched.

The vulnerabilities, known as PHP2Shell, are tracked as CVE-2026-109618 and CVE-2026-109619. Both carry a severity rating of 9.2 out of 10.

Why this matters

PHP is a programming language that works behind the scenes to power a large part of the web. It underpins WordPress, Drupal, Joomla, Magento, and many other applications, including software whose users may not realize PHP is involved.

Successful exploitation could let an attacker run malicious code on an affected server without logging in. That code would run with the permissions available to the PHP process, potentially allowing attackers to steal application data, alter website content, or establish a backdoor.

The PHP team says all PHP installations serving web requests are at risk. In some configurations, an attacker can trigger an exploit before the website’s own code even runs.

Cloudflare’s chief technology officer, Dane Knecht, has reported β€œearly attacks emerging,” while warning that firewall mitigations are only a stopgap.

Emergency patches are now available

The PHP team scheduled its emergency security updates for October 21 at 10:00 am ET (14:00 UTC). It has now released fixes in PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35, and urges users to update immediately. Administrators should check with their hosting provider or operating system vendor for the appropriate updated packages.

You may still encounter offline websites while administrators install the updates and check their systems.

CERT-EU recommends identifying PHP-based applications and patching as soon as possible. Where an immediate fix is not feasible, it advises considering isolation of internet-facing applications from public networks.

The risk may outlast today’s emergency

The longer-term concern is forgotten infrastructure: abandoned websites, unsupported applications, and connected devices with PHP-based management interfaces. Vulnerable installations may remain exposed if nobody maintains them or a vendor no longer supplies updates.

PHP 8.1 and older no longer receive routine security updates from the PHP project. Administrators using those versions should check whether their vendor supplies a fix or arrange an upgrade to a supported version.

Website owners should establish who updates their underlying PHP installation. Updating WordPress or its plugins is not the same as updating PHP. Hosting providers or server administrators may need to apply the fix.

For visitors, temporary downtime alone doesn’t mean a website has been breached. It may reflect a protective decision while its administrators install updates.

However, consumers need to be extra careful as a β€œtrusted website” may no longer be trustworthy, and not just because of PHP2Shell, but also because of eight compromised TLS certificates.

Shahak Shalev, Global Head of Scam and AI Research at Malwarebytes, said:

β€œThis is a goldmine for hackers. They can hijack real websites to take advantage of the site’s reputation to do things like phish people, serve malicious software from the trusted channel. The opportunities are endless.”

What to do

If you’re a website visitor:

  • Some websites may temporarily go offline while they are patched.
  • Watch for unexpected content, downloads, or redirects, and repeated login requests, even on familiar sites.
  • If something looks wrong, leave the page.
  • You don’t need to install PHP updates on your own device.

If you’re a website owner:

  • Ask your hosting or IT provider to confirm PHP fixes are installed, not just scheduled, across all your websites and applications.
  • If they can’t patch immediately, ask whether affected services should temporarily be taken offline.
  • If you manage your own servers, follow PHP’s update instructions.
  • Using unsupported PHP? Check for a vendor fix or upgrade to a supported version.

What Malwarebytes is doing

  • Helping keep you safe from hacked websites: Malwarebytes web protection and Browser Guard block known harmful sites, scam pages, and dangerous downloads. Our researchers are watching for websites compromised through these flaws so we can quickly add them to our block lists.
  • Updating our own websites: We use a managed hosting provider and are working with them to install the PHP fixes. We are closely monitoring our websites until the updates are in place.

Stop threats before they can do any harm.

Malwarebytes Browser Guard blocks phishing pages and malicious sites automatically. Free, one click to install. Add it to your browser β†’

PHP2Shell: Why many websites had to go offline

21 October 2026 at 18:14

If you’ve encountered websites in maintenance mode today, it may be a security precaution. Reports of attacks targeting two critical PHP vulnerabilities have prompted warnings to install emergency updates and consider temporarily taking affected services offline until they can be patched.

The vulnerabilities, known as PHP2Shell, are tracked as CVE-2026-109618 and CVE-2026-109619. Both carry a severity rating of 9.2 out of 10.

Why this matters

PHP is a programming language that works behind the scenes to power a large part of the web. It underpins WordPress, Drupal, Joomla, Magento, and many other applications, including software whose users may not realize PHP is involved.

Successful exploitation could let an attacker run malicious code on an affected server without logging in. That code would run with the permissions available to the PHP process, potentially allowing attackers to steal application data, alter website content, or establish a backdoor.

The PHP team says all PHP installations serving web requests are at risk. In some configurations, an attacker can trigger an exploit before the website’s own code even runs.

Cloudflare’s chief technology officer, Dane Knecht, has reported β€œearly attacks emerging,” while warning that firewall mitigations are only a stopgap.

Emergency patches are now available

The PHP team scheduled its emergency security updates for October 21 at 10:00 am ET (14:00 UTC). It has now released fixes in PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35, and urges users to update immediately. Administrators should check with their hosting provider or operating system vendor for the appropriate updated packages.

You may still encounter offline websites while administrators install the updates and check their systems.

CERT-EU recommends identifying PHP-based applications and patching as soon as possible. Where an immediate fix is not feasible, it advises considering isolation of internet-facing applications from public networks.

The risk may outlast today’s emergency

The longer-term concern is forgotten infrastructure: abandoned websites, unsupported applications, and connected devices with PHP-based management interfaces. Vulnerable installations may remain exposed if nobody maintains them or a vendor no longer supplies updates.

PHP 8.1 and older no longer receive routine security updates from the PHP project. Administrators using those versions should check whether their vendor supplies a fix or arrange an upgrade to a supported version.

Website owners should establish who updates their underlying PHP installation. Updating WordPress or its plugins is not the same as updating PHP. Hosting providers or server administrators may need to apply the fix.

For visitors, temporary downtime alone doesn’t mean a website has been breached. It may reflect a protective decision while its administrators install updates.

However, consumers need to be extra careful as a β€œtrusted website” may no longer be trustworthy, and not just because of PHP2Shell, but also because of eight compromised TLS certificates.

Shahak Shalev, Global Head of Scam and AI Research at Malwarebytes, said:

β€œThis is a goldmine for hackers. They can hijack real websites to take advantage of the site’s reputation to do things like phish people, serve malicious software from the trusted channel. The opportunities are endless.”

What to do

If you’re a website visitor:

  • Some websites may temporarily go offline while they are patched.
  • Watch for unexpected content, downloads, or redirects, and repeated login requests, even on familiar sites.
  • If something looks wrong, leave the page.
  • You don’t need to install PHP updates on your own device.

If you’re a website owner:

  • Ask your hosting or IT provider to confirm PHP fixes are installed, not just scheduled, across all your websites and applications.
  • If they can’t patch immediately, ask whether affected services should temporarily be taken offline.
  • If you manage your own servers, follow PHP’s update instructions.
  • Using unsupported PHP? Check for a vendor fix or upgrade to a supported version.

What Malwarebytes is doing

  • Helping keep you safe from hacked websites: Malwarebytes web protection and Browser Guard block known harmful sites, scam pages, and dangerous downloads. Our researchers are watching for websites compromised through these flaws so we can quickly add them to our block lists.
  • Updating our own websites: We use a managed hosting provider and are working with them to install the PHP fixes. We are closely monitoring our websites until the updates are in place.

Stop threats before they can do any harm.

Malwarebytes Browser Guard blocks phishing pages and malicious sites automatically. Free, one click to install. Add it to your browser β†’

PHP2Shell: How to Protect Your Server | Kaspersky official blog

21 October 2026 at 18:09

Two critical vulnerabilities have been discovered in the popular PHP programming language. The vulnerabilities, identified as CVE-2026-109618 and CVE-2026-109619, allow attackers to remotely execute code on a server running PHP without authentication. The language’s development team has released updates for all supported branches, but the first attempts to exploit the vulnerabilities were observed even before the patches were published. The exploit has been named PHP2Shell.

The architectures of popular marketplaces, e-commerce platforms, and learning management systems (LMS) are written in PHP. In addition, PHP is used in various content management systems (CMS) such as WordPress, Drupal, Joomla, and so on, which power most websites on the internet.

In this blogpost, we discuss CVE-2026-109618 and CVE-2026-109619 in detail, and explain how companies can protect their infrastructure. Read the Securelist expert blog to learn how events surrounding these vulnerabilities unfolded before the patch was released.

Vulnerable PHP versions

According to PHP web site, versions prior to 8.2.35, 8.3.36, 8.4.27, and 8.5.12 are vulnerable to CVE-2026-109618 and CVE-2026-109619. There are no official fixes for older branches. According to unofficial reports, the vulnerabilities also affect PHP versions starting with 5.4.0.

What makes CVE-2026-109618 and CVE-2026-109619 dangerous

Both vulnerabilities received a score of 9.2 on the CVSS v4.0 scale. They arise because, after a request is interrupted (for example, due to a memory shortage), PHP leaves invalid data in the memory buffer, and subsequently accesses it, allowing code to be executed on the server. One of the confirmed attack chains via CVE-2026-109619 exploits the `session.upload_progress` mechanism (which tracks file upload progress), which is enabled by default in PHP.

By exploiting these vulnerabilities, attackers can remotely execute code on the server with web server process privileges without authentication.

According to PHP developers, all installations of unpatched versions that process web requests are at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed. The greatest risk lies with mod_php: researchers demonstrated an exploit for it in which an unauthenticated request triggers the attack even before the application code is executed.

What businesses should do

We’ve compiled key recommendations from the PHP developers and experts at Kaspersky.

  • Update PHP to versions 8.5.12, 8.4.27, 8.3.36, or 8.2.35. Start with systems accessible from the internet. The source code is available on the PHP website. If PHP is installed from distribution packages or provided by your hosting provider, check for updated packages: Linux distributions and LTS vendors received patches in advance. If the server is managed by a hosting provider, ask them to apply the update.
  • Versions 8.1 and older no longer receive updates from the PHP project. Check with your distribution vendor or LTS support provider to see if backported fixes are available, or switch to a supported branch. For PHP 7.4, 8.0, and 8.1, the developers have prepared minimal source code backports for manual compilation. These can also be found on the PHP website.
  • Restart PHP-FPM or the web server so that the processes load the new code, and verify the version using the `php -v` command. If PHP was installed from distribution packages, check the package changelog: the version number may remain the same.
  • Check the logs from October 20. A warning sign is when the web server process is performing actions it shouldn’t (running command shells, curl, wget, and the like). Kaspersky solutions help detect malicious activity in a timely manner. Attempts to exploit the described RCE vulnerabilities on Linux and Windows machines can be detected using Kaspersky NEXT EDR Expert, while exploitation of PHP2Shell in network traffic is detected by Kaspersky Anti Targeted Attack (KATA) with the NDR module.

If an immediate update is not possible

Only the immediate installation of patches will fully resolve the issue, but if that isn’t possible, it’s recommended to implement temporary measures. PHP developers provide step-by-step instructions for each vulnerability.

Millions of PHP Instances Exposed - What Organizations Need To Do Right Now

21 October 2026 at 17:31

Two critical vulnerabilities in PHP (CVE-2026-109618 and CVE-2026-109619) have been published. Both vulnerabilities carry a severe CVSS score of 9.2 (more technical details are in the Unit 42 Threat Brief).Β 

This is not just another high-severity vulnerability disclosure, it marks the opening chapter in a massive acceleration of cyberthreats that will define the foreseeable future. Because PHP is widely used globally (by some estimates, more than half of all websites), the sheer scale of this is massive. Navigating this new reality demands immediate imperatives, including continuous, proactive vulnerability discovery before adversaries weaponize code, and a modern defense strategy that pairs traditional patching with real-time virtual patching. At a footprint of 22 million exposed instances, relying on manual remediation cycles alone is not a viable defense.

For context, exposures are typically in the thousands, for example around 50,000 potentially vulnerable exposed instances for recent NetScaler vulnerabilities, and about 16,000 exposed instances of BeyondTrust, potentially vulnerable to CVE-2026-1731. Pervasive open-source software introduces an exposure footprint on an entirely different order of magnitude.Β 

This situation illustrates what I shared in Defender’s Guide to the Frontier AI Impact on Cybersecurity. We’re officially in a new reality, and this is going to be an ongoing cycle.

An Accelerating Cycle

The latest frontier AI models are extraordinarily capable at finding vulnerabilities in code. We’ll see these models continue to surface critical issues at a pace faster than ever before.

But here’s the challenge: As soon as patches for vulnerabilities are available, attackers will reverse engineer the patch, locate the root flaw, and target them in near real time. It simply takes too long to apply patches to every system. This vulnerability deluge demands urgency and new technologies, such as virtual patching, are needed.

What Organizations Should Do Now

(1) Assess Your Open Source Inventory

Given the unprecedented speed at which new, critical vulnerabilities are being found with frontier AI, organizations need the ability to understand their true exposure at a moment’s notice. Attack surface management solutions have never been more critical for finding these blind spots across your entire codebase and supply chain. You can’t protect what you can’t see.

Additionally, services like Unit 42 Continuous Frontier AI Defense put defender-grade AI models in the hands of defenders to find and fix vulnerabilities before attackers can weaponize them.

(2) Prioritize Remediation Based on Reachability

You have to reduce what is reachable by attackers. You can't instantly patch everything everywhere, so prioritize what needs to be fixed first based on attack-path reachability. Secure what must be accessible to the public internet, and evaluate your environments to understand which of those exposed PHP instances carry the most immediate risk. For example, Cortex Xpanse and exposure management are great tools for determining reachability and automating remediation.

(3) Secure your AI deployments

While not the main focus for these PHP vulnerabilities, rapid deployment of AI across organizations is expanding the attack surface. All AI deployments must be secure AI deployments.

(4) Mitigate and Ensure Attack Protections

While you coordinate patching with your development teams, ensure best-in-class protections are in place to block the actual exploits. Mitigate against potential attacks immediately through proactive virtual patching and reducing overall exposure. Deploying high-fidelity virtual patches across your network and cloud security provides the mitigation layer necessary to give your teams the time they need to update the actual software safely.

Our new Frontier Virtual Patching capability delivered preemptive coverage for these PHP vulnerabilities ahead of today’s public disclosure. Additionally, Palo Alto Networks customers are protected from exploitation of these vulnerabilities by Advanced Threat Prevention available on our next-generation firewalls and Prisma Access.

(5) Deploy Real-Time Security Operations

Autonomous AI-driven attacks will drive attack lifecycles to minutes requiring every SOC to achieve single-digit mean time to detect (MTTD) and mean time to respond (MTTR).

The Path Forward: Institutionalize Defenses

This isn’t a one-and-done situation. With frontier AI compressing the patch-to-exploit window to minutes, assessing exposure, prioritizing reachability, mitigating and ensuring attack protections must become a continuous, automated motion.

This is a pivotal moment. While the scale of the challenge presented by frontier AI is real, I’m confident in our ability to solve it. Take the steps to secure your organization today, and build the foundation needed to ensure the advantage remains with the defender.

Mitigating Critical PHP Vulnerabilities (CVSS 9.2) at Machine Speed

When frontier AI models accelerate both vulnerability discovery and reverse-engineering of patches, traditional remediation creates an unavoidable window of exposure. Get started with Frontier Virtual Patching in Advanced Threat Prevention Plus to solve this structural delay.
Get Started

The post Millions of PHP Instances Exposed - What Organizations Need To Do Right Now appeared first on Palo Alto Networks Blog.

Critical RCE vulnerabilities in PHP (CVE-2026-109618, CVE-2026-109619)

21 October 2026 at 17:18

UPD 23.10.2026: added Kaspersky SIEM rules and events for developing custom detection rules or conducting threat hunting.

UPD 22.10.2026: added a description of how the Kaspersky Managed Detection and Response service detects the described malicious activity.

UPD 22.10.2026: added a description of how Kaspersky Vulnerability Management detects vulnerable versions of PHP.

Vulnerability overview

On October 20, 2026, the PHP security team published a preliminary notice regarding an upcoming emergency release that addresses two critical vulnerabilities (both rated 9.2 on the CVSS scale). The patches were released on Wednesday, October 21, 2026, at 14:00 UTC.

The release was expedited after information about the vulnerabilities was leaked to the public before the scheduled embargo was lifted. In a post on Hacker News, a user reported two RCE vulnerabilities in PHP, allegedly affecting all versions starting with PHP 5.4.0.

The vulnerabilities in question are CVE-2026-109618 and CVE-2026-109619. Shortly after the post appeared, researchers confirmed the existence of the vulnerabilities. Along with the leak of details, an exploit unofficially named PHP2Shell appeared online. In the leaked demo video, the exploit is shown in action on web servers running WordPress, MediaWiki, phpBB, Magento, Joomla, Laravel, Symfony, Drupal, and WHMCS β€” platforms that power many modern websites. The authenticity of the demonstration and the exact behavior of the exploit had not been independently verified at the time of publication.

According to the researcher who published the PoC, the vulnerabilities are related to the handling of the multipart/form-data MIME type in conjunction with the session upload progress mechanism (session.upload_progress) in the PHP core and fall under the categories of use-after-free and memory corruption. This means that the flaws cannot be fixed via application code, and the only fix is to update PHP on the server. The attack requires no authentication: an attacker with network access to a PHP application can execute arbitrary code with the privileges of the PHP process without needing to authenticate. Security advisories issued by the PHP team on October 21 confirm this information.

The vulnerabilities affect PHP versions 5, 7, and 8. As of this publication, branches 8.2 through 8.5 are supported. Older branches, including PHP 8.1, 8.0, 7.x, and 5.x, have reached the end of their lifecycle; however, due to the critical severity of the vulnerabilities, backported patches have also been released for versions 7.4, 8.0, and 8.1.

Sansec experts estimate that widespread exploitation could begin within 15 minutes of the update’s release. We strongly recommend that administrators responsible for publicly accessible PHP web servers take the following steps before the patch is available:

  1. Take an inventory of all PHP-based systems in your infrastructure (such as web servers, control panels, and third-party software).
  2. Disable upload-progress: set session.upload_progress.enabled = Off using the php_admin_flag in PHP-FPM pools.
  3. Block multipart requests on nginx and Apache servers.
  4. Consider temporarily isolating PHP applications that connect to the Internet until fixes are released.
  5. Be ready to install the patch immediately upon its release.
  6. Plan to migrate servers running unsupported versions (8.1 and earlier) to the latest PHP branch.

Detection by Kaspersky solutions

Kaspersky solutions detect the described malicious activity at various stages of the attack. Possible detection scenarios are listed below.

When an attempt is made to exploit these RCE vulnerabilities,Β Kaspersky Endpoint Detection and Response promptly alerts the user to suspicious actions performed in the context of a web server, on both Linux and Windows machines. This activity is detected by the following rules:

Detection of the PHP2Shell vulnerability exploit by KEDR

Detection of the PHP2Shell vulnerability exploit by KEDR

Exploitation of the PHP2Shell vulnerability in network traffic is detected by Kaspersky Anti Targeted Attack (KATA). This solution detects such activity with the following verdicts: Exploit.CVE-2026-109618.HTTP.C&C and Exploit.CVE-2026-109619.HTTP.C&C.

Detection of the PHP2Shell vulnerability exploit by KATA

Detection of the PHP2Shell vulnerability exploit by KATA

Kaspersky Endpoint Security, now available as Kaspersky Next, also detects malicious post-exploitation activity using the Behavior Detection component, with verdicts such as PDM:Exploit.Linux.Generic and PDM:Exploit.Win32.Generic.

Our Kaspersky Vulnerability Management solution detects vulnerable software versions using the Vulnerability scanning and Agentless black-box scanning components.

Detection of the PHP vulnerability in Kaspersky Vulnerability Management

Detection of the PHP vulnerability in Kaspersky Vulnerability Management


The Kaspersky Managed Detection and Response service detects the exploitation of the described vulnerabilities by monitoring activity characteristic of RCE:
  • Spawning of suspicious processes by the web server;
  • Creation of suspicious executable files in the web application directory;
  • Creation of suspicious scripts in the web application directory;
  • Creation of files with uncommon extensions in the web application directory;
  • Execution of reconnaissance commands by the web server process;
  • Execution of persistence commands by the web server process;
  • Delivery and launch of web shells on the web server.

Moreover, MDR detects other malicious activity not directly related to remote code execution.

To protect companies that use our Kaspersky SIEM system, the product repository includes rules that help detect the following malicious activity.

  • Execution of suspicious executable files by web server processes on Windows and Linux machines:
    • R300_04_Windows shell started by a web application
    • R152_08_A running Linux shell process has a suspicious parent process
  • Execution of reconnaissance commands by the web server process:
    • R286_05_Possible web-shell (Linux)

We also recommend monitoring the creation of scripts or executable files in the web server directory when developing your own detection rules or conducting threat hunting:

((DeviceEventClassID = '4663' AND DeviceCustomString1 ilike 'WriteData') OR DeviceEventClassID = '11')
AND match(FileName,'(?i).*\.(php|asp|aspx|ashx|jsp|js|jar|jse|dll|exe|bat|ps1|vbs|wsf|wsh|msi|msp|hta|cpl)$')
AND match(DestinationProcessName,'(?i).*(php-cgi|nginx|httpd|w3wp)\.exe')

Name = 'openat' AND has(SA.Nametype, 'CREATE')
AND
length(arrayFilter(x -> match(x, '(public_html|var/www|usr/local/apache2|usr/local/httpd|var/apache|srv/www|home/httpd/html|srv/http|usr/share/nginx/html|var/lib/pgsql/data|usr/local/mysql/data|var/lib/mysql|var/vsftpd|etc/bind|var/named)'), SA.FileName))>1
AND
length(arrayFilter(x -> match(x, '\.(aspx|asp|asmx|asax|ashx|jspx|jsp|js|phpt|php|phtml|pht|cfm|shtml|htaccess|fcgi|cgi|pl|py|sh)'), SA.FileName))>1

Critical RCE vulnerabilities in PHP (CVE-2026-109618, CVE-2026-109619)

21 October 2026 at 17:18

UPD 23.10.2026: added Kaspersky SIEM rules and events for developing custom detection rules or conducting threat hunting.

UPD 22.10.2026: added a description of how the Kaspersky Managed Detection and Response service detects the described malicious activity.

UPD 22.10.2026: added a description of how Kaspersky Vulnerability Management detects vulnerable versions of PHP.

Vulnerability overview

On October 20, 2026, the PHP security team published a preliminary notice regarding an upcoming emergency release that addresses two critical vulnerabilities (both rated 9.2 on the CVSS scale). The patches were released on Wednesday, October 21, 2026, at 14:00 UTC.

The release was expedited after information about the vulnerabilities was leaked to the public before the scheduled embargo was lifted. In a post on Hacker News, a user reported two RCE vulnerabilities in PHP, allegedly affecting all versions starting with PHP 5.4.0.

The vulnerabilities in question are CVE-2026-109618 and CVE-2026-109619. Shortly after the post appeared, researchers confirmed the existence of the vulnerabilities. Along with the leak of details, an exploit unofficially named PHP2Shell appeared online. In the leaked demo video, the exploit is shown in action on web servers running WordPress, MediaWiki, phpBB, Magento, Joomla, Laravel, Symfony, Drupal, and WHMCS β€” platforms that power many modern websites. The authenticity of the demonstration and the exact behavior of the exploit had not been independently verified at the time of publication.

According to the researcher who published the PoC, the vulnerabilities are related to the handling of the multipart/form-data MIME type in conjunction with the session upload progress mechanism (session.upload_progress) in the PHP core and fall under the categories of use-after-free and memory corruption. This means that the flaws cannot be fixed via application code, and the only fix is to update PHP on the server. The attack requires no authentication: an attacker with network access to a PHP application can execute arbitrary code with the privileges of the PHP process without needing to authenticate. Security advisories issued by the PHP team on October 21 confirm this information.

The vulnerabilities affect PHP versions 5, 7, and 8. As of this publication, branches 8.2 through 8.5 are supported. Older branches, including PHP 8.1, 8.0, 7.x, and 5.x, have reached the end of their lifecycle; however, due to the critical severity of the vulnerabilities, backported patches have also been released for versions 7.4, 8.0, and 8.1.

Sansec experts estimate that widespread exploitation could begin within 15 minutes of the update’s release. We strongly recommend that administrators responsible for publicly accessible PHP web servers take the following steps before the patch is available:

  1. Take an inventory of all PHP-based systems in your infrastructure (such as web servers, control panels, and third-party software).
  2. Disable upload-progress: set session.upload_progress.enabled = Off using the php_admin_flag in PHP-FPM pools.
  3. Block multipart requests on nginx and Apache servers.
  4. Consider temporarily isolating PHP applications that connect to the Internet until fixes are released.
  5. Be ready to install the patch immediately upon its release.
  6. Plan to migrate servers running unsupported versions (8.1 and earlier) to the latest PHP branch.

Detection by Kaspersky solutions

Kaspersky solutions detect the described malicious activity at various stages of the attack. Possible detection scenarios are listed below.

When an attempt is made to exploit these RCE vulnerabilities,Β Kaspersky Endpoint Detection and Response promptly alerts the user to suspicious actions performed in the context of a web server, on both Linux and Windows machines. This activity is detected by the following rules:

Detection of the PHP2Shell vulnerability exploit by KEDR

Detection of the PHP2Shell vulnerability exploit by KEDR

Exploitation of the PHP2Shell vulnerability in network traffic is detected by Kaspersky Anti Targeted Attack (KATA). This solution detects such activity with the following verdicts: Exploit.CVE-2026-109618.HTTP.C&C and Exploit.CVE-2026-109619.HTTP.C&C.

Detection of the PHP2Shell vulnerability exploit by KATA

Detection of the PHP2Shell vulnerability exploit by KATA

Kaspersky Endpoint Security, now available as Kaspersky Next, also detects malicious post-exploitation activity using the Behavior Detection component, with verdicts such as PDM:Exploit.Linux.Generic and PDM:Exploit.Win32.Generic.

Our Kaspersky Vulnerability Management solution detects vulnerable software versions using the Vulnerability scanning and Agentless black-box scanning components.

Detection of the PHP vulnerability in Kaspersky Vulnerability Management

Detection of the PHP vulnerability in Kaspersky Vulnerability Management


The Kaspersky Managed Detection and Response service detects the exploitation of the described vulnerabilities by monitoring activity characteristic of RCE:
  • Spawning of suspicious processes by the web server;
  • Creation of suspicious executable files in the web application directory;
  • Creation of suspicious scripts in the web application directory;
  • Creation of files with uncommon extensions in the web application directory;
  • Execution of reconnaissance commands by the web server process;
  • Execution of persistence commands by the web server process;
  • Delivery and launch of web shells on the web server.

Moreover, MDR detects other malicious activity not directly related to remote code execution.

To protect companies that use our Kaspersky SIEM system, the product repository includes rules that help detect the following malicious activity.

  • Execution of suspicious executable files by web server processes on Windows and Linux machines:
    • R300_04_Windows shell started by a web application
    • R152_08_A running Linux shell process has a suspicious parent process
  • Execution of reconnaissance commands by the web server process:
    • R286_05_Possible web-shell (Linux)

We also recommend monitoring the creation of scripts or executable files in the web server directory when developing your own detection rules or conducting threat hunting:

((DeviceEventClassID = '4663' AND DeviceCustomString1 ilike 'WriteData') OR DeviceEventClassID = '11')
AND match(FileName,'(?i).*\.(php|asp|aspx|ashx|jsp|js|jar|jse|dll|exe|bat|ps1|vbs|wsf|wsh|msi|msp|hta|cpl)$')
AND match(DestinationProcessName,'(?i).*(php-cgi|nginx|httpd|w3wp)\.exe')

Name = 'openat' AND has(SA.Nametype, 'CREATE')
AND
length(arrayFilter(x -> match(x, '(public_html|var/www|usr/local/apache2|usr/local/httpd|var/apache|srv/www|home/httpd/html|srv/http|usr/share/nginx/html|var/lib/pgsql/data|usr/local/mysql/data|var/lib/mysql|var/vsftpd|etc/bind|var/named)'), SA.FileName))>1
AND
length(arrayFilter(x -> match(x, '\.(aspx|asp|asmx|asax|ashx|jspx|jsp|js|phpt|php|phtml|pht|cfm|shtml|htaccess|fcgi|cgi|pl|py|sh)'), SA.FileName))>1

Sizing the PHP exposure window for CVE-2026-109618 and CVE-2026-109619 with VirusTotal

21 October 2026 at 12:12
On October 20, the PHP security team announced an out-of-band security release for Wednesday, October 21, 2026 at 14:00 UTC, fixing two critical vulnerabilities rated CVSS v4.0 9.2 (CVE-2026-109618 and CVE-2026-109619). Hours before the release, technical details leaked publicly. They point to the session.upload_progress feature, which has been part of PHP since 5.4.0 and is enabled by default. The community quickly converged on an interim mitigation: set session.upload_progress.enabled = Off in php.ini.
That leaves defenders with two questions: how big is the exposed surface, and where should they start? We used Internet Scanning in VirusTotal to answer both.
Note: Official details, affected versions and fixed versions are published by the PHP project with the release. The figures below describe the Internet-facing PHP footprint, not confirmed vulnerable hosts.

Most PHP servers don't say they are PHP

VirusTotal fingerprints roughly 5.1 million IP addresses running PHP (port_service_cpe:php), about 3.8 million of them with at least one port open today. Only around 1.1 million of those announce a version in an HTTP header such as X-Powered-By: PHP/8.3.35.
In other words, roughly four out of five PHP servers hide their version (expose_php = Off, stripped headers, reverse proxies). VirusTotal still identifies them as PHP through other signals: the application on top (WordPress, Laravel, Nextcloud...), PHPSESSID cookies and framework-specific headers. If you only search for a version string, you only see the fraction of the problem that volunteers it.

The version picture: the long tail of end-of-life PHP

Among the servers that do disclose their version, the split is stark:
PHP versions disclosed in service banners: supported, end-of-life and pre-5.4 branches

  • ~272K run a supported branch (8.2 to 8.5), the only branches that receive security fixes from the PHP project.
  • ~758K run an end-of-life branch between 5.4 and 8.1. These branches have session.upload_progress enabled by default and no longer receive security fixes. PHP 7.4 alone accounts for ~187K IPs and PHP 5.4 for ~119K.
  • ~88K run PHP 5.2 or 5.3, which predate session.upload_progress.
Being up to date doesn't buy much time either: about 85K IPs run the exact releases published on September 24 (8.3.35, 8.2.34, 8.4.26 and 8.5.11), the latest available before this fix.
Latest PHP releases before the fix and other open ports on PHP hosts

What runs on top, and where

Apache (~2.9M) and nginx (~1.48M) are the web servers most often seen on PHP hosts, followed by LiteSpeed (~90K). On the application side, WordPress dominates with ~538K IPs, followed by Laravel (~141K) and Nextcloud (~107K). Webmail (Roundcube) and database admin panels (phpMyAdmin) add another ~25K high-value targets.
Web servers and applications detected on PHP hosts

The geography is concentrated: the United States accounts for ~920K PHP hosts with at least one open port, and a handful of cloud and hosting providers (AWS, DigitalOcean, Alibaba, OVHcloud, Hetzner) concentrate a large share. That concentration is good news for remediation: a few providers that push a configuration change or a WAF rule can cover a lot of ground.
Top countries and selected hosting providers for PHP hosts with an open port

Going beyond the web port

PHP rarely travels alone. ~394K PHP hosts also have port 22 open (SSH by default), ~233K port 3306 (MySQL) and ~68K port 3389 (RDP). Those co-exposed services are useful for something else: identifying the exact build behind the web server.
The leaked material references LiteSpeed lsphp82 8.2.34 builds for Debian 12, Ubuntu 22.04 and Ubuntu 24.04, and notes that HTTP headers alone don't tell those builds apart. The OpenSSH package on port 22 does. With the bracket syntax, every condition is pinned to its port:
entity:ip port_service_cpe:php port_banner:"PHP/8.2.34" port_service_version[22]:"9.6p1 Ubuntu"
Of the ~3.5K IPs whose banners show both LiteSpeed and PHP 8.2.34, about 500 also have port 22 open. Across all PHP 8.2.34 hosts, the OpenSSH package on port 22 matches Ubuntu 24.04 on 269 IPs, Ubuntu 22.04 on 112 and Debian 12 on 65. For a defender, that is the difference between "patch everything" and "these are the machines that match the leaked target profile, patch them first". Keep in mind that port 22 reveals the host operating system: PHP may still run inside a container built on a different base image.
Ports tab of a PHP 8.2.34 host showing HTTP and OpenSSH on port 22

Adversaries run PHP too

The exposed surface also includes attacker infrastructure. Around 5.7K PHP hosts with at least one open port have five or more detections in VirusTotal, 729 of them disclosing PHP 8.x. One of them is an old acquaintance: the NOX Stealer panel (rebranded as BOMBAY) on 5.175.221[.]206:8443, which we profiled in our Internet Scanning post, runs nginx 1.24.0 with PHP/8.3.33.
Ports tab of 5.175.221.206 showing nginx 1.24.0 and PHP/8.3.33 on port 8443

What the VirusTotal corpus saw

The leak left traces across VirusTotal. The archive referenced in the write-up was first submitted at 02:29 UTC on October 21, less than 15 minutes after the first submission of the write-up URL. By the time of writing, 21 crowdsourced reports covering the vulnerabilities had been ingested as collections. Following entity:collection collection_type:report "CVE-2026-109618" is the fastest way to keep up with new reporting as it appears.
VirusTotal search results for crowdsourced reports about CVE-2026-109618

What to do now

  1. Patch. Upgrade to the fixed release of your branch (8.2, 8.3, 8.4 or 8.5) as soon as it is available on php.net or through your distribution.
  2. Plan the EOL migration. PHP 8.1 and older no longer receive security fixes. If you are on 5.4 to 8.1, upgrade the branch or check whether your distribution or vendor ships a backport.
  3. Disable upload progress until you patch. Set session.upload_progress.enabled = Off in php.ini (or the pool configuration) and reload PHP-FPM, Apache or LSAPI. It only breaks upload progress bars that rely on the feature. Community analysis suggests it may not cover every vector, so treat it as a stopgap, not a fix.
  4. Filter multipart at the edge. Where an application doesn't need file uploads, block or inspect multipart/form-data requests before they reach PHP. Cloudflare shipped emergency rules to its Managed and Free rulesets on October 21, and its CTO stated that they cover known payloads, while stressing that only updating PHP fully protects a site.
  5. Make sure the WAF can't be bypassed. Edge rules only help if the origin is not directly reachable. Search your own ranges in VirusTotal (for example, entity:ip port_service_cpe:php asn:<your ASN>) to find origins that expose PHP directly to the Internet.
  6. Don't rely on hiding the version. expose_php = Off hides the header, not the vulnerability.

Queries used in this post

Query What it finds
entity:ip port_service_cpe:php All IPs where VirusTotal fingerprinted PHP on any port
entity:ip port_service_cpe:php port_status:open PHP hosts with at least one port currently open
entity:ip port_service_cpe:php port_banner:"PHP/" PHP hosts that disclose their version in an HTTP header
entity:ip port_service_cpe:php port_banner:"PHP/7.4." PHP hosts on a given branch (repeat for each branch from 5.2 to 8.5)
entity:ip port_service_cpe:php port_banner:"PHP/8.3.35" PHP hosts on the latest release before the fix (repeat for 8.2.34, 8.4.26 and 8.5.11)
entity:ip port_service_cpe:php port_service_cpe:nginx PHP hosts by web server (also "apache:http_server", lighttpd, internet_information_services)
entity:ip port_service_cpe:php port_banner:"LiteSpeed" PHP hosts by Server header (also openresty, Caddy)
entity:ip port_service_cpe:php port_service_cpe:wordpress PHP hosts by application (also laravel, nextcloud, drupal, joomla, roundcube, phpmyadmin...)
entity:ip port_service_cpe:php port_status:open country:US PHP hosts with an open port, by country
entity:ip port_service_cpe:php port_status:open asn:16509 PHP hosts with an open port, by hosting provider ASN
entity:ip port_service_cpe:php open_port:22 PHP hosts with another port open (also 3306, 3389, 445, 8443, 8000)
entity:ip port_service_cpe:php port_banner:"LiteSpeed" port_banner:"PHP/8.2.34" Hosts whose banners show both LiteSpeed and PHP 8.2.34, the profile referenced in the leak
entity:ip port_service_cpe:php port_banner:"PHP/8.2.34" port_service_version[22]:"9.6p1 Ubuntu" PHP 8.2.34 hosts whose OpenSSH package on port 22 is Ubuntu 24.04's (use 8.9p1 Ubuntu for Ubuntu 22.04 and deb12 for Debian 12)
entity:ip port_service_cpe:php port_status:open positives:5+ PHP hosts with an open port and five or more detections
entity:collection collection_type:report "CVE-2026-109618" Crowdsourced reports about the vulnerabilities
Note: All counts in this post were taken on October 21, 2026. For large result sets VirusTotal returns estimated totals that vary between runs, so we report the median of seven runs, rounded. Port modifiers without a port in brackets match per IP, not per port: port_service_cpe:php port_status:open means PHP was fingerprinted on the IP and at least one of its ports is open.

References

Happy hunting!

❌