The PHP vulnerability of October 2026, known as PHP2Shell, is a pair of critical flaws in the PHP engine itself that can let an attacker run code on a web server. PHP released emergency fixes on 21 October 2026. If your website runs on PHP, including WordPress, you need to update PHP itself, not just your website software.

PHP Vulnerability 2026: Quick Facts

What Is PHP?

PHP is a programming language that runs on web servers and builds web pages before they reach your browser. When you load a blog post, log in to a site or add something to a shopping cart, PHP is often the code doing the work behind the scenes.

You never see PHP directly. You see the page it produces. That is why many people only learn the name when something goes wrong with it.

PHP matters because so much of the web depends on it. It powers roughly 70% of websites, including these popular platforms:

• WordPress
• Drupal
• Joomla
• Magento
• Nextcloud
• phpMyAdmin
• Roundcube webmail

Think of PHP as the engine, and WordPress or Drupal as the car built around it. A problem in the engine affects every car that uses it, no matter how well each car is maintained. That is exactly the situation with the PHP vulnerability.

What Is the PHP Vulnerability? PHP2Shell Explained

PHP2Shell is a flaw in how PHP cleans up after it runs out of memory. Under the right conditions, an attacker can send a specially built web request that tricks PHP into running the attacker's commands on the server. This is called remote code execution, the most serious class of web vulnerability.

Why it is so serious

Most website vulnerabilities live in a plugin, theme or application. PHP2Shell lives one layer lower, in the PHP runtime. That has three consequences:

• Good website hygiene does not protect you. An up-to-date WordPress site with no risky plugins can still be exposed.
• The attack can happen before your site's code runs. PHP can be compromised while it is still reading the incoming request, before login checks or security plugins get a chance to act.
• Even a basic page can be vulnerable. With an unpatched PHP version and an affected configuration, a simple "Hello World" site is at risk.

How the PHP vulnerability works, in plain English

PHP has a safety setting called memory_limit that stops any single request from using too much memory. Normally, hitting that limit is harmless: PHP stops the request, cleans up and moves on.

Researchers found that hitting the limit at exactly the wrong moment leaves PHP confused:

1. PHP starts building an internal record, such as an entry in a list of form fields.
2. It marks the record as "ready" before it has finished writing it.
3. The memory limit is hit in between, and PHP abandons the task.
4. During cleanup, PHP trusts its "ready" mark and handles leftover data as if it were a real record.
5. An attacker who planted that leftover data earlier in the same request can steer the cleanup into running a command.

The clever part is how attackers trigger the memory limit on demand. A small request full of nested form fields and empty file uploads can balloon into hundreds of megabytes inside PHP. So size limits on uploads, such as post_max_size, do not stop it.

What an attacker gets

Code runs with the same permissions as the PHP process. That is not automatic full control of the server, but it is still very serious. PHP usually has access to your website files and the database password, so an attacker could read customer data, change pages or plant a backdoor.

One more detail worries defenders: the malicious request can come back with a normal 200 OK response. A successful-looking request in your logs is not proof that nothing happened.

PHP CVE: CVE-2026-109618 and CVE-2026-109619

PHP2Shell is tracked as two CVEs, CVE-2026-109618 and CVE-2026-109619, both rated 9.2 out of 10. A CVE (Common Vulnerabilities and Exposures) number is the official ID that security teams, scanners and vendors use to refer to a specific flaw.

Both CVEs come from the same root problem: PHP mishandling its own cleanup when it runs out of memory mid-task. They differ in where inside PHP the mix-up happens.

• One involves PHP's hash tables, the internal structure PHP uses for arrays and incoming request variables. PHP counts a new entry before it finishes creating it.
• The other involves stale pointers left behind when PHP exits a task early, which a later request can stumble on. Programmers call this a use-after-free.

If you saw a severity score of 10 on social media, that was wrong. On 20 October, the CVE numbers spread online with an incorrect score of 10 and an incorrect release time. The official rating is 9.2, which is still critical.

To track these CVEs, check the official PHP security announcements and the CISA Known Exploited Vulnerabilities Catalog.

Which PHP Versions Are Affected by the PHP Vulnerability?

Any PHP version older than the emergency releases below should be treated as vulnerable. PHP published these fixed versions on 21 October 2026 at 7 am Pacific time:

The scale of the problem is large. Shortly after the release, Censys reportedly counted around 1.5 million internet-facing servers advertising PHP versions older than the fixes. Another estimate put at least 1 million systems on PHP versions so old that PHP will not patch them at all.

If your server runs PHP 8.1, 7.x or older, there is no patch coming. Check the PHP supported versions page and plan a move to a supported branch.

How to check your PHP version

• On a server you manage: run php -v on the command line. Note that the command-line PHP can differ from the PHP serving your site.
• In WordPress: go to Tools → Site Health → Info → Server.
• On shared hosting: look in your hosting control panel, usually under "PHP version" or "PHP settings", or ask your host directly.

Is WordPress Affected by the PHP Vulnerability?

Yes. WordPress runs on PHP, so a WordPress site on an unpatched PHP version is exposed to PHP2Shell. Researchers demonstrated remote code execution against WordPress and 10 other PHP applications, and a separate researcher confirmed a working attack against an official WordPress Docker image.

The key point for WordPress owners: this is not a WordPress bug. Updating WordPress core, your theme or your plugins does not fix it. The fix has to happen in the PHP version your hosting runs.

What WordPress site owners should do

