Who patches your site?

Whether you need to do anything depends on who controls the server your site runs on. The size of your business and the theme you use don't change it. Pick the setup that sounds most like yours.

Where does your website live?

Pick the option that sounds most like you. You'll get the answer for your setup here, including when the honest answer is that you don't need to do anything.

What happened

PHP is the programming language behind a large share of the web, including every WordPress site. W3Techs finds it on 69.3% of websites whose server-side language it can detect. On October 21, 2026, the PHP project released fixes for two flaws it rates 9.2 out of 10, and the pair became known as PHP2Shell (PHP advisory).

Both let an attacker run their own code on a web server without logging in. CVE-2026-109618 is set off when a memory failure interrupts PHP partway through handling a request and leaves half-built data behind. CVE-2026-109619 comes from leftover data that outlives its request inside PHP's long-running worker processes, and PHP says it can also expose memory. One change to how PHP cleans up after an aborted request fixes both.

AI tools helped find them. Calif, a security firm, found the bugs in August while auditing PHP under OpenAI's Patch the Planet program, and Wiz Research reported the same problem on its own on August 24 (Calif, Wiz). CNBC reports that Calif used OpenAI's GPT-5.6 Sol, and Wiz used its own agent alongside Google's Gemini 4 Argon and GPT-5.6 Sol.

The release was planned for October 22. After the CVE IDs leaked on October 20, PHP moved it up a day. About half an hour later, Calif accidentally posted, then deleted, a video of its working exploit (PHP Foundation). Calif's write-up shows code running on WordPress, Drupal, Joomla, Magento and Laravel sites, and heise reports the Laravel demo got there in 38 seconds.

Timeline

  1. Aug 1 to Aug 21

    Calif finds the bugs while auditing PHP under OpenAI's Patch the Planet program and reports them on August 11 and August 21.

    Calif, The PHP Foundation

  2. Aug 24

    Wiz Research reports the same problem independently.

    Wiz Research

  3. Oct 17

    Amazon's honeypots log an exploitation attempt, four days before public disclosure.

    AWS Security Blog

  4. Oct 20, about 15:00 UTC

    The CVE IDs leak, including in a Hacker News post, with a wrong 10.0 severity score.

    The PHP Foundation, Hacker News

  5. Oct 20, 19:30 UTC

    Because of the leak, PHP moves the release forward by a day.

    The PHP Foundation

  6. Oct 20, about 20:00 UTC

    Calif mistakenly posts a video of its working exploit, then deletes it.

    The PHP Foundation

  7. Oct 21, 03:02 UTC

    Cloudflare switches on firewall rules for free and paid plans.

    Cloudflare

  8. Oct 21, 14:00 UTC

    PHP releases 8.5.12, 8.4.27, 8.3.36 and 8.2.35. CISA and the NSA tell organizations to patch.

    PHP, CISA, NSA

  9. Oct 22

    Cloudflare's CEO reports millions of attempts. The UK government takes 32 online services offline as a precaution.

    Matthew Prince on X, The Register

  10. Oct 23

    PHP discloses a third, narrower bug, CVE-2026-115560, with no emergency fix. Neither main CVE is on CISA's exploited list.

    PHP, CISA

Is anyone actually being hacked?

There have been a lot of attempts. As of October 23, nobody has publicly confirmed a successful break-in.

Cloudflare's CEO, Matthew Prince, said attempts across its network went from thousands before the announcement to "hundreds of thousands within 2 hours, and millions now" by early October 22, UTC (his post on X). Amazon's honeypots caught an attempt on October 17, four days before public disclosure. Amazon now describes widespread exploitation attempts and says it's unclear whether any of them would have worked (AWS).

Some context keeps this in proportion. Sophos reported one successful exploitation on October 22, then retracted it that evening (Sophos). Wordfence said the same day that it knew of no compromises (Wordfence), and The Register still found none publicly confirmed on October 23 (The Register). CISA, which keeps the US government's list of vulnerabilities known to be exploited, hadn't added either CVE as of its October 23 catalog (CISA KEV).

Many of the public "exploits" don't work. The PHP Foundation told CNBC that the ones it had seen were incomplete or broken, and heise found that triggering one of the bugs can take several thousand requests. That slows attackers down. It isn't a reason to wait, because the researchers' own exploits do work.

