The Latest PHP Vulnerability Explained

What Is PHP?

PHP is the language that builds a page on the server before it reaches the visitor's browser. When someone loads a WordPress blog post, PHP pulls the text from the database, drops it into the theme and sends back finished HTML.

It’s a widely used server-side programming language. As a matter of fact, about 69.3% of websites with a known server-side language use PHP, and that includes every WordPress, Drupal and Joomla site, along with a long tail of custom portals and form scripts.

PHP Vulnerability: What Happened in October, 2026

The PHP vulnerability, called php2shell, is two memory-handling flaws in the PHP engine, tracked as CVE-2026-109618 and CVE-2026-109619. The PHP security release describes them like this:

• CVE-2026-109618 - if PHP runs out of memory while it's halfway through setting up a request, the cleanup step can treat that half-built data as valid.
• CVE-2026-109619 - leftover data from one request can survive after its memory is freed, and the next request handled by the same worker can pick it up.

php2shell vs. wp2shell

php2shell and wp2shell are two separate issues that happen to have similar names. php2shell is in the PHP engine and was fixed on October 21, 2026, while wp2shell was a chain of flaws in WordPress core itself, disclosed on July 17, 2026.

‍

Therefore, a WordPress site needs both fixes. Updating WordPress to 7.0.2 handles wp2shell and does nothing for php2shell, and updating PHP does nothing for an unpatched WordPress install.

How Serious Is the PHP Security Issue?

The PHP security issue is serious enough that national cyber agencies told site owners to switch sites off. However, it’s manageable enough that a patched server is no longer exposed to these two bugs.

‍

Why It Is Serious

It’s serious because nobody needs an account. A working exploit needs only one unauthenticated request, and the flaw sits in the layer under every PHP application rather than in one plugin you could switch off.

For example, Amazon's honeypots recorded an exploitation attempt on October 17, four days before disclosure, and more attempts arrived on October 21 from what looked like several different actors.

Why It Is Manageable

It’s manageable because a fix is already out. PHP shipped patched versions on October 21, 2026 and Linux vendors got the fix early, so a good host could update the same day. Once your server runs the fixed version, these two bugs can’t be used against it.

However, not every PHP site is equally easy to attack. The riskiest setup is one where PHP runs directly inside the Apache web server (called mod_php).

The weak spot is old PHP. Versions 8.1 and older don’t get an official update, so sites still running them depend on their host or Linux vendor to patch them, or need an upgrade.

PHP Security Update: Which Versions Are Fixed

The PHP security update fixes both October 2026 flaws in four releases, including 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Anything below those numbers on the same branch is vulnerable unless your Linux vendor has backported the fix.

‍

Two details are worth flagging to your developer:

1. PHP 8.2 reaches end of life on December 31, 2026, according to php.net, so patching 8.2 today buys you about ten weeks of official support before you face an upgrade anyway.
2. PHP lists temporary settings changes for anyone who can't update yet, such as disabling session upload progress, but their own advisory says none of them is a complete fix and that updating is the only safe choice.

What to Check on Your Site

Here's what to check on your site today:

1. List every place your company runs PHP, including the main site, blog, landing page tools, customer portals, staging copies and old microsites.
2. Find who controls each server, whether that's a managed host, an agency or someone on your own team.
3. Ask each owner to confirm the fixed PHP package is installed, and when it went in.
4. Flag anything on PHP 8.1 or older, and ask for either a vendor backport or a dated upgrade plan.
5. Isolate anything that can't be patched yet, which is what the UK NCSC and the Canadian Cyber Centre both advise.
6. Review logs after patching, since attempts started before the fix was public (more on this below).

However, keep in mind that staging sites and campaign microsites from three years ago don't show up in anyone's hosting dashboard, yet they still answer requests from the internet.

What to Ask Your Host

Copy this into an email or support ticket and send it to every company that hosts a PHP site for you:

Pro tip: A good host answers it with a date and a package version, and a vague "we keep everything up to date" is a reason to follow up.

Does Webflow Use PHP?

No, Webflow’s core platform isn’t built on PHP, and a Webflow site has no way to run PHP code. The core services are unaffected by php2shell, so a site built and hosted entirely on Webflow has nothing to patch.

A WordPress site is different. WordPress sends every page request through PHP on the server, so whoever runs that server has to keep PHP updated. On Webflow, hosting and the platform underneath it are Webflow’s job. There’s no PHP version for you or your developer to look after.

The only PHP risk for a Webflow site is in the services connected to it:

• A WordPress blog on a subdomain
• A PHP script that receives Webflow form submissions
• A customer portal or help centre hosted somewhere else

Each one runs on its own server, with its own PHP version and its own owner, so each one needs its own check.

When It’s Time to Move Your Site to Webflow

Patching php2shell fixes today’s problem. It doesn’t fix the reason it was a problem, which is a server that someone has to keep updating. With that said, these signs usually mean it’s time:

• Nobody owns the server. Your host, your agency and your developer each assume one of the others handles PHP updates.
• Updates feel risky. Plugin and PHP updates keep getting put off because the last one broke a form or the layout.
• The site only needs marketing pages. Pages, a blog, forms, landing pages and a CMS cover everything it does, with no custom server logic behind it.
• Your marketing team waits on developers. Changing a headline or launching a page takes a ticket and a week.
• You found forgotten sites during this check. Old subdomains, staging copies and microsites nobody remembers building.

If any of the above points apply to you, then a WordPress to Webflow migration might be worth considering. At Tunel Studio, we rebuild the site in Webflow, bring the content across into the CMS, and map every old URL to the new one so search traffic carries over.

On Virtuo’s move to a new domain, the redirect map kept the organic visibility through the switch, and organic clicks tripled after launch. The full project, 10 pages in two languages, took six weeks. For Finmatics, the rebuild brought 40% more organic clicks and doubled demo submissions.

However, migration doesn’t fit every site. E-commerce stores that depend on WordPress plugins, apps with real server logic, and sites with heavy custom PHP are better kept where they are and patched. We’ll tell you if yours is one of them.

Conclusion

• PHP fixed two critical flaws, CVE-2026-109618 and CVE-2026-109619, on October 21, 2026, in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35.
• An attacker needs no login; Amazon recorded an exploitation attempt four days before the fix was public.
• Updating WordPress, themes or plugins does nothing for this one, because the PHP running on the server has to change.
• PHP 8.1 and older get no official release, so your host or Linux vendor has to backport the fix, or you upgrade.
• Webflow doesn't run on PHP, but a WordPress blog, form handler or portal attached to a Webflow site can still be exposed.
• Migrating your website to Webflow takes server updates off your plate, so the next PHP flaw becomes Webflow’s job instead of yours.