On October 21, the PHP project released fixes for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, which researchers are calling php2shell. Both let an unauthenticated visitor run code on your server. Both score 9.2.

The flaws are in PHP itself, not in October CMS. Every October site on an unpatched PHP is affected, the same as every other PHP application, and no October update can fix it. The fix is a PHP update, which for most sites means your host.

We rarely tell anyone to hurry. This is the exception. Working exploits were built against both Apache mod_php and PHP-FPM during the research that found the flaws, and Cloudflare reported attacks in the wild hours before the fixes were even released.

The good news: the fix is routine, and you probably have help nearby. Find out which PHP serves each of your sites, get it updated and restarted, and if you have to wait on someone, there are mitigations to bridge the gap. Here's each step.

Check Your PHP Version

Find out which PHP version serves your website and compare it with this table.

If your PHP comes from php.net or a repository that tracks the official releases, anything older than the fixed release on your branch is vulnerable. If it comes from a Linux distribution's packages, the fix is often backported without changing the version number, on any branch, so a patched server can still report an older number. The changelog check under PHP From Your Linux Distribution below settles it either way.

PHP 7.4, 8.0 and 8.1 have no fixed release of their own, but some distributions have patched them anyway. That's covered below too.

Your hosting control panel usually shows the version. If you check over SSH, keep in mind that php -v reports the command-line PHP, and that isn't always the one serving your website; shared hosts often run several versions side by side. To see the one actually serving the site, create a CMS page with an unguessable URL, open it in a browser, and delete the page once you've looked:

url = "/check-x7k2"
==
<?
function onStart()
{
    return PHP_VERSION;
}
?>
==

If you don't manage the server yourself, ask your host. Here's a message you can send as-is:

Please confirm that the PHP version serving our website includes the fixes for CVE-2026-109618 and CVE-2026-109619, released by the PHP project on October 21, 2026. The fixed versions are 8.2.35, 8.3.36, 8.4.27 and 8.5.12. If our PHP reports an older version number, please confirm whether the package includes the backported fix.

If you look after client sites, that's one message per host, not one per site.

Restart PHP after updating. Running PHP keeps the old code in memory, so an update hasn't taken effect until PHP restarts. With mod_php, restart Apache: the service is apache2 on Debian and Ubuntu, httpd on RHEL and Amazon Linux. With PHP-FPM, restart the FPM service: php8.3-fpm on Debian and Ubuntu (matching your version), plain php-fpm on RHEL and AlmaLinux.

Where Your October Version Fits

Version 4 runs on every fixed PHP branch, so a v4 site needs no October update. Update PHP, restart it, and this one is behind you. Sites that have moved to Laravel 13 need PHP 8.3 or later, so pick 8.3.36 or newer.

Version 3 installs Laravel 9 by default, which runs up to PHP 8.2, so 8.2.35 is your target. Keep in mind that PHP 8.2 reaches end of life on December 31, 2026, so it buys you weeks, not years. Since v3.4 you can opt into Laravel 10 by changing the laravel/framework constraint in your composer.json:

"laravel/framework": "^10.0"

Run composer update afterwards, and the site can move to PHP 8.3, which gets security fixes until the end of 2027. Plugins that pin Laravel 9 will need updating too, so run this on a copy of the site first. The v3.4 release notes have the details. Version 3 still receives security fixes from us, and you don't need to move to v4 to deal with this.

Versions 1 and 2 can't run on any PHP version with an official fix. Version 2 tops out at PHP 8.0 and version 1 at PHP 7.4, and the PHP project no longer publishes releases for those branches. For this incident it did publish source backports for 7.4, 8.0 and 8.1, which Linux distributions and long-term support vendors can build into their packages. A v1 or v2 site is only as safe as its host's PHP packages, which makes the message above the important one. Nobody plans to still be on v1 in 2026, but these sites exist, they're often quietly running someone's business, and they deserve a plan rather than a lecture. The lasting fix is moving them forward. The v3 upgrade guide and v4 upgrade guide cover the steps.

PHP From Your Linux Distribution

If your PHP comes from distribution packages, whether it gets the fix depends on where the packages come from, not on the version number. Here's what we could confirm on October 22; your vendor's security tracker has the current picture.

Ubuntu Pro. Once an Ubuntu release is past its five years of standard support, security fixes only arrive through Ubuntu Pro. Canonical has released this fix for 18.04 and 20.04 that way, and for 14.04 and 16.04 through the Legacy Support add-on, which is paid on top of Pro. Pro itself has a free tier for personal use on up to five machines; check Canonical's terms for business use. With a token from ubuntu.com/pro, Canonical's tooling does the rest:

sudo pro attach <your-token>
sudo pro fix CVE-2026-109618
sudo pro fix CVE-2026-109619

pro fix installs the fixed packages and tells you whether the server is still affected. Canonical's Pro documentation covers attach and repository problems.

The version number won't confirm the fix. A backported fix doesn't change PHP's version number, on any branch. A patched Ubuntu 24.04 still reports PHP 8.3.6, a patched 20.04 still reports 7.4.3; only the package revision changes, which php -v and hosting panels don't show. Version-based security scanners get fooled the same way. Check the package changelog instead, matching the package name to your branch:

# Debian and Ubuntu
zgrep -E 'CVE-2026-10961[89]' /usr/share/doc/php8.3-common/changelog.Debian.gz

# RHEL, AlmaLinux and Amazon Linux
rpm -q --changelog php-common | grep -E 'CVE-2026-10961[89]'

On Remi's SCL-style installs the package carries a prefix, such as php82-php-common; rpm -qa | grep php finds the name. A patched package normally lists both CVEs. If they're there, you have the fix. If they're not, treat it as unconfirmed and ask whoever supplies your packages, since not every vendor logs CVE ids the same way.

If no package source has a fix, you have two options. You can rebuild your distribution's PHP package with the backport applied, which works but leaves you maintaining your own PHP builds from then on. Or you can move the site to an operating system and PHP version that are still supported, which is the lasting fix anyway.

If PHP Can't Be Updated Yet

These measures reduce the risk while you wait for a fixed PHP. None of them replace the update, but if your update is days away rather than hours, they're worth the few minutes they take. Hosting setups vary, so test on a staging copy where you can, and lean on your host for anything you're unsure of; that's what they're there for.

Turn off session upload progress. PHP's advisory lists this as the stopgap for CVE-2026-109619: it removes the demonstrated trigger, though not every path. October itself doesn't use the feature. A plugin or custom uploader showing a progress bar might, so test uploads after the change. On PHP 8.5, the advisory also says to turn off fatal error backtraces:

session.upload_progress.enabled = 0
fatal_error_backtraces = 0

If you run PHP-FPM, set these in the pool configuration with php_admin_value so application code can't override them. With mod_php, set them in php.ini. Either way, restart PHP as described above so they reach every worker.

php_admin_value[session.upload_progress.enabled] = 0

On shared hosting without access to those files, a .user.ini in the web root works under FPM and FastCGI (give it a few minutes to take effect), and php_value lines in .htaccess work under mod_php; many hosting panels expose the same settings directly. fatal_error_backtraces is system-level, so that one needs the host.

Cap request sizes. CVE-2026-109618 is triggered by crafted multipart requests, the kind used for forms and file uploads, so a lower post_max_size limits what an attacker can send. The sharp edge: October's media manager and file upload fields use the same requests, so whatever you set becomes your largest upload. Pick a cap just above the largest file your site genuinely accepts; many sites land around 32M.

post_max_size = 32M
upload_max_filesize = 24M

PHP's advisory lists one more mitigation for CVE-2026-109618: memory_limit = -1, set administratively, which stops PHP's out-of-memory handling from running at all. It also removes PHP's per-request memory cap, so it only belongs on servers where the container or operating system enforces its own memory limit. We mention it for completeness; the request-size cap is the safer of the two, and this one is a call for whoever runs the server.

If your site sits behind Cloudflare, Cloudflare says its WAF rules cover these vulnerabilities on every plan, including the free one. It also says to patch anyway, and that it has already seen attackers mutating payloads to get past the rules. Treat it as extra time, not protection.

If You Patched Late

We'd like to end with "update and you're covered", and for most sites that's true. But attacks started before most sites could patch, and updating PHP stops new ones without undoing one that already landed. If your site sat reachable on an unpatched PHP after October 21, spend a few minutes reviewing admin accounts, scheduled tasks and recently changed files, and treat unusual multipart POST requests in the access logs as worth a closer look. Odds are you'll find nothing, and then you'll know.

If You Need a Hand

The statuses above are what we could confirm on October 22. Your distribution's security tracker and your host stay current, so when they disagree with this page, trust them; they're closer to your server than we are.

And if the thing standing between an old October site and a patched PHP is the upgrade itself, you're not on your own. Get in touch and we'll point you in the right direction, or find an October CMS Partner who does this work every week. Old sites deserve to be carried forward, and that part we can help with.