PHP2Shell: what this week’s critical PHP flaws mean for your ExpressionEngine site (and how we can help!)

The short version

• Two critical security flaws in PHP itself were fixed on 21 October 2026. Together they're known as "PHP2Shell".
• They can let an attacker take control of a web server without logging in, and attacks are already being reported.
• PHP 8.2 or newer: official patched releases are out. Make sure your server is running one today.
• PHP 8.1 or older: fixes exist, but not as normal updates. They come as backported patches from the PHP project, Linux distributions and specialist vendors, and they need applying deliberately. Your host may or may not have done this.
• We can work with your hosting company or server to make sure the right protection is in place, and help you plan a longer-term move to a supported PHP version.

What happened

On 21 October the PHP project released emergency security updates for two vulnerabilities, CVE-2026-109618 and CVE-2026-109619. Both are rated 9.2 out of 10 for severity. In plain terms, a specially crafted request to a website running PHP could let an attacker run their own code on the server. That gives them a route to your data, your visitors and the rest of your hosting.

The release was rushed forward after details of the flaws leaked online on 20 October, a day before the planned fix. Security firms have since reported attempts to exploit the flaws in the wild. The US Cybersecurity and Infrastructure Security Agency (CISA) has told organisations to patch immediately.

This isn't a bug in a plugin or a particular CMS. It's in PHP, the language that powers ExpressionEngine, WordPress, Craft, Laravel and a large share of the web. If your website is built on PHP, it's in scope.

Am I affected?

Almost certainly, unless your server has already been patched. How you get protected depends on which version of PHP you're running.

That last row is the one to watch. On a supported PHP version, the fix usually arrives through normal updates. On an older one, someone has to go looking for the right patched package for your particular server and install it. Because the version number doesn't change, you can't tell from it alone whether the fix has been applied.

How to check: in the ExpressionEngine control panel, the PHP version is shown under Utilities → PHP Info. Your hosting control panel will usually show it too. If you're on 8.1 or older, ask your host specifically whether the PHP2Shell backport has been applied, not just which version you're on.

Why ExpressionEngine sites often run older PHP

Each version of ExpressionEngine only runs on a certain range of PHP versions. Many long-running EE sites have stayed on older PHP for exactly that reason: the site works, nobody wants to break it, and the PHP version has quietly fallen out of support.

Based on ExpressionEngine's official compatibility chart, this is roughly where each version can go:

If your site is on ExpressionEngine 5 or older, or an early EE 6 or 7 release, it can't run on a PHP version that gets regular official security updates. Backported patches can protect you this week. But you're relying on someone else continuing to patch an unsupported version every time a new flaw appears, and on your host remembering to apply it.

So there are really two jobs: get protected now, and get onto a supported footing so the next one of these is a routine update rather than a scramble.

How Orionesque can help

We work with ExpressionEngine sites every day, and we're used to working alongside hosting companies and server teams. Depending on where your site is, we can help in a few ways:

1. Emergency check and hosting liaison (today)

We'll confirm which PHP and ExpressionEngine versions you're running and whether you're exposed. Then we'll work directly with your hosting company, or on your own server if you manage it, to make sure the right fix is in place:

• confirming the patched release or backport has actually been applied, not just scheduled
• sourcing and installing a suitable backported PHP build where your host can't or won't
• putting interim protections in place while that happens, such as firewall rules and disabling the PHP setting used in one of the known attack paths
• checking that your site still works properly afterwards

You won't have to work out what to ask your host or interpret their answers. We'll handle that conversation for you.

2. PHP update and test

If your ExpressionEngine version supports PHP 8.2 or newer, we'll get PHP updated to a supported, patched version and run through the site to make sure everything works as it should.

3. ExpressionEngine upgrade

For sites on EE 2 through to early EE 7, we'll plan and carry out the upgrade to the current release of ExpressionEngine 7, running on a supported PHP version. That includes:

• auditing your add-ons, updating the ones that can be updated and replacing or rebuilding the ones that can't
• fixing templates and custom code for modern PHP
• doing the whole upgrade on a staging copy first, so your live site keeps running (and stays protected) until everything is tested and signed off

4. Ongoing care

Security releases like this one will keep coming. Our care plans keep PHP, ExpressionEngine and your add-ons up to date, and keep us in touch with your host, so the next time a story like this breaks it's already been handled.

What to do next

If you're not sure where your site stands, book a free 15-minute PHP & ExpressionEngine health check. We'll tell you exactly which versions you're on, whether you're protected, and what it will take to fix it, with no obligation.

If you already know you're on an older ExpressionEngine version, get in touch and we'll get you protected now and talk through an upgrade plan.

For developers: the technical detail

• CVE-2026-109618: memory corruption during out-of-memory handling.
• CVE-2026-109619: a use-after-free involving state retained between requests.
• Fixed upstream in: 8.5.12, 8.4.27, 8.3.36 and 8.2.35. For 7.4, 8.0 and 8.1, the PHP project has published source-only mitigation commits. There's no tarball and no version bump.
• Backports for end-of-life versions: check your distribution's package changelog for the CVE, for example zgrep CVE-2026-109618 /usr/share/doc/php8.1-fpm/changelog.Debian.gz on Debian or Ubuntu, or dnf updateinfo on RHEL-family systems. TuxCare's ELS for Runtimes covers PHP 5.x through 8.1.
• Interim mitigation: setting session.upload_progress.enabled = 0 blocks one known attack path for CVE-2026-109619. It doesn't address CVE-2026-109618.
• What to monitor for: PHP worker processes spawning shells or downloading tools.
• Further reading: the official advisory on php.net, the CISA alert, the write-up from Rapid7, and TuxCare's patch guide.