Which PHP versions are fixed

Your PHPStatusWhat to doSource
8.5Fixed in 8.5.12Update.PHP
8.4Fixed in 8.4.27Update.PHP
8.3Fixed in 8.3.36Update. Security fixes continue until December 31, 2027.PHP, PHP
8.2Fixed in 8.2.35Update, then plan a move. Security support ends December 31, 2026.PHP, PHP
8.1, 8.0, 7.4No official release. PHP published source patches, and some vendors shipped patched builds.Ask your host what they installed. Plan a move to 8.3 or newer.PHP on GitHub, CloudLinux
7.3 and olderCVE-2026-109619 still applies, back to PHP 5.4. Nothing from PHP.Upgrade. A few vendors, such as CloudLinux and Hostinger, patched these too.NIST NVD, CloudLinux, Hostinger

Don't judge a server by its version number alone. Linux distributions and hosts often apply the fix to the version you already have and keep its number. On Ubuntu 26.04 LTS the patched PHP 8.5 package is 8.5.4-0ubuntu1.5 (Ubuntu), and GoDaddy says a patched site can still report 8.5.11 or 8.2.34. A build dated October 21, 2026 or later, or a changelog that names both CVEs, is better evidence.

On PHP 8.1 or older there's no official release to install. cPanel backported fixes to its PHP 7.4, 8.0 and 8.1 packages, and CloudLinux patched every version from 5.2 to 8.5 on CloudLinux 7, 8 and 9 (CloudLinux). Hostinger shipped patched builds from 5.2 to 8.5 on its shared and cloud plans (Hostinger). CentOS 7 itself gets nothing, so patched PHP there means paying for TuxCare's extended support or using a third-party build (TuxCare). Moving to a supported PHP version is the fix that lasts.

How to check your PHP version

  • WordPress: go to Tools, then Site Health, open the Info tab and expand Server (WordPress.org).
  • cPanel: MultiPHP Manager shows the version each domain uses (cPanel). On servers running CloudLinux, the menu is called Select PHP Version.
  • Your own server: run php -v and php-fpm -v, or the versioned names such as php8.3 -v. The command line can run a different PHP than your website, so check the one that serves pages (Wordfence).

None of these tells you whether the build is patched. They tell you which branch you're on, and so whether a fix exists and who should have installed it.

Two emails to send today

Most owners don't need to touch a server. They need a straight answer from whoever runs it. Copy whichever email fits, add your domain and send it.

To your hosting company

Subject: PHP2Shell (CVE-2026-109618 and CVE-2026-109619) on [your domain]

Hi,

Can you confirm that the server running [your domain] has a PHP build that fixes CVE-2026-109618 and CVE-2026-109619?

Please tell me which PHP version and build are installed, and the date the update went in. If the site is on PHP 8.1 or older, what are my options for moving to a supported version?

Thanks,
[Your name]
To your designer, agency or freelancer

Subject: Has our website been patched for PHP2Shell?

Hi [name],

You've probably seen the PHP2Shell news. Could you tell me:

1. Who updates PHP on the server our site runs on: you, or the hosting company?
2. Which PHP version is it on now, and when was the fix for CVE-2026-109618 and CVE-2026-109619 installed?
3. Has anyone looked at the server logs from October 17 onward for anything unusual?

If this isn't covered by our current arrangement, let me know what it would take.

Thanks,
[Your name]

A useful reply names a version and a date. If you get "we're secure" with no details, ask again.

Get a free check from an engineer

Send us the address. Within one business day an engineer will tell you what the site runs on, who hosts it, who is responsible for patching PHP and the exact question to ask them. If the server shows its PHP version publicly, we'll tell you that too. Most hide it, and we'll say so rather than guess.

We only look at what any visitor's browser can see. Scanning or testing your server needs your written permission, and we don't do it as part of a free check. If you need the patch done and nobody owns the server, we'll quote a fixed price before touching anything and give you a written note of what changed. If you don't need us, we'll tell you that.

An engineer replies within one business day. We only look at what any visitor's browser can see, and we never scan or test your server without your written permission. See our privacy policy.

If you run your own server

