Haven't Updated PHP Yet? Where PHP2Shell Stands and What to Check Now

A week has passed since fixes for the critical PHP vulnerabilities known as PHP2Shell (CVE-2026-109618 / 109619) were released. On October 26, CISA in the United States added them to its catalog as vulnerabilities being exploited in the wild. Even so, a huge amount of PHP around the world has still not been updated.

This article is for people who aren’t sure whether their own site is safe. It sets out how many have not updated and what to check now, in order. For the technical details, see the summary for engineers. The figures are as of the evening of October 28, Japan time.

Key points

• Of the PHP whose version can be seen, only about a quarter is on a fixed version. About 70% reports a version that is not fixed (Censys).
• In Japan, about 1.17 million services report a version that is not fixed. That ranks 6th of 232 countries and regions (Censys).
• On October 26, CISA added the flaws to its KEV catalog, which means exploitation is confirmed. On October 24, honeypot servers also logged successful attacks.
• October 29 update: firewalls have been reported compromised (Dream, JPCERT/CC, in Japanese). Palo Alto itself also updated its threat brief the same day to say it is seeing exploitation of exposed management interfaces (Unit 42). Fixing PHP alone is not enough. The Linux kernel and appliances need updating too.
• Fixed versions exist for PHP 8.2 to 8.5. For 8.1 and earlier, there is no official fix.
• What to do: find out which PHP version you run, update to a fixed version, and check whether anyone got in on or after October 17.

How many have not updated

Censys scans the PHP exposed to the internet and counts it by version, according to whether the version is fixed. This is the display as of October 28 (Censys PHP2Shell Exposure Tracker; latest data to 14:10 UTC, 23:10 Japan time).

A “service” is an IP address or hostname plus a port. It is not a count of organizations or of servers. One server can run several sites.

Of the roughly 45 million services whose version is visible, 73.3% (about 32.7 million) are not fixed. The most common version is PHP 7.4.33, at about 6.93 million (15.5%).

Even on the branches that have a fix, only about half have updated (Censys, October 28).

In the last 24 hours, Censys first saw about 400,000 services on a fixed version. Since the release on October 21, it has seen about 10.61 million move to one.

How to read the numbers

• These are upper bounds counted from the version each service displays. Linux distributions and rental servers sometimes pull in a fix without changing the version number. A patched service is then still counted as unfixed (Censys notes this too).
• I expect Japan to be affected by this more than most. Major Japanese rental-server companies applied their own fixes even to old PHP versions. For example, Lolipop! applied a self-made fix to 5.3 through 7.3 (Piyolog roundup, in Japanese), and the displayed version does not change. I think Japan’s “about 1.17 million” includes some already-fixed services. That is my own view, and I don’t know the share.
• The 59% that hide their version are not counted. The real number of unfixed services could be lower or higher.
• In Japan, Censys has seen about 1.52 million services on an unfixed version at some point since October 21, and about 350,000 (22.9%) of those move to a fixed version (Censys; I calculated the percentage).

More important than the exact figures: a very large number of services have not updated, in the world and in Japan.

Exploitation is confirmed

Through October 23, the reports were mostly about attack attempts, and no solid report of success could be confirmed. That has changed.

• October 17: four days before the fixes were released, an Amazon honeypot saw the first attack attempt (SecurityWeek).
• October 24: Adel Karimi, a researcher at Perplexity, confirmed 35 cases in which an attack succeeded and a shell started, on three honeypot servers (PHP 8.4.26, Apache mod_php). The traffic came from two groups of addresses (published report).
• October 26: CISA added CVE-2026-109618 and 109619 to the KEV (Known Exploited Vulnerabilities) catalog and told US federal agencies to deal with them by October 29 (I checked the data in CISA’s KEV directly). In Japan, IPA has added this listing to its alert (IPA, in Japanese).

The honeypot result is from one setup (a single Apache worker and a 128 MiB memory limit). How many real sites have been compromised is unknown. But attacks now succeed in practice, so there is no reason left to put the update off.

October 29 addition: firewalls were compromised too

The Israeli security company Dream reports that firewalls were compromised in attacks using PHP2Shell. The product is Palo Alto’s PAN-OS (report published October 26, updated October 29; Dream). JPCERT/CC also added this to its alert on October 29 (JPCERT/CC, in Japanese). Palo Alto itself updated its Unit 42 threat brief on the same day, October 29, and wrote that PHP2Shell “is being actively exploited against PAN-OS management interfaces that are exposed to the internet.” It says it independently verified the same attacker’s tooling and confirmed Dream’s results (Unit 42).