• On managed WordPress hosting: most managed hosts patch PHP for you. Check your host's status page or support announcements to confirm PHP was updated after 21 October.
• On shared hosting: check your PHP version in Site Health or the control panel. If it is below the fixed versions, switch to a patched version in your panel or contact your host.
• On a VPS or your own server: you are responsible. Update PHP through your operating system's package manager and restart PHP (see the checklist below).
• Running an old PHP version for an old plugin? Now is the time to replace that plugin. PHP 8.1 and older receive no fix.

A security plugin or firewall can block some attack attempts, but it cannot fully protect you. PHP itself said there was no complete mitigation short of updating.

Also remember the WordPress sites you do not think about: staging copies, old marketing microsites and client sites on forgotten servers. Each one needs checking.

PHP Vulnerability: What to Do Now

Update PHP, restart it, then check whether anyone got in before you patched. Follow these steps in order.

1. Find every place PHP runs. List your public websites, WordPress installs, internal tools and third-party services that depend on PHP. If you write no PHP yourself, you may still rely on it through WordPress or a vendor.
2. Check each PHP version. Compare it with the fixed versions above: 8.5.12, 8.4.27, 8.3.36 or 8.2.35.
3. Install the PHP update. Use your Linux distribution's packages, your hosting panel or the official PHP downloads page. Package servers were overloaded during release day, so retry if downloads time out.
4. Restart PHP. Restart Apache, PHP-FPM or whatever runs your PHP workers. New files on disk do nothing while the old PHP is still running in memory.
5. Confirm the new version is live. Check the version the website actually uses, not just the command line.
6. Take unpatchable systems offline. If a server runs PHP 8.1 or older, or you cannot update right away, consider taking it down until you can. National security agencies recommended exactly this.
7. Investigate from 17 October onward. Amazon detected an attack attempt on 17 October, before the public announcement. Review logs from that date for suspicious requests, unexpected files or new admin accounts, and check the indicators of compromise published in Amazon's threat report.
8. Keep watching official sources. Follow PHP's announcements, your distribution's security notices and the CISA catalog for updates.

Do not rely on these as fixes

• Setting memory_limit to -1. Removing the memory limit may block this specific trick, but it lets PHP eat all the server's memory. That swaps one problem for an easy way to crash your server.
• A firewall alone. Cloudflare and others added blocking rules early, which buys time. It is not a substitute for updating.
• Updating WordPress or plugins. Helpful in general, but it does not touch the PHP engine.
• Random "exploit checkers" from social media. Many public scripts for PHP2Shell do not work, and some may attack the computer that runs them.

PHP Vulnerability News: Timeline of What Happened

A planned, quiet release on 22 October turned into an emergency after leaks forced PHP to ship fixes a day early. Here is the timeline, newest first.

The NSA and government response

Governments treated the PHP vulnerability as a national-level threat:

• United States: the NSA, FBI and CISA issued warnings. The NSA recommended taking vulnerable systems offline if they could not be patched immediately.
• United Kingdom: the cyber minister told Parliament that 32 government services had been taken offline.
• Japan: the prime minister issued an early-morning warning urging organisations to patch PHP servers at once and to suspend websites if they could not.
• Netherlands: the National Cyber Security Centre took its own website offline, along with the Port of Rotterdam and other government services.
• Germany, France, Finland and Belgium: government services went dark as a precaution.

These shutdowns were defensive choices, not signs that the sites were hacked. Many organisations decided that a website offline for a few hours was safer than a website exposed without a patch.

The Chainguard controversy

The early Chainguard release split the security community. PHP argued that publishing a patched build early let attackers compare it with the old version and work out the bug while everyone else waited. Chainguard said attacks were already happening and it acted to protect customers, making the fixed images free. Both sides have a point, and the episode has restarted the debate on how security embargoes should work.

Is the PHP Vulnerability Being Exploited?

Attack attempts are certain; confirmed successful break-ins are still disputed. That gap is behind most of the arguments on Reddit and security forums.

The evidence for active attacks

• Amazon recorded an attempt on 17 October and later described PHP2Shell as broadly exploited, advising investigations from that date.
• watchTowr reported active exploitation of both CVEs.
• Cloudflare saw attempts jump from thousands before the announcement to tens of thousands within 45 minutes, hundreds of thousands within two hours and millions by the end of the day.

The evidence that attacks are harder than they look

• Many exploits sprayed at servers did not work reliably, or just crashed the target.
• Germany's cyber agency saw attacks but no successful exploitation, and said exploitation was more complicated than early coverage suggested.
• Dutch officials and the PHP Foundation reported no confirmed successful attacks within what they could see at the time.
• Many public "proof of concept" scripts fail against a standard PHP setup.

Why "hard to exploit" is not a reason to wait

A working exploit has to be tuned to each server's exact setup, which takes skill. But AI tools are making that tuning much faster. One researcher used AI agents to build a working attack against the official php:8.5.4-apache image in under two hours, inside an isolated lab, and also succeeded against an official WordPress image.

For comparison, a famous 2021 sudo bug took about three days to produce a first working exploit, even with full details published. With PHP2Shell, several people had working exploits within about 24 hours, without the details.

An attempt, a crash, a lab demo and a confirmed breach are different things. Millions of attempts do not mean millions of hacked sites. But the lack of confirmed breaches so far is not proof you are safe either.

Is the PHP patch complete?

Based on the evidence so far, yes. Some videos showed PHP still crashing after the update, but those examples used different, local bugs, not the remote PHP2Shell flaw. The patch works by delaying the out-of-memory error until PHP has finished its cleanup, which removes the unsafe moment the attack depends on.

PHP Vulnerability FAQ

Sources

• PHP security announcements, 2026 archive
• PHP supported versions
• PHP downloads
• PHP memory_limit documentation
• Calif: PHP2Shell technical write-up
• CISA Known Exploited Vulnerabilities Catalog