If you manage the server, this one is yours. In order:

  1. Update PHP from wherever it came from: your distribution's packages, your control panel (cPanel's EasyApache, CloudLinux's alt-php) or a tool like Laravel Forge. Forge's automatic security updates don't patch PHP, so do it by hand (Laravel Forge).
  2. Restart PHP-FPM, or Apache if it runs mod_php, so the new build is the one serving requests. Laravel Forge also reminds you to restart long-running PHP workers such as queues (Laravel Forge).
  3. Check the version the web server uses, not only the command line.
  4. Go through your logs back to October 17 (what to look for is below), and keep logs from at least the 48 hours before the release (AWS, Wordfence).
  5. If the server sat exposed and unpatched, change database passwords and API keys. One of the flaws can leak memory, and Sansec says that memory can hold passwords, session tokens, API keys and TLS private keys (Sansec).
Update and verify
# Debian or Ubuntu
sudo apt update && sudo apt upgrade

# RHEL, AlmaLinux, Rocky
sudo dnf upgrade 'php*'

# Restart PHP so the new build is the one serving requests
# (match your version; restart apache2 or httpd too if it runs mod_php)
sudo systemctl restart php8.3-fpm

# Check the version the web server uses, not just the command line
php8.3 -v
php-fpm8.3 -v

If you can't update today

PHP lists stopgaps and is clear that only updating fixes the problem completely (PHP advisory):

  • Turn off session upload progress (session.upload_progress.enabled = 0) and restart every worker. That covers the confirmed path for CVE-2026-109619 and the newer CVE-2026-115560.
  • Keep request bodies small with post_max_size: 8M if the site takes no uploads, 32M if it does.
  • On PHP 8.5, set fatal_error_backtraces = 0.
  • Setting memory_limit = -1 through php_admin_value, so apps can't override it, reduces the risk from CVE-2026-109618, though a failed memory allocation can still reach the bug. One request can then use all the server's memory, so put a container or cgroup memory cap around PHP. Don't use RLIMIT_AS or RLIMIT_DATA instead, because PHP says they trigger the same bug.
php.ini
; Stopgaps from PHP's advisory. Remove them once PHP is updated.
; Turn off session upload progress (covers the confirmed CVE-2026-109619 path)
session.upload_progress.enabled = 0

; Keep request bodies small: 8M if the site takes no uploads, 32M if it does
post_max_size = 8M

; PHP 8.5 only
fatal_error_backtraces = 0

A firewall in front of the site helps while you work. Cloudflare's rules are on by default for free and paid plans, AWS added rules to its managed PHP rule set, Fastly's have to be switched on, and Bunny Shield's only block in blocking mode (Cloudflare, AWS, Fastly, bunny.net). Sansec goes further and suggests temporarily blocking multipart form uploads on every PHP site, accepting that uploads break until you patch (Sansec).

Why security plugins aren't the fix

A WordPress security plugin is PHP code running inside the same PHP that has the bug. PHP confirmed that one attack path runs before any application code, which means before WordPress and its plugins have loaded (PHP advisory).

The plugin makers say as much. MalCare says its firewall can't block PHP2Shell. Wordfence says its firewall intercepted more than 74,000 exploit or probing attempts (Wordfence), and also that some attacks can begin before WordPress starts and that updating and restarting PHP is essential (Wordfence). Patchstack warns against unofficial fix plugins and copied snippets. WordPress says no WordPress update is required or planned (WordPress.org), and WooCommerce says the same for WooCommerce.

Keep your plugin if you like it. Just don't count it as the fix.

Signs of a break-in since October 17

Amazon recommends investigating from at least October 17, when its honeypots logged the first attempt (AWS). Worth checking:

  • PHP files you don't recognize, especially in upload folders, plus new admin accounts, unexpected scheduled tasks and odd outgoing connections (Sucuri).
  • Upload requests followed by memory-limit errors or HTTP 500 errors, unusually large PHPSESSID cookies, and PHP workers restarting for no clear reason. Patchstack points out these aren't proof either way (Patchstack).
  • PHP processes starting a shell, which Datadog calls the most direct evidence of a successful attack (Datadog).

If you find something, don't wipe the server yet. Logs and strange files show what happened and when, and you'll need them for the cleanup, for your insurer and for any notification duties. Bring in someone who does incident response, and ask a lawyer whether your state's breach-notification rules apply.

