Updated October 22, 2026. This is a fast-moving story, and we'll update this article as official guidance changes.

On October 21, the PHP project released fixes for PHP2Shell, two critical vulnerabilities that can let an attacker run code on a vulnerable PHP web server without logging in. How exposed a given site is depends on how its server runs PHP. Researchers demonstrated working attacks against WordPress, Drupal, Joomla, Laravel, Magento and several other platforms, and Amazon's threat intelligence team says it observed an exploitation attempt against its honeypots on October 17, four days before public disclosure.

If you're a marketing director, there's a good chance your website runs on PHP and a good chance you don't know which version. That's normal. The website is yours; the server usually belongs to a host, an IT team or the agency that built it. This article is for the person in between: what PHP2Shell is, whether it affects you, and what to ask the people who manage your server today.

What PHP2Shell is, in plain terms

PHP is the programming language behind about 69% of websites whose server language is known, according to W3Techs, and WordPress is built on it. PHP2Shell is the name researchers gave to two flaws in PHP itself, tracked as CVE-2026-109618 and CVE-2026-109619.

The first is triggered when PHP runs out of memory partway through setting up a request, then cleans up data that was never finished. The second involves leftover data from one request being reused by a later one, which can belong to a different visitor. Both can lead to remote code execution, meaning an attacker can run their own commands with the same permissions as your website. PHP rates both 9.2 out of 10 under CVSS v4.0. Early reports of a perfect 10.0 score were wrong, according to the PHP Foundation.

The fixed releases are:

• PHP 8.2.35
• PHP 8.3.36
• PHP 8.4.27
• PHP 8.5.12

PHP 8.1 and older no longer receive normal upstream releases. PHP says it provided minimal source patches for 7.4, 8.0 and 8.1, and vendors such as Red Hat and Ubuntu have published fixed packages for some older versions. Ask your host which exact package is installed and whether its security advisory lists both CVEs as fixed.

How the bugs were found matters too. The PHP Foundation says Calif and OpenAI independently reported the same root cause on August 11, and Wiz Research reported its own findings later that month. All three describe AI tools as part of their research, though their accounts of what the tools did differ, and Calif says its researcher directed the work. For anyone responsible for a website, the signal is that serious flaws are being found faster, and exploits are following them faster.

Is your website affected?

If your site runs on WordPress, Drupal, Joomla, Magento, Laravel, Symfony or any other PHP software, assume yes until someone confirms the server's PHP has been updated. That includes managed hosting. Many hosts patch quickly, but "probably" isn't a confirmation.

Two things trip people up. First, updating your CMS doesn't fix this. Clicking update on WordPress core, plugins or themes is good hygiene, but PHP2Shell lives one layer down. The PHP installation on the server needs updating, and the PHP workers need to be restarted.

Second, a low version number isn't automatically bad news. Linux vendors like Red Hat often patch older versions without changing the main version number, so a server reporting PHP 7.4 may already be fixed. Your host or IT team can confirm from their package records.

How your server runs PHP also matters. The clearest attack works against Apache with mod_php, where a request can trigger the flaw before your site's own code runs. PHP-FPM, a common setup on modern hosts, is not immune, but the demonstrated attack against it depends on how the site's code handles certain requests and on a later request reaching the same server process. Either way, the fix is the same: update PHP.

If your site is on a hosted platform like Webflow, Squarespace or Shopify, you don't manage a PHP server at all. The platform is responsible for its own infrastructure, so your action is checking whether it has published a statement.

Why this is a this-week problem

Several signals point the same way. AWS observed an attempted exploit against its honeypots on October 17. After disclosure it saw more attempts and described PHP2Shell as being broadly exploited in the wild, though its report covers activity against its own sensors and doesn't confirm widespread compromise of customer sites. Cloudflare reported live attack traffic against its customers, and CISA, the U.S. cybersecurity agency, issued an alert calling for immediate patching.

The damage can go well past a defaced homepage. Wiz demonstrated that one attack path leaks live server memory, which may contain passwords, login tokens and API keys from other requests or from the server itself. For a marketing site, that could include credentials for your CRM, marketing automation or analytics integrations.

A note on the headlines. You'll see "70% of the internet affected." That figure reflects PHP's share of websites. It doesn't measure how many sites are actually exploitable once patches and server differences are accounted for, and no reliable count of vulnerable sites exists yet. The number doesn't need to be large to include yours.

Questions to send your host, IT team or agency today

Copy these into an email. If you get clear answers within a day, you'll know who owns the response and what still needs doing.

1. Which version of PHP is running on our live site, staging site and any other properties, and how is it set up (mod_php, PHP-FPM or something else)?
2. Has PHP been updated to a fixed release or a vendor-patched package, and were the PHP workers restarted afterward?
3. If not, what's protecting us until it is? Cloudflare says it switched on PHP2Shell protections by default for its firewall customers, AWS has published firewall guidance, and PHP lists temporary server settings. Ask your provider to confirm the rules are active for your site; PHP is clear that none of these is a complete fix.
4. Are we reviewing server and PHP logs for unusual upload requests, memory errors, repeated server errors or unexplained restarts, and checking for unexpected processes or changed files? These are clues to investigate. They don't prove an attack, and a clean-looking log doesn't prove you're safe.
5. If anything looks suspicious, will we rotate the passwords and API keys stored on that server?
6. What other PHP sites do we own that nobody is watching? Old campaign microsites, event pages, a careers portal, an intranet.

That last question is usually where the real exposure lives.

The bigger issue: who owns your website after launch

In our experience, most companies can name who designed their website instantly. Far fewer can name who patched their server this week. Marketing owns the content and the results. IT owns the network. The agency that built the site handed it over and moved on. A server-level vulnerability lands in the space between those three, and that's where it sits unpatched.

We see this whenever a website is treated as a project with a launch date instead of infrastructure with an operating budget. Hosting, runtime updates and security monitoring rarely appear in a redesign brief, so nobody budgets for them, and the work only becomes visible when something like PHP2Shell forces it.

The way these bugs were found makes the gap more expensive. When AI-assisted research can surface a critical flaw in one of the most scrutinized languages on the web, and working exploits appear within days, the time between disclosure and attack keeps shrinking. Your website needs a named owner for its infrastructure, with the time and budget to act within hours.

If you sent the questions above and heard "we'll look into it," that's useful information. It tells you where the gap is.

If you're not sure who owns your site's infrastructure, we can help you map who's responsible for what and who needs to confirm the patch. Let's talk.