On October 21, 2026 the PHP project shipped emergency fixes for two critical flaws in the PHP engine itself. Together they are being called PHP2Shell, and they let an attacker with no login and no password run code on a web server that uses PHP. Exploit attempts were already hitting the internet before the patch was out.

PHP runs a huge share of the web. WordPress, WooCommerce, Magento, Drupal, Joomla, Laravel apps, client portals, booking systems, and plenty of the custom line-of-business software that small businesses depend on. If your company has a website or a web application, there is a good chance PHP is underneath it, even if nobody on your team has ever heard the word.

What Is PHP2Shell?

PHP2Shell is two separate bugs, tracked as CVE-2026-109618 and CVE-2026-109619. Both are rated 9.2 out of 10 on CVSS v4.0.

CVE-2026-109618 sits in how PHP cleans up when it runs out of memory partway through setting up a request. Half-built request data gets treated as if it were valid, and an attacker can steer that.
CVE-2026-109619 is a use-after-free in the state PHP keeps between requests on the same worker. One request leaves behind a pointer to memory that has already been released, and a later request can use it. Session upload progress handling is part of one confirmed attack path.

The important part for a business owner: these are bugs in PHP, not in your website's code. A perfectly written, fully updated WordPress site is still exposed if the PHP version underneath it is vulnerable. Updating your plugins does nothing here.

The flaws were found by Wiz Research, Calif, and OpenAI's Codex Security team. The vulnerable code has been in PHP for more than a decade, and the affected range reportedly goes all the way back to PHP 5.4.

Why This One Is Serious

Most web vulnerabilities need something specific to line up: a certain plugin, a certain setting, a logged-in user. PHP2Shell needs very little.

No authentication. The attacker does not need an account on your site.
It can fire before your application runs. On Apache with mod_php, a demonstrated exploit triggers from a single unauthenticated request before any of your site's code executes. Your security plugin never gets a chance to see it.
It leaks secrets even without full takeover. Researchers showed they could read PHP worker memory remotely. That memory can hold passwords, session tokens, API keys, and certificates from other people's requests. So even a "failed" attack can walk away with credentials.
The timeline collapsed. Details leaked on social media on October 20, a researcher accidentally posted a video of a working exploit that evening, and PHP moved its release up a day. Amazon's threat intelligence team says it saw an exploitation attempt against its honeypots on October 17, four days before the fix existed.

The reaction from large organizations tells you how seriously this is being taken. BambooHR took its service offline in the US, Canada, and Ireland as a precaution. In the Netherlands, DigiD, MijnOverheid, the parliament's website, and the national cyber security center's own site went offline while they patched. CISA's guidance is to take PHP systems offline if they cannot be patched, or if they run PHP 8.1 or older.

As of October 22, watchTowr and Cloudflare report active exploitation attempts, and Amazon describes PHP2Shell as broadly exploited in the wild. No specific confirmed breach had been publicly reported yet, and CISA had not added either CVE to its Known Exploited Vulnerabilities catalog. That will likely change. When it does, you want to already be patched.

Who Is at Risk

According to the PHP project, every PHP installation that serves web requests is at risk. That includes PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed. In practical terms:

WordPress and WooCommerce sites, especially on budget shared hosting where you have no control over the PHP version and no idea when your host will update it
Client portals, intake forms, and booking systems built on PHP, which often handle exactly the kind of data you do not want leaked: patient details, payment info, logins
Old servers nobody touches. The internal app a developer built in 2017 that "just works" is the most likely place to find PHP 7.x, and it may never get an official fix
Vendor appliances and software that bundle PHP internally. Even some security products ship with it

If you are running PHP 8.1 or older, there is no official patched release. The PHP security team published minimal source backports for 7.4, 8.0, and 8.1, but anything from 5.4 through 7.3 gets no fix at all. Phoenix Security estimates roughly 884,000 internet-facing hosts are on end-of-life PHP versions with no fix available. The only real answer for those systems is an upgrade.

What to Do This Week

1. Find Every Place PHP Runs

List your websites, portals, and web apps, and find out who hosts each one
For each, get the exact PHP version. Your hosting control panel usually shows it. On a server you manage, php -v tells you the CLI version, but check what the web server is actually using too, since they can differ
Ask your software vendors directly whether their products bundle PHP and whether they have shipped an update

2. Patch to a Fixed Version

The fixed releases are PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35
If you install PHP from Linux distribution packages, the version number may look old even after the fix lands, because distributions backport patches. Check the package changelog for the CVE numbers instead of trusting the version string
Restart PHP after updating. Running workers keep the old code in memory until they are restarted
PHP 8.2 reaches end of life on December 31, 2026. If you are on 8.2, patch now and plan the move to 8.4 or 8.5 while you are in there

3. If You Cannot Patch Today

These are partial measures. The PHP team is clear that updating is the only complete fix. But they reduce exposure while you schedule the work:

Set session.upload_progress.enabled=0, and on PHP 8.5 also set fatal_error_backtraces=0. This blocks the confirmed session-based paths for CVE-2026-109619
For CVE-2026-109618, PHP's guidance is to set memory_limit=-1 so applications cannot override it, keep post_max_size low, and enforce request size limits at the web server or proxy
Restart every PHP worker after changing settings
Put the site behind a web application firewall. Cloudflare has deployed rules for known PHP2Shell attack patterns, including on its free plan, but attackers are already changing payloads to get around them
If a system cannot be patched at all, take it off the public internet until it can

4. Check for Signs of Compromise Back to October 17

Look for unusual multipart requests followed by memory-limit errors or bursts of HTTP 500 responses
Watch for unusually large PHPSESSID cookies in responses
Flag PHP worker restarts you cannot explain
Look for new files in your web directories, new admin users in WordPress, and scheduled tasks nobody created

5. Rotate Secrets on Anything That Was Exposed

Because of the memory leak, patching does not undo what may already have been read. If an internet-facing PHP server was unpatched after October 17, treat the secrets it handled as possibly exposed. That means database passwords, API keys for payment processors and email services, admin passwords, and session tokens. Rotate them after you patch, not before, or the new ones can leak too.

The Bigger Pattern

The researchers behind PHP2Shell say AI models helped them turn these bugs into working exploits, with one researcher doing in about a week what would normally take a team months. This is the second time this year we have written about that pattern. In April, Copy Fail went from research finding to working cross-distribution Linux exploit in days.

The gap between "bug found" and "attacks start" is now measured in days or hours. Here it was negative: attempts began before the fix shipped. A business that patches its website when someone gets around to it, or whose web host updates PHP on its own schedule, is going to be on the wrong side of that gap more and more often.

How ITP 360 Can Help

Most of the businesses we talk to do not know what PHP version their website runs on, who is responsible for updating it, or whether the developer who built their portal is still around. That is normal. It is also exactly the situation where a flaw like this turns into a breach.

Here is what we do for clients during an event like PHP2Shell:

Exposure check. We inventory your websites, portals, and servers, identify every PHP installation and its version, and tell you which ones are vulnerable
Patching and hardening. We update PHP, restart workers, apply the interim mitigations where a patch has to wait, and put a web application firewall in front of anything public
Compromise review. We go through web server and PHP logs back to October 17 looking for the indicators above, and check for web shells, rogue admin accounts, and unexpected changes
Credential rotation. We rotate the database passwords, API keys, and admin logins tied to exposed systems, and coordinate with your vendors where needed
Upgrade path for end-of-life PHP. For sites stuck on PHP 7 or 8.1, we plan and carry out the move to a supported version so you are not in this position again

Our managed IT and cybersecurity clients get this work as part of their service. If you are not a client and you want a fast answer on whether PHP2Shell affects you, contact our team for a free exposure review. We will tell you what you are running, what needs to happen, and how quickly.

Bottom Line

PHP2Shell is a remote, unauthenticated code execution flaw in the software behind a large part of the web, with attacks already underway. If your business has a website, portal, or web app, find out today what PHP version it runs and get it patched to 8.5.12, 8.4.27, 8.3.36, or 8.2.35. If it is on PHP 8.1 or older, it needs an upgrade, and until then it should not be facing the internet.

PHP2Shell: Two Critical PHP Flaws Put Business Websites at Risk