PHP2Shell: Two Critical PHP Flaws Reported as RCE, CVE-2026-109618 and CVE-2026-109619

PHP2Shell is the name used for two critical flaws in PHP itself, which CERT-EU names CVE-2026-109618 and CVE-2026-109619. PHP released the fixes on 21 October 2026, in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP says the flaws can allow unauthenticated remote code execution, rates both 9.2 on CVSS v4.0 and says updating is the only safe choice.

This post joins what PHP, CERT-EU and security researchers have said. It marks what PHP confirms and what is only reported, and it lists steps you can take today. Where nobody has published a fact, the post says so instead of guessing.

Update 29 October 2026: Mitel product fixes, workarounds and pending updates were added from its 28 October advisory.

Update 30 October 2026: Palo Alto Networks Unit 42 reported on 29 October that PHP2Shell was being actively exploited against PAN-OS management interfaces exposed to the internet. Unit 42 said it independently verified attacker tooling from a campaign chaining PHP2Shell with a Linux kernel privilege-escalation flaw. Separately, CISA says CVE-2026-46300 can be chained with the PHP flaws to run commands as root.

Palo Alto Networks advises removing public internet access to management interfaces, restricting management to trusted internal IP addresses, and applying available PAN-OS fixes.

Update 30 October 2026, Dream report: Dream reports that one attacker rooted 25 PAN-OS servers in the US, Japan, Taiwan and South Korea. It says the targets included a US government-affiliated organization, whose Active Directory the attacker then went after. Unit 42 says it verified the same attacker’s tooling. Details, the unsettled attribution and Palo Alto’s hotfixes are in our PAN-OS status post.

Free PHP2Shell CheckerSee which PHP version your site shows to the outside world and whether it falls in the CVE-2026-109618 and CVE-2026-109619 range. Passive check, no account, no exploit traffic.Check Your Site →

What Do 40,849 PHP2Shell Checks Show?

Our free PHP2Shell check ran 40,849 times on 30,027 different sites between 21 and 25 October 2026. The numbers below are Brandefense Atlas data, and we publish counts only. The check reads the PHP version a site shows in its response headers.

That version was readable on only about 12% of the sites, or 3,532. At their latest check, PHP was present but hid its version on 9,411 sites, and on 10,023 the check found no PHP. The table splits the 3,532 sites with a readable version, using each site’s latest check that showed a version.

One more site showed a PHP branch outside this list. So 2,071 sites, or 59% of those with a readable version, showed a PHP version older than the fixed releases. Of these, 914 were on a supported branch and 1,157 on an end-of-life branch, where only a vendor backport, which the version number may not show, would carry the fix.

The patched share rose over the week. Counting each site’s first readable check of the day, it went from 21% (50 of 236) on 21 October to 50% (64 of 129) on 25 October. The 21 October figure includes the hours before the fixed releases, which PHP had scheduled for 14:00 UTC, and the later days have small samples.

Some sites came back and had patched. We saw 84 sites unpatched on a supported branch and checked them again on a later day. By their last check, 55 of them had patched.

Three limits apply. Visitors chose what to check, often their own or their clients’ sites, so this is not a random sample of the internet. The version comes only from response headers and most PHP sites hide it, and a hidden version is not a safe version. Distribution and vendor builds can carry the fix under an old version number.

Source: Brandefense Atlas, free PHP2Shell check, aggregate counts, 21 to 25 October 2026. Run the same free check on your own site.

What Do We Know So Far?

PHP has now published its advisories, so most of the technical facts are confirmed. Each row below names the source of its date.