• The attacker found about 19,000 internet-facing PAN-OS devices, targeted 240 of them and got root on 24, according to the report. A management server was then compromised through one of them, making 25 in all. They include a US government-related environment
• The method chains PHP2Shell with the Linux kernel flaw CVE-2026-46300. The PHP flaw plants a web shell first, and the kernel flaw takes it up to root
• On October 28, CISA added that kernel flaw to KEV too. The KEV note also describes the chain with PHP2Shell (I checked CISA’s KEV data directly). Palo Alto has released fixing hotfixes (the affected versions are in the table on Palo Alto’s advisory)

Dream’s report is the investigators’ own work. It names no attacker, and notes that it could not recover the Active Directory results. Palo Alto, for its part, says the affected devices were about 0.02% of its installed base, those with a management interface exposed to the internet, and that it contacted each affected customer individually. The management interface is not exposed by default (Unit 42. The figure is Palo Alto’s own and has not been independently verified). Where reports and primary sources disagree is covered in a separate article. What matters for readers of this article:

• Updates for appliances that embed PHP (firewalls and the like) come from the appliance vendor. You cannot update the PHP yourself
• On Linux servers, check kernel updates as well as PHP. Which kernels are affected differs by distribution, so check your distribution’s notice

What to do now

1. Find out who runs your PHP

Who updates PHP depends on how you run it.

Updating a CMS such as WordPress does not help if PHP itself is unfixed. Conversely, if PHP is updated, the CMS-side fix is not required for this issue (summary for engineers).

2. Check which PHP version you use

• On a rental server, you can see it in the control panel’s PHP version setting.
• On WordPress, open Tools, then Site Health, then Info, then Server in the admin screen. It shows the PHP version.
• If you can’t tell, ask your server administrator or maintenance company: “Which PHP version is it?”

3. Decide the next step by version

PHP 8.2 reaches end of life on December 31, 2026 (PHP announcement). While you are updating, plan the migration too.

If you are moving off an old version, you need to confirm that your site or system runs on the newer PHP. Don’t switch production all at once. Test in a test environment first.

4. Stopgaps if you can’t update right away

None of these makes you safe. They only buy time until you update.

• Take the site offline for now, or make it reachable only from set places such as your office
• Put it behind a WAF such as Cloudflare. Cloudflare rolled out rules for known attack paths to all customers, including the free plan. It calls this a stopgap, and it only works on traffic that passes through Cloudflare (Tenable)
• Ask your administrator to apply the temporary PHP settings (such as disabling session.upload_progress.enabled). The settings are in the summary for engineers

5. Check whether anyone got in on or after October 17

Even after you install a fixed version, an intrusion stays if someone got in before the release or before your update. Attacks began four days before the fixes were released.

Ask your maintenance company or administrator to check the following.

• Whether the processes running PHP have started a shell, curl, wget or the like
• Whether there are unfamiliar files in the web-published folders
• Whether there are new scheduled jobs (cron) or unfamiliar accounts
• Whether the logs have been kept, not deleted

If something looks suspicious, isolate that server and replace every password PHP can see (database, API keys and so on). The detailed checklist is in the summary for engineers.

What not to do

• Don’t stop at updating an app such as WordPress. If PHP itself is unfixed, it does not help
• Don’t try an “exploit” you found online on your own server. It may contain malicious code
• Don’t rely on a WAF alone. A WAF only reduces the known attack paths
• Don’t feel safe because you hid the version display. Hiding it does not fix PHP

What is not confirmed

• The real number of unfixed services in Japan is unknown. Censys’s figure is an upper bound based on displayed versions, and I expect it does not reflect the self-made fixes by Japanese rental-server companies
• No further fixed release from PHP has been confirmed since the October 21 release (checked October 28 in docker-library’s versions.json). A fix for CVE-2026-115560 is planned for the next regular release

Related articles

• A Severity 9.8 Linux Kernel Flaw: What the AI-Built Attack Needs, and Where Each Distribution Stands: A new severity 9.8 Linux kernel flaw. It is separate from the PHP2Shell chain
• Where PHP2Shell Reports and the Primary Sources Disagree: Where the reports and the primary sources disagreed

If you’d like help finding where your PHP runs, updating it, or checking for intrusion, get in touch below.