Sites people forget

Patching the main website isn't always the end of it. These often run PHP too and get missed:

  • Old blogs and landing pages on subdomains
  • Staging and test copies of your site
  • Booking, quote and client-portal pages a vendor set up years ago
  • Webmail such as Roundcube and database tools such as phpMyAdmin on your hosting account

Anything on the same server that uses a patched PHP build is covered. Many servers run several PHP versions side by side, so check each one. Anything on another server needs the same check.

Should you take your site offline?

Only if you can't patch it. CISA says organizations that can't update right away, or that run PHP 8.1 or older, should take PHP systems offline until they're patched (CISA). The NSA gives similar advice for systems that can't be updated right away (NSA), and the UK's NCSC suggests considering it only when PHP's stopgaps can't be applied either (NCSC).

For a small business that comes down to this. If your host has patched, stay online. If you run the server and can't update today, apply the stopgaps. If you can do neither, a few hours offline costs less than cleaning up a hijacked server.

Headlines to ignore

What you might readWhat's true
"70% of websites were hacked"PHP runs 69.3% of websites whose server-side language W3Techs can detect. That's how many sites use PHP, not how many were hacked.
"It's a perfect 10 out of 10"The leaked IDs came with a 10.0. PHP's own score is 9.2 (PHP Foundation).
"The NSA told everyone to take their sites offline"Its advice applies only if you can't update right away (NSA).
"Every PHP site is being exploited"There are millions of attempts. As of October 23, no successful break-in has been publicly confirmed (The Register, Sophos).
"Install this plugin to fix PHP2Shell"No plugin can update PHP. Patchstack and MalCare both warn against "fix" plugins and copied snippets.
"60% of small businesses close within six months of a cyberattack"Nobody has found a source for this number, and the group it's usually credited to says it didn't come from its research (Nextgov).

What's next

PHP 8.2 stops getting security fixes on December 31, 2026 (PHP). If you just patched to 8.2.35 you're covered for PHP2Shell, and you have about ten weeks to move to 8.3 or newer before the next flaw lands on a version nobody fixes.

PHP also disclosed a third, narrower bug on October 23, CVE-2026-115560. It only affects apps that switch PHP's session serializer at runtime in one particular way, which PHP considers unlikely, so the fix will come in the regular release cycle instead of an emergency one (PHP, The Register). Until then PHP suggests keeping session upload progress off. Apps that never change the serializer at runtime can leave it on.

The rest of the week

PHP2Shell wasn't the only problem this week. If your business builds software or uses AI tools, these matter too:

  • Node.js fixed 10 security bugs on October 21, including CVE-2026-111497, an out-of-bounds write in its Brotli decompression code reachable through node:zlib. Update to 22.23.4, 24.22.1 or 26.12.1 (Node.js).
  • GitLab patched CVE-2026-110264, a 10.0-rated bug that lets an attacker run code on self-managed GitLab without logging in. It affects every version since 7.0 in 2014. GitLab.com was already patched, and Ruby shipped matching fixes on October 23 (GitLab, Ruby).
  • A malicious LiteLLM release, 1.107.0, sat on PyPI for under two hours on October 21 and stole credentials from machines that installed it. Wiz counts about 49,000 downloads. The last safe version is 1.106.2 (LiteLLM, Wiz).
  • Railway said some customer environment variables may have been decrypted and told everyone to rotate secrets (Railway). OpenCode said AI provider keys stored in its hosted console may have been exposed (The Hacker News).
  • Browsers blocked eight eMudhra intermediate certificates between October 17 and 20 after their private keys turned out to be tiny numbers (Mozilla Bugzilla, The Hacker News), and Mozilla removed emSign root certificates (NSS release notes). This only matters if your SSL certificate came from eMudhra or emSign.
  • Axios reported, citing unnamed sources, that big US banks are dealing with unauthorized AI agents inside customer accounts. Morgan Stanley said it hadn't seen rogue agents on its platforms (Cybersecurity News). The practical lesson: don't give an AI assistant your banking login.

Questions people ask

Will updating WordPress or my plugins fix PHP2Shell?

No. PHP2Shell is a flaw in PHP, the language WordPress runs on, so the fix is a PHP update on the server. WordPress says no WordPress update is required or planned. On managed or shared hosting your host installs it. On a VPS, you or your developer do.

Does a security plugin like Wordfence protect my site?

Not reliably. Plugins run inside WordPress, and PHP confirmed one attack path that fires before any application code runs. MalCare says its firewall can't block PHP2Shell. Wordfence says its firewall intercepted more than 74,000 exploit or probing attempts, and that updating and restarting PHP is essential. Treat a plugin as an extra layer, never as the fix.

Does an attacker need my password?

No. Both flaws can be triggered by web requests from someone who isn't logged in and needs no account on your site. A site with no login form, shop or plugins is still in scope, because the problem sits in PHP itself, underneath whatever the site is built with.

I'm on shared hosting and can't run commands. What can I do?

Ask your host in writing whether your server runs a PHP build that fixes CVE-2026-109618 and CVE-2026-109619, and when it was installed. Check your PHP version in the control panel. If it's 8.1 or older, move to 8.3 or newer, ideally after testing on a staging copy.

My host says my site is "protected." Does that mean patched?

Not always. "Protected" can mean a firewall rule that blocks known attack patterns, like Cloudflare's, which only covers traffic routed through Cloudflare. "Patched" means the PHP on your server has the fix. Some hosts did both. Ask which one applies to your server, and ask for a date.

My PHP version is lower than the fixed release, but my host says it's patched. Who's right?

Possibly both. Linux distributions and hosts often patch an older version without changing its number. On Ubuntu 26.04 LTS the patched PHP 8.5 package is 8.5.4-0ubuntu1.5, and GoDaddy says patched sites can still show 8.5.11 or 8.2.34. Look for a build date of October 21, 2026 or later, or ask for the changelog.

My site doesn't take payments. Is it still a target?

Yes. Attackers want the server, not only card numbers. A hijacked site can send spam, host phishing pages, redirect your visitors or capture what people type into your forms. One of the flaws can also leak memory, which Wiz says can include passwords and API keys from other requests.

Are Wix, Squarespace and Shopify sites affected?

You can't patch PHP on those platforms and you don't need to, because the platform runs the servers. Webflow says its core services aren't built on PHP. We couldn't find a PHP2Shell statement from Wix, Squarespace or Shopify as of October 23, so ask their support if you want it confirmed.

Should I take my website offline?

Only if you can't patch it. CISA says organizations that can't update right away, or that run PHP 8.1 or older, should take PHP systems offline until they're patched. The NSA gives similar advice for systems that can't be updated right away. If your host has already patched your server, you don't need to.

I'm stuck on PHP 7.4 or 8.1. Now what?

PHP shipped no official release for 8.1 or older. Some vendors patched those versions anyway: cPanel backported fixes for 7.4, 8.0 and 8.1, and CloudLinux and Hostinger shipped patched builds back to PHP 5.2. Ask your host which applies to you, then plan a move to PHP 8.3 or newer.

I look after a lot of client sites. Where do I start?

Sort them by who controls PHP. Servers you run come first, especially Apache with mod_php, where PHP confirmed the most direct attack path. Sites on PHP 8.1 or older come next. Sites on managed hosts usually need only written confirmation from the host. Keep notes, because clients will ask.

What changed

  • : Published. Facts checked against PHP, CISA, the NSA, host status pages and vendor advisories at 6:45 pm ET, including the third bug (CVE-2026-115560) PHP disclosed today. CISA's exploited list was checked again at publication and still doesn't include either PHP2Shell CVE.

Sources

Every claim above links to its source. Here they are in one place, checked on October 23, 2026, 6:45 PM ET.

PHP and government advisories

Researchers and security vendors

News and statistics

Get the next one in plain English

When a vulnerability like this hits business websites, we'll send a short email: what happened, whether you need to do anything and how to check. We stay quiet when it doesn't affect you.

Plain-English alerts, sent only when a vulnerability affects business websites. We'll email you a link to confirm. Unsubscribe anytime.

Written by Hudson Shimanyula, Engineer at InfinityEdge Technologies. Spotted a mistake or have a question? Email services@infinityedgetech.com and we'll correct it.