SnowDriven Research · News
Update PHP now. On 21 October 2026 the PHP project fixed two critical vulnerabilities that can let an attacker run code on a web server without logging in. The fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. On PHP 8.1 or older there is no fixed release from the project: upgrade, or get a patched package from your vendor.
Before you change anything. This page is general information, not advice for your system. The facts come from the PHP project’s advisory and the reports we link, last checked on 21 October 2026, and they can change, so confirm on the PHP advisory before you act. Back up, test every change on a copy that isn’t in production where you can, keep a way back, and follow your own change process. You follow these steps at your own risk (terms). SnowDriven isn’t affiliated with The PHP Group (trademarks).
From the PHP project’s advisory of 21 October 2026, and from other reports where they are named.
If PHP runs out of memory at the wrong moment, it can stop while a request’s data is only partly set up, and the cleanup that follows treats that half-built data as valid.
Some state that belongs to one request can outlive the memory behind it, and a later request handled by the same PHP worker may use it.
The advisory covers every PHP installation that serves web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed.
The advisory rates Apache with mod_php highest. It describes a demonstrated exploit in which a request from someone who isn’t logged in triggers the attack before any application code runs.
If a site or app runs on PHP and serves web requests, treat it as affected until its PHP is updated. That includes WordPress and WooCommerce sites and custom PHP apps.
The flaws are in PHP, not in your code. Updating WordPress, a theme, a plugin or a framework doesn’t fix them; an updated PHP does.
Affected, with no fixed release from the PHP project. Some distributions and long-term support vendors backport fixes; ask yours.
It takes a minute. Check the PHP that serves the site, not only the one on the command line.
Either command prints the version:
php -vphp -r 'echo PHP_VERSION;'The command-line PHP can be a different version from the one behind PHP-FPM or mod_php. To see what the site really uses, put a file containing <?php phpinfo(); at a private, hard-to-guess path, open it once, then delete it: it shows server details that shouldn’t stay public.
Open Tools → Site Health → Info, then the Server section: it lists the PHP version.
Your hosting control panel may show the PHP version for each site, often where you can change it.
A backported fix may keep the same PHP version number. Compare the installed package version with your vendor’s security notice rather than the version alone.
By how your PHP is run. In every case, back up first.
Your host controls PHP. Check its status page or notices for CVE-2026-109618 and CVE-2026-109619, or ask support whether PHP on your plan has the fix, and when.
If your plan lets you choose a PHP version and you’re on 8.1 or older, ask whether that version gets a backported fix. If it doesn’t, plan the move to a supported version, tested on a staging copy first. Keep WordPress, themes and plugins updated as usual, but they don’t fix this.
Install the PHP security updates from your Linux distribution or long-term support vendor; the advisory says they received the patches in advance. Then restart every PHP process (PHP-FPM pools, Apache if it runs mod_php, FrankenPHP or LiteSpeed) and confirm the package version against your vendor’s notice.
If you rely on the volunteer-run rpms.remirepo.net repository: the advisory says it wouldn’t have updates on the day, and points to distribution packages or a source build instead.
Build PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 (whichever matches your branch) from php.net’s source downloads (Windows builds are on php.net too), deploy, and restart every worker.
For 7.4, 8.0 and 8.1 the project published minimal source backports as GitHub branches, for people who build from source or have no long-term support vendor: PHP 7.4, PHP 8.0 and PHP 8.1. They aren’t releases, so test them as you would your own patch.
There is no fixed release from the PHP project. Ask your distribution or long-term support vendor for a backported fix, naming both CVEs. If you build PHP yourself, the source backports cover 7.4, 8.0 and 8.1. For 7.3 and older nothing is published: upgrade, or find a vendor that covers your version.
The lasting fix is a supported version. PHP 8.2’s security support ends on 31 December 2026, so aim for 8.4 or 8.3; our PHP 8.2 guide covers the move for WordPress sites and custom apps. Use the interim measures below while you work on it.
The advisory lists measures that reduce exposure while you arrange the update. They don’t make an installation safe; only updating is a complete fix. In short:
memory_limit=-1 where applications can’t override it, with php_admin_value in the PHP-FPM pool or the Apache config.post_max_size low: 8M with no uploads, 32M with them, and upload_max_filesize below it. Add request-size limits at the web server or proxy.RLIMIT_AS or RLIMIT_DATA.session.upload_progress.enabled=0 in php.ini, the FPM pool or the server config, then restart every worker. Setting it with ini_set() or .user.ini doesn’t count.fatal_error_backtraces=0, then restart every worker.Each measure has conditions. Read the full list in the PHP advisory before you change a setting.
From our WordPress PHP tracker’s snapshot of 21 October 2026: WordPress.org’s figures, summed by what the PHP project published for each version.
Source: our WordPress PHP tracker, from WordPress.org’s PHP version statistics as stored on 21 October 2026 (the data as JSON).
The figures count PHP versions, not patch levels. A site on PHP 8.3 is fixed only once it runs 8.3.36 or a patched package, and the figures can’t show which sites have updated.
Hosts and Linux distributions may backport fixes to older versions. WordPress.org’s figures can’t show which sites have them.
Only WordPress sites that report their PHP version to WordPress.org are counted, not all websites. SnowDriven isn’t affiliated with or endorsed by WordPress.org.
What has changed since the advisory, newest first. We add to this list as things develop.
The PHP project released PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 and published its advisory. Reported by watchTowr: exploitation seen in the wild as of 21 October. Reported by Huntress: no exploitation seen on its partners’ systems as of 4:30 pm ET that day. We published this page.
The PHP project gave advance notice of a critical security release, scheduled for 21 October 2026 at 14:00 UTC. Reported by Huntress and Infosecurity Magazine: word of the vulnerabilities leaked on Hacker News the same day.
Each checked on the day shown. Third-party reports are theirs; we quote only what the page says.
SnowDriven. “PHP2Shell (CVE-2026-109618, CVE-2026-109619): what to do now.” SnowDriven Research. https://snowdriven.com/research/php2shell/ (last updated 21 October 2026).
One click or tap selects the whole citation, ready to copy.
The facts are the vendor’s, from its own advisory, and each report is its publisher’s, attributed by name; all were checked on the day shown, and the WordPress shares are WordPress.org’s. Any of them can change without notice, and our summary can fall behind or contain mistakes, so confirm with the source before you act. Information only, provided as is (terms). Reuse: free to quote, with credit to SnowDriven and a link (terms of use).
Start a project
We can update PHP on your server or work with your host on it, apply the interim measures while a fix is arranged, and plan the move off PHP 8.1 or older. Tell us what you run; we reply within one business day.
Pittsburgh, PA · Since 2015 · First step: a 30-minute call