1. 11 Aug 2026Calif’s first reportCalif says it reported the first bug to PHP on this date, shared a proof of concept on 14 August and had PHP confirm it on 15 August. It says it reported a second bug on 21 August.
2. 19 Aug 2026Wiz’s first findingWiz says its researchers found the first PHP vulnerability on this date. It says it reported the flaws to the PHP security team on 24 August.
3. 21 Sep 2026PHP acknowledges WizWiz says PHP acknowledged its reports on this date and began work on a coordinated fix.
4. 17 Oct 2026Amazon honeypot sees first attemptAmazon says its MadPot honeypot telemetry shows a PHP2Shell exploit attempt four days before public disclosure.
5. 20 Oct 2026, 15:20 UTCThe leak startsSansec lists a Hacker News post that reported two upcoming PHP RCE disclosures. Huntress says the post was later taken down.
6. 20 Oct 2026PHP gives advance noticeThe PHP security team announces a release for 21 October at 14:00 UTC that fixes two critical flaws.
7. 20 Oct 2026CERT-EU advisory 2026-018CERT-EU names both CVE ids and lists a score of 9.2 for each. It says no technical details have been made public.
8. 21 Oct 2026, 03:02 UTCCloudflare rules go liveCloudflare says it switched on protection rules, including a managed free ruleset for free plans, before the public release.
9. 21 Oct 2026, 11:35 UTCHadrian reports attacksHadrian’s update log says it sees PHP2Shell exploited in the wild at scale, mostly through PHP’s session upload progress path. It gives no counts.
10. 21 Oct 2026, 12:55 UTCJapan’s prime minister asks site owners to actPrime Minister Sanae Takaichi posts on X (21:55 in Japan) an “urgent request” to check whether public websites use PHP and to be ready to apply the fix as soon as it is out. She adds that if patching is hard, temporarily suspending a site is one way to lower risk (our translation).
11. 21 Oct 2026Fixed releasesPHP publishes 8.5.12, 8.4.27, 8.3.36 and 8.2.35 and a security advisory that names both CVE ids and the affected versions. PHP 8.1 and older get no new release, only minimal source backports for 7.4, 8.0 and 8.1.
12. 21 Oct 2026, 13:45 UTCNSA tells PHP users to prepareThe US National Security Agency posts: “Effective Immediately, all organizations using PHP for their systems are advised to be prepared for an update addressing two critical vulnerabilities.” It adds that if an immediate update is not feasible, organizations should take the system offline until it i
13. 21 Oct 2026, 13:57 UTCJapan’s National Cybersecurity Office posts a warningThe office posts that PHP updates with fixes for serious flaws are out and should be applied as soon as possible, or sites may be compromised (our translation).
14. 21 Oct 2026, 14:17 UTCNVD records appearNVD publishes both CVE records, with PHP’s 9.2 on CVSS 4.0 for each.

The facts split into three groups.

• Confirmed by PHP: two critical flaws, each 9.2 on CVSS v4.0, both CVE ids and the cause of each bug. PHP also lists the affected and fixed versions and says both can allow unauthenticated remote code execution.
• Reported by others: the name PHP2Shell. Sansec says it is the name of an exploit tool seen in a leaked screenshot and credited to Calif.
• Reported by Amazon: six IP addresses seen in its MadPot honeypots, which it says include shared anonymization infrastructure and should be investigated, not blocked. Huntress writes that no indicator of compromise has been confirmed and says Sigma and YARA rules will follow once technical details are available.

PHP’s release text does not report exploitation. Cloudflare says it observed attack traffic targeting its customers, with attackers changing the payload to try to get past its rules. Cloudflare gives no counts and does not say that any customer was compromised. Wiz’s first post, published on 21 October, does not say whether the flaws are exploited in the wild.

Huntress wrote on 21 October that, as of 4:30 pm ET (20:30 UTC), it had not observed exploitation on its partner systems. CISA’s alert of 21 October first said CISA had not observed exploitation at the time of publication. On 26 October CISA revised the alert and removed that sentence when it added both CVEs to its KEV catalog.

On 26 October CISA added both CVEs to its Known Exploited Vulnerabilities catalog. Until then, the file released on 23 October at 19:30 UTC listed neither.

Amazon’s threat intelligence team reports a first exploit attempt on 17 October 2026 in its MadPot honeypot telemetry, four days before disclosure. It says more attempts followed from 02:00 UTC on 21 October. Payloads and anonymization infrastructure varied, which it takes to mean several actors.

It also says it is unclear whether those honeypot attempts would have succeeded on real systems. It says PHP2Shell is now being broadly exploited in the wild. This is a honeypot sighting, not a report of a breached customer.

A researcher’s honeypot report dated 24 October records 35 shells started by Apache workers right after exploit requests. The honeypots ran PHP 8.4.26 under Apache mod_php; VulnCheck says at least one public proof of concept bypassed ASLR on x86-64 for that version only.

The report calls the traffic consistent with CVE-2026-109618 and does not establish use of CVE-2026-109619. It reports no second-stage download and says the setup was deliberately favourable, so it does not measure how reliable the exploit is elsewhere.

Two other firms report attacks. watchTowr says it is observing active exploitation attempts of both CVEs. Its FAQ ties this to its Attacker Eye honeypot network.

Hadrian’s update log says that at 11:35 UTC on 21 October it saw exploitation at scale, mostly through PHP’s session upload progress path. At 14:35 UTC it said this was still happening.

Sophos and Arctic Wolf add a malware angle. On 22 October Sophos wrote that the payload in an attempt it blocked, a likely Mirai variant known as Potassium, was not delivered. It says it saw scanning and a small number of failed exploitation attempts.

It found no evidence of a successful compromise. Sophos says the sample can run DDoS attacks, as Mirai malware has done before. Arctic Wolf describes Potassium as a Mirai-derived botnet family first identified in March 2026 by Synthient.

It says it saw widescale scanning and exploitation attempts after disclosure and links payloads on associated infrastructure to Potassium. It adds that request data alone does not show a target was vulnerable or that code ran. Its telemetry did not establish that the PHP2Shell requests downloaded or ran either sample.

Neither report says that any site was taken over.

watchTowr and Hadrian publish no counts, source addresses or victims, and we cannot check their data. Read them as reports of attempts, not as proof that any site was breached. Of the reports here, only the honeypot report above shows code running. For the public reaction, see how the first 36 hours unfolded, with our own X and GitHub counts.

Wiz’s post of 27 October describes the attempts it captured from a public exploit kit. Neither variant of the kit completed the chain in those attempts. The older one hit request-size limits or did not reach the memory-exhaustion condition. The newer one exhausted PHP’s memory each time, but its memory-leak stage failed in every captured run.

Wiz says the kit’s memory layout was calculated for the official php:8.4.26-apache image with a 128 MB memory limit. Its own Roundcube honeypot ran a different build with a 64 MB limit. Wiz adds that consecutive requests must reach the same Apache worker, which timeouts and network latency can disrupt.

Wiz expects these barriers to shrink over time. It calls the honeypot report above the strongest public evidence it has seen. It also notes that the setup there was favourable, so the report does not show reliability elsewhere.

Wiz says two scanners that failed against its own systems did succeed against that honeypot. It also found tools branded PHP2Shell that did not try to exploit either flaw. One of them only works if the target has a vulnerable test page from the exploit author’s own lab, or a similar file-inclusion flaw. Wiz’s post ends with a table of IP addresses seen between 21 and 26 October in exploitation attempts, scanning and as a payload server.

NVD published records for both CVEs on 21 October at 14:17 UTC. It lists PHP’s 9.2 on CVSS 4.0 for each. NVD added its own CVSS 3.1 scores later that day, 9.8 for both, and on 22 October lowered CVE-2026-109619 to 8.1, so the two now differ. The scores come from different CVSS versions, so do not compare them directly.

NCSC-NL’s page, updated on 23 October, says it knows of one report of possible misuse abroad that is not confirmed as successful. It says exploiting the flaws is complicated and that the chance of large-scale misuse is lower than it first estimated, and that its advice stays the same: install the updates. HKCERT wrote on 22 October that both CVEs are being exploited in the wild.

Sansec expects mass attacks to start within 15 minutes of the release. Treat the forecasts as forecasts, not measurements.

On proof of concept, Wiz says it combined the two flaws in one script. It ran the script in its lab against current WordPress, Drupal and Joomla container images. Sansec says the write-ups and an exploit tool are public. We have not opened, downloaded or run any exploit code, and we link none.

For scale, Check Point cites a count of roughly 884,000 internet-facing hosts that advertise PHP 8.1 or older in their Shodan banners on 20 October. Check Point calls these banner counts, not confirmed vulnerable systems.

Who Found PHP2Shell?

Two research teams say they found the bugs, and their pages date events differently, so we give each as that team’s own account. The 21 October announcement on php.net names no finders.

• Calif says the bugs were discovered by Calif, OpenAI and Wiz. It says OpenAI invited it to the Patch the Planet initiative. Its dates are in the timeline above.
• Wiz says Wiz Research found the first PHP vulnerability. Its post credits the PHP team, Calif and OpenAI for discovery, coordination and patch verification. Its dates are in the timeline above.

Both teams describe exploits against WordPress, Drupal and Joomla in their own labs, and we have not verified them. Calif adds that the PHP-FPM route is application-dependent. It needs the application to decode data, such as a session, and a fatal error during that decode leaves stale state that a later request can use.

On PHP-FPM, exposure therefore depends on the application. On Apache mod_php, Calif reports RCE against arbitrary PHP scripts. PHP2Shell is separate from the Drupal core flaw CVE-2026-108097 in Field UI, which needs its own update.

Which PHP Versions Are Exposed?

PHP’s GitHub advisories list every release before 8.2.35, 8.3.36, 8.4.27 and 8.5.12 as affected. PHP says all PHP installations serving web requests are at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. It considers the risk highest for mod_php, where it has a demonstrated exploit in which an unauthenticated request triggers the attack before any application code runs.

The advisories do not say how far back older branches are affected. CERT-EU’s earlier range of PHP 5 and later, and Sansec’s PHP 5.4 and later, are not confirmed by PHP. Cloudflare (PHP 5.4 or later), Calif (the earliest path it found dates to PHP 5.4.0) and watchTowr (PHP 5, 7 and 8 in their entirety) give similar ranges. PHP does not confirm those either.

A PHP security team member wrote on oss-security on 21 October that unauthenticated RCE has been demonstrated against Apache mod_php. Source analysis suggests PHP-FPM is also susceptible, but no complete FPM exploit had been demonstrated for CVE-2026-109618.

VirusTotal sized the exposure with scan data from 21 October. About 1.1 million servers disclose a PHP version. Of those, it counts about 272,000 on a supported branch (8.2 to 8.5) and about 758,000 on an end-of-life branch (5.4 to 8.1). VirusTotal says the figures size the footprint and are not confirmed vulnerable hosts.

Wiz tracked how exposure changed after the 21 October disclosure. Its telemetry shows an approximate 67% fall in the daily number of distinct internet-exposed machines vulnerable to PHP2Shell. The number of organizations with at least one exposed, vulnerable instance fell by about 47.9%. Among exposed machines that were still vulnerable, the share running PHP 7.3 or earlier fell from 8.3% to 5.7% over five days.

Wiz says this fits patching, upgrading, retiring machines and restricting internet access, but its data does not show how much each one contributed. It also warns that scan coverage and population size can move the numbers. Wiz puts the share of initially affected organizations that were still vulnerable one week after disclosure at less than 53%. A falling total says nothing about your own servers, so use the exposure checklist below to check them.

For distribution builds, match the package channel as well as the PHP number. SUSE lists php8 and apache2-mod_php8 at 8.5.12-160100.1.1 or later for SUSE Linux Enterprise Server 16.1 in its CVE-2026-109618 and CVE-2026-109619 package tables. This is a distribution package track, not a new upstream PHP release.

The fixed versions come from PHP’s release announcements, and the support dates from php.net. PHP says 8.2 reaches end of life on 31 December 2026 and gets no security fixes after that date. For 8.1 and older, PHP says some distributions and LTS vendors provide backported fixes, so contact your vendor or upgrade to a supported version.

CISA says organizations that cannot update immediately, or that still use PHP 8.1 or earlier, should take PHP-based systems offline until they are patched or updated. The UK NCSC says to consider taking a system offline if you cannot update it or apply the temporary measures. It also says to search all PHP installations, not only outdated ones.

PHP also published minimal source backports for 7.4, 8.0 and 8.1 on GitHub, to help people who build from source or have no LTS vendor. Linux distributions and LTS vendors received the patches in advance, so check your vendor for updated packages.

For PHP 5.4 to 5.6, a community member posted an unofficial backport of the CVE-2026-109618 fix on oss-security on 24 October. It does not come from the PHP project and we have not tested it. A reply on 25 October asked whether, given the size of the upstream patch, it would be better to crash the process on out-of-memory.

Which Mitel Products Have a PHP2Shell Fix?

Mitel’s MISA-2026-0008 advisory, revision 6.0 of 28 October, lists fixes, workarounds and planned updates for products that carry PHP. The rows below cover products it marks Affected by CVE-2026-109618 and CVE-2026-109619. Match the product and branch before choosing a response.

A workaround is not a released software fix. Mitel’s public advisory points to knowledge-base articles for deployment steps; those access-controlled instructions are not reproduced here. Ask the product owner or Mitel partner to match the guidance to the installed build.

Mitel says it has reviewed its operated cloud services and updated them where needed. It names Unify Phone and CloudLink as not affected by these PHP flaws. These statements cover supported product versions; end-of-support products are outside the advisory’s assessment.

The same table also contains Not Affected and Investigating rows. Investigating does not mean an affected product has been confirmed. Check Mitel’s current advisory for products outside the selected rows above, rather than treating this list as a statement about every Mitel device.

What Is the Root Cause of Each Flaw?

PHP’s advisories describe two separate bugs, and PHP maps each CVE id to one of them.

• CVE-2026-109618, “RCE via OOM corruption”: out-of-memory handling can interrupt PHP while internal request data is only partially initialized. Request cleanup may then treat the invalid data as valid. The GitHub advisory names multipart parsing issues as one trigger.
• CVE-2026-109619, “RCE via stale global state”: request-owned internal state can survive after its backing memory has been freed. A later request handled by the same worker may use that stale state before normal initialization resets it. The advisory confirms two cases: the PHP 8.5 fatal error backtrace path and session upload progress after an out-of-memory or other fatal error.

The changelog lists one core fix for both advisories, titled “Avoid state corruption via bailout”. The advisories linked in the sources have the full technical details.

One setting now has a confirmed link. The PHP manual describes session upload progress, a feature that tracks a file upload and writes its progress into the session. The manual lists session.upload_progress.enabled as on by default. PHP’s advisory for CVE-2026-109619 names this feature as one place where the stale state can be read.

How Do You Check for PHP2Shell?

You can check for PHP2Shell in three safe ways. Run our free PHP2Shell checker, which reads the version your site shows to the outside. Run php -v and php-fpm -v on the server. Or open a phpinfo() page and delete it right after.

We know of no published safe test for the bugs, so do not send exploit traffic to a server. What you can check safely is the version and the setting. Huntress starts with an inventory, including PHP bundled in vendor software, control panels and CMS platforms.

• List every PHP runtimeInclude containers, control panels, CMS hosts and appliances that ship their own PHP.
• Read the version inside the serverRun php -v. The command line binary can differ from the one your web server uses, so also check php-fpm -v or the Apache module. Compare with 8.5.12, 8.4.27, 8.3.36 or 8.2.35, and check your vendor’s notice for backported fixes.
• Read the upload progress settingLook for session.upload_progress.enabled in the php.ini and pool files your web server loads. The default is 1.
• Look from outsideResponse headers may show a PHP version when expose_php is on. A missing header does not mean you are safe.
• Mark unsupported branchesAnything on 8.1 or older gets no new PHP release and needs a vendor backport, PHP’s minimal source backport (7.4, 8.0 and 8.1 only), an upgrade or isolation.

php -v
php -i | grep -i session.upload_progress
php-fpm -v
curl -sI https://www.example.com/ | grep -iE "^(server|x-powered-by):"

The second command reads the setting for the command line, which may use a different php.ini than your website. Check the file your web server really loads, for example with a phpinfo() page that you delete right after.

To see the PHP version your site advertises to the outside world without a terminal, run our free PHP2Shell checker. It sends one ordinary request to your homepage, reads the version from the response headers and never sends exploit traffic. If it shows no version, the site may simply hide it. That does not make the site safe, so read the version on the server and update if it is older than the fixed releases.

What Can You Do If You Cannot Update Yet?

Updating is the only complete fix. PHP says its release has no complete mitigations. It says the measures below reduce exposure to specific attack paths but do not make an installation safe.

• For CVE-2026-109618, remove the memory limit. Set memory_limit=-1, preferably where applications cannot override it, such as php_admin_value in the FPM pool or the Apache configuration. Check that no pool, directory or application setting puts a finite limit back. PHP says an underlying allocation failure can still reach the vulnerable path, and it advises against RLIMIT_AS and RLIMIT_DATA.
• Limit request size. PHP suggests post_max_size = 8M for applications without file uploads and 32M where uploads are needed, with upload_max_filesize below it. It also suggests limits at the web server or proxy on request size, field count, multipart parts, headers and nesting depth.
• For CVE-2026-109619, turn off upload progress. Set session.upload_progress.enabled=0 in php.ini, an FPM pool or server configuration that applies before request parsing, and restart every worker. PHP says not to rely on ini_set() or FPM .user.ini. This blocks the confirmed session paths but not other variants. PHP’s 23 October advisory for CVE-2026-115560 suggests keeping it off until the next regular bugfix release; it does not say the 21 October releases fix that issue.
• On PHP 8.5, turn off fatal error backtraces. Set fatal_error_backtraces=0 and restart every worker. PHP says this blocks only the confirmed fatal backtrace path.
• Isolate or take offline what you cannot patch. CERT-EU advises isolating internet-facing applications from public networks if immediate patching is not possible. CISA says to take PHP-based systems offline until they are updated, and the UK NCSC says to consider it.
• Add a web application firewall as an extra layer. CISA says a WAF may provide some protection until systems are updated. Cloudflare says customers on its free or paid WAF are protected by default. Free plans get seven rules in the Cloudflare Managed Free Ruleset. Professional, Business and Enterprise plans get seven matching rules in the Cloudflare Managed Ruleset, which you should confirm are in block mode.
• Know what a WAF cannot do. Cloudflare says updating website code or a plugin does not fix these flaws, because they sit in the PHP runtime. It says attackers were changing payloads to get past its rules. CloudLinux says its Imunify360 ruleset 8.83 blocks the circulating exploit pattern on ModSecurity and Coraza but only logs it on LiteSpeed. It calls this an interim measure.
• Plan the move off old branches. For 8.1 and older, PHP says to contact your vendor for backported fixes or upgrade to a supported version.

How Should You Roll Out the Patch?

PHP says all users should update immediately to 8.5.12, 8.4.27, 8.3.36 or 8.2.35. Read the php.net announcement for your branch, and take the version numbers in your plan from there. On Windows, install the -1 builds of these versions, for example 8.5.12-1. They also carry the Brotli fix for CVE-2026-111497, covered in our HTTP2Shell fixed-versions post.

1. Patch internet-facing PHP first. Huntress says to patch internet-facing systems first, and Sansec expects attacks within minutes of the release.
2. Check your Linux distribution or host for updated packages. PHP says distributions and LTS vendors received the patches in advance. If you rely on the volunteer-maintained rpms.remirepo.net repository, PHP urges you to switch to distribution packages or build from source. That repository would not have updates on 21 October.
3. Restart PHP-FPM or the web server so running workers load the new code, then confirm the version again with the commands above.
4. Look back through logs since 20 October for the signs in the next section.

If you use your distribution’s PHP, take its update. Distribution packages keep their own version numbers, so read the vendor notice and not the number alone.

Ubuntu (USN-8948-1 and USN-8948-2), Debian (DSA-6574-1) and Red Hat (RHSA-2026:87072) list these fixed packages:

• Ubuntu 22.04: php8.1 8.1.2-1ubuntu2.28, in standard support.
• Ubuntu 24.04: php8.3 8.3.6-0ubuntu0.24.04.13, in standard support.
• Ubuntu 26.04: php8.5 8.5.4-0ubuntu1.5, and Ubuntu 26.10: php8.5 8.5.9-0ubuntu2.1, both in standard support.
• Ubuntu 20.04 and older: through ESM with Ubuntu Pro, for example php7.4 7.4.3-4ubuntu2.29+esm5 on 20.04.
• Debian 13: php8.4 8.4.27-1~deb13u1, the only Debian release the notice lists.
• RHEL 9: the php:8.2 module moves to php 8.2.35.

Hosting and panel vendors are moving at different speeds, and the statements below are from 21 October only. GoDaddy says it patched all PHP versions on Managed Hosting for WordPress. It is waiting for its vendor’s packages for Web Hosting and Windows Hosting, and it leaves VPS customers to update PHP themselves. GoDaddy also says cPanel backported the fix to its PHP 7.4, 8.0 and 8.1 packages.

CloudLinux says its first alt-php packages with the fix came out at 19:00 UTC on 21 October. It says 7.4 and 8.0 are fixed on most platforms and 8.1 on some, and that it tracks the rest on its status page.

Fortinet advisory FG-IR-26-186 (published 21 October, CVSS v3 9.8) lists FortiDDoS, FortiSOAR and FortiSOAR PaaS as under investigation. It says four FortiClient Cloud Services hosts are fixed. It says FortiOS, FortiManager, FortiAnalyzer, FortiMail and FortiAuthenticator, among others, are not impacted. It names no fixed versions, and its known-exploited field says No.

Palo Alto Networks lists PAN-OS and Panorama as affected and says active exploitation has been observed against management interfaces exposed to the internet. By 29 October it had released all 20 hotfixes. It lists Prisma Access and Cloud NGFW as not affected. Our Palo Alto product matrix has each release train and the steps to take before the hotfix.

If your host is not named here, ask it in writing which PHP build your site runs and whether that build carries the fix. NCSC-NL also wrote that third-party images, appliances and embedded runtimes need a separate check.

Teams that lose track of their PHP hosts can use External Attack Surface Management to list what faces the internet. That list is the starting point for the update order, and vulnerability intelligence helps decide which new flaws to patch first.

How Do You Spot an Attack?

Amazon has published six IP addresses from its MadPot honeypot sightings, listed below, but says they include shared anonymization infrastructure and should be investigated rather than blocked. Huntress says no indicator has been confirmed, and Sansec lists no signatures. The practical signal is behavior: a web server process doing something a web server should not do. Successful remote code execution often ends in a web shell that gives the attacker a way back in.

Amazon Threat Intelligence lists these six addresses, written here with the last dot in brackets so they cannot be clicked by accident. Amazon saw them in its MadPot honeypots and states: “The identified IP addresses include shared anonymization infrastructure and are not exclusive to this threat activity. Organizations should investigate any observations involving these addresses as opposed to blocking.” Amazon does not name an actor for these addresses, and neither do we.

Signs on the server to look for:

• PHP worker processes (php-fpm, php-cgi, httpd, apache2) starting shells such as sh, bash, cmd.exe or powershell.exe, per Huntress. The same goes for interpreters such as python or perl, or tools such as curl, wget, nc or certutil.exe.
• Unusual multipart requests followed by memory limit errors or repeated HTTP 500 responses, unexpectedly large or malformed PHPSESSID cookies, and unexplained PHP worker churn, per Wiz.
• Command-line strings with /dev/tcp/, fsockopen or mkfifo, and reconnaissance commands such as whoami, id, uname -a and ipconfig run by the web server, per Huntress.
• Apache error log entries that show worker crashes, for example AH00051 child exit signal messages, and unexpected outbound connections from PHP workers, per Fastly. Fastly says confirmation lives on the origin.

Fastly’s firewall data adds request fingerprints for the most widespread exploit kit. They describe one tool, not the flaw. Fastly says there is no payload string to match, because the exploit is a condition: make the request fail at the wrong moment. Attackers can change every fingerprint below, so use them to find this kit’s traffic, not to prove a server is safe.

• A POST to /index.php or / with the User-Agent php2shell-109618. Fastly warns that User-Agent strings go stale within a day, because the tools change fast.
• The header Content-Type: multipart/form-data; boundary=B7kQpoc618, a fixed-size body and few other headers. Fastly calls the multipart boundary the most reliable separator so far. It found more than ten candidate kits this way, five tied to PHP2Shell.
• Requests aimed at a raw IP address instead of a host name, once or twice per host. Fastly reads this as mass scanning across IP space, not a campaign against one site.
• Look-alikes come first. Fastly found that two circulating PHP2Shell signatures were 98.6% and 99.9% React2Shell traffic in the hour it measured. A Next-Action request header marks React2Shell, because PHP never uses it.

If you find signs of compromise, Huntress advises you to isolate the server and keep the web server and PHP logs. Then look for web shells, new files in the web root, cron jobs, scheduled tasks and new accounts. Attackers who use this route are exploiting a public-facing application, which MITRE tracks as T1190 (Exploit Public-Facing Application), and a planted shell maps to T1505.003.

Our guide shows which PHP2Shell detection rules caught what in a lab and how to prove the fix is running.

How Is PHP2Shell Different From WP2Shell?

The names are close, the problems are not. In our WP2Shell analysis, the flaws sit in WordPress core code and are fixed by updating WordPress. PHP2Shell concerns PHP itself.

Sansec says the fix is a PHP update at server level, which a store cannot apply from its own code. It says this reaches stores such as Magento, Shopware and WooCommerce. A WordPress site on an exposed PHP version could be affected by both stories, and each needs its own update.

PHP was not the only critical remote code execution flaw fixed on 21 October. GitLab also released a patch that day for CVE-2026-110264, rated CVSS 10.0. If you run GitLab yourself, read our GitLab critical vulnerability guide. Node.js also fixed a remote code execution flaw in its Brotli decoder that day; known as Node2Shell (CVE-2026-111497).

One day earlier, on 20 October, CISA added four Plex Media Server CVEs to its Known Exploited Vulnerabilities catalog. Chained, they give remote code execution; our Plex2Shell analysis for Plex Media Server gives the fixed build.

The same week brought a critical flaw in a different PHP project. On 19 October Laravel published an advisory on GitHub for the Laravel TokenGuard authentication bypass. It sits in the Laravel framework, not in PHP, and is fixed with a framework update.

PHP2Shell is also the first story in our weekly security news recap for 19 to 25 October, ranked with seven other stories.