PHP2Shell: What the Critical PHP Flaw Means for Your Business Website

A plain-English guide for service business owners, plus the exact steps for whoever runs your server

Oct 21, 2026 · 6 min read

On October 21, 2026, the PHP project shipped emergency fixes for two critical security flaws known together as PHP2Shell (CVE-2026-109618 and CVE-2026-109619). If your business website, booking form, or customer portal runs on PHP, and most of the web does, this one deserves your attention today.

What happened, in plain English

PHP is the programming language that powers a huge share of websites, including anything built on WordPress, Drupal, Joomla, or Laravel. Researchers from Wiz, OpenAI and Calif found that PHP itself can be tricked when a web request ends abnormally, for example when the server runs out of memory partway through. In that moment PHP can leave its internal memory in a broken state, and a skilled attacker can use that to run their own code on your server.

The scary parts:

No login needed. An attacker doesn't need a password or an account on your site.
Your website's code doesn't have to be buggy. The flaw lives in PHP itself, so even a well-built site is exposed until PHP is updated.
It's old. The underlying problem reaches back to PHP 5.4, so older sites are affected too.
Attacks are already happening. Details leaked before the official fix, and Cloudflare reported seeing attack traffic before the patch was even public.

PHP's own team rated both flaws 9.2 out of 10 for severity. The UK's National Cyber Security Centre went as far as telling organizations to update immediately or take PHP systems offline until they can.

Why a plumber or HVAC company should care

If someone takes over your web server, they're not just defacing a homepage. They can reach whatever that server touches: customer names and phone numbers from your contact forms, job addresses, estimates and invoices, and sometimes the passwords used to connect to your email or payment tools. For a small service business, a breach like that costs more than money. It costs the trust you've built one job at a time.

Am I affected?

You're likely affected if your website or any web app you use runs on PHP and hasn't been updated since October 21, 2026. That includes every common way PHP is served: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed.

The quickest way to find out:

On a hosted website builder or managed WordPress host: email your host and ask, "Have you patched PHP2Shell (CVE-2026-109618 and CVE-2026-109619)?" Get a yes in writing.
If a web developer or IT person manages your site: forward them this article and ask them to confirm the PHP version.
If you run your own server (for example on AWS EC2, DigitalOcean or a VPS): the patch is your responsibility. Keep reading.

The fix: update PHP

Updating is the only complete fix. Temporary settings and firewalls help, but PHP's developers have been clear that none of them fully block an attack. The patched versions are:

PHP 8.5.12
PHP 8.4.27
PHP 8.3.36
PHP 8.2.35

If you're on PHP 8.1 or older, the PHP project no longer ships updates for those versions. Check whether your Linux distribution or support vendor offers a backported fix, and plan an upgrade to a supported version either way.

For whoever runs the server

Update PHP through your system's package manager, then restart PHP so the new version is actually loaded:

Ubuntu / Debian: sudo apt update && sudo apt upgrade 'php*'
RHEL / Rocky / Alma: sudo dnf upgrade 'php*'
Amazon Linux 2023: sudo dnf check-update 'php*', then upgrade. Watch the Amazon Linux security page, since AWS's packages may lag the upstream release.

Then restart: sudo systemctl restart php-fpm (or php8.x-fpm, or apache2/httpd if you use mod_php). Confirm the version with php-fpm -v. Check the web-serving PHP, not just the command line, because they can use different settings.

If you can't patch today

These stopgaps from the PHP security team reduce exposure while you wait for a package. They are not a substitute for updating.

Set session.upload_progress.enabled=0 and restart every PHP worker.
On PHP 8.5, set fatal_error_backtraces=0 and restart workers.
Set a low post_max_size: 8M if your site doesn't take file uploads, 32M if it does.
Put the site behind a web application firewall. Cloudflare customers on free and paid plans have had protection rules enabled by default since early October 21.

After you patch

Look for signs of a break-in. Because attacks started before the fix, check your web folders for unfamiliar PHP files and scan your logs for odd requests from the past few days.
Rotate secrets if anything looks off. Change database passwords, API keys and email credentials stored on the server.
Watch for a behavior change. Patched PHP now stops a process immediately when it hits its memory limit, without running shutdown code. Most sites won't notice, but custom code that relied on cleanup at shutdown might.

The bigger lesson

PHP2Shell is a reminder that your website isn't a brochure you set up once and forget. It's software, and software needs someone watching it. Researchers noted these flaws sat in PHP for many years and that AI tools helped turn them into working attacks, which means bugs like this will be found and weaponized faster from here on out.

For a busy service business, the practical takeaway is simple: know who is responsible for updating your website, and make sure they move the same day a critical fix lands. If the honest answer is "nobody," that's the real risk to fix.