Two critical PHP vulnerabilities fixed: check your server updates

On 21 October 2026, the PHP developers released fixes for two critical vulnerabilities: CVE-2026-109618 and CVE-2026-109619. Both can allow an attacker to execute code on a server without authentication. These vulnerabilities are collectively known as PHP2Shell.

The fixes are available in PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. The PHP team recommends updating immediately. Older branches, including PHP 5.6, are also affected and need attention.

Why these vulnerabilities are dangerous

The flaws are in PHP itself, which executes your website’s code. Updating WordPress, another CMS or its plugins is therefore not enough. Both vulnerabilities have a CVSS v4.0 score of 9.2 and involve memory management errors.

• CVE-2026-109618: out-of-memory handling can interrupt a request before PHP finishes initialising internal data. Subsequent cleanup may then access memory incorrectly.
• CVE-2026-109619: internal state can survive after its backing memory has been freed. A later request handled by the same worker may use that invalid state.

Check updates for PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The developers consider mod_php the highest-risk configuration: a demonstrated exploit uses a single unauthenticated request before any application code runs.

Wiz researchers also demonstrated reading PHP process memory without achieving remote code execution. That memory may contain passwords, tokens and API keys. The risk therefore extends beyond changes to website files.

Nginx with PHP-FPM also needs updating. Calif researchers published a demonstration against this configuration. Their tested applications include WordPress, Drupal, Joomla, MediaWiki, Roundcube, Magento, phpMyAdmin, Nextcloud, Laravel, Symfony and WHMCS. These are research demonstrations, not a list of compromised services.

Which PHP version should you install?

If you use Linux distribution packages, your supplier may backport the fix without changing the main PHP version number. Check the full package version and the supplier’s security advisory; a label such as “PHP 8.3” is not enough. CERT-EU recommendations.

What if your website uses PHP 5.6, 7.x, 8.0 or 8.1?

Older branches are affected too. They no longer receive official support from the PHP project, but distributions, third-party repositories and extended support providers may supply fixes.

• PHP from the Sury repository, including PHP 5.6. Ondřej Surý said fixes for both CVEs should cover every PHP version in his repository for all Debian and Ubuntu releases it supports. The amd64 packages will be available first, followed by ARM as builds complete; no timeline was given. Check the fixed package for your PHP branch, OS and architecture. This statement applies to Sury packages, not every PHP 5.6 installation. Sury PHP maintainer’s comment.
• Packages from your distribution or extended support provider. Read its security advisory and install the recommended build.
• PHP built from source. The PHP team has published minimal source fixes for PHP 7.4, 8.0 and 8.1. For other older branches, check separately whether a suitable patch is available.
• PHP managed through a hosting control panel. Ask your provider whether the version used by your website has been patched and whether you need to take any action.

A patch addresses these two vulnerabilities; it does not restore full support for an obsolete branch. Install the available fix, then plan a separate migration to a supported PHP version.

PHP updates in Ubuntu, Debian and AlmaLinux

Status checked on 21 October 2026. The following fixed package versions are confirmed for the official Ubuntu and Debian repositories:

The numbers in the table apply to official packages from each distribution. For Sury and other third-party repositories, check their own package versions. A fix may be backported without changing the main PHP version number. Ubuntu USN-8948-1.

Canonical has released fixes for both CVEs for the Ubuntu versions listed. Debian published advisory DSA-6574-1 for Trixie, and its security tracker now marks the Bookworm version as fixed. Check package availability on your mirror and for your architecture. Debian Security Tracker.

AlmaLinux: its official announcement says packages are being prepared for supported streams in AlmaLinux 8, 9 and 10: testing first, then production after validation. Release to stable repositories is not yet confirmed. This concerns AlmaLinux’s own packages, not third-party PHP repositories. AlmaLinux announcement.

The first round covers PHP 7.4 and 8.2 on AlmaLinux 8; PHP 8.0, 8.2 and 8.3 on AlmaLinux 9; and PHP 8.3 and 8.4 on AlmaLinux 10. Retired PHP 7.2, 7.3 and 8.0 streams on AlmaLinux 8 and PHP 8.1 on AlmaLinux 9 are excluded from this first round.

PHP updates in hosting control panels and CloudLinux

Status checked on 21 October 2026. Updates are still rolling out: package availability depends on the PHP branch, operating system and repository.

cPanel. A cPanel representative announced fixes for ea-php74, ea-php80, ea-php81, ea-php82, ea-php83, ea-php84 and ea-php85, including the obsolete 7.4, 8.0 and 8.1 branches. Check updates for every ea-php version in use, not just the panel version. cPanel announcement.

Plesk. A staff member on the official forum said patched builds for PHP 7.4, 8.0 and 8.1 were complete and undergoing testing. That does not confirm availability of every package. Check your branch and platform separately; an available Linux build does not confirm an available Windows build. Plesk staff response.

FASTPANEL. At the time of checking, we could not find a dedicated official PHP2Shell advisory or list of fixed builds. A PHP version appearing in the panel does not establish that it is patched. Check the installed package and repository, or ask support for confirmation.

DirectAdmin. Website PHP is usually compiled through CustomBuild, so updating OS packages may not be enough. Check available versions in CustomBuild → Updates or with da build versions; custom_versions.txt can pin an older version. At the time of checking, we could not find a complete developer-confirmed list of fixes, especially for older branches. Forum instructions that manually replace version numbers are not equivalent to an official release.

ispmanager. System PHP comes from the OS repository, while alternative versions are installed from the ispmanager repository under /opt/. Check both sources: updating system PHP does not confirm that alternative website handlers are fixed. At the time of checking, we could not find a dedicated official advisory for these CVEs or a list of fixed builds. This is a lack of confirmation, not evidence that patches are unavailable.

CloudLinux. Patches are planned for alt-php 5.2–8.5; some builds, including alt-php74, are already released. Check your OS and branch. Imunify360 ruleset 8.83 is in Stable for enabled WAFs, but does not replace PHP updates. CloudLinux release status.

One server may run the panel’s own PHP, system PHP, ea-php and alt-php simultaneously. Updating one package family does not confirm that the others are fixed. After installing updates, restart the relevant processes and check which handler each website uses.

Why so many websites are affected

PHP runs on the server: it processes forms, checks authentication, retrieves database records and generates pages. Website owners may work entirely through a control panel without knowing which PHP version their hosting uses.

WordPress, Drupal, Joomla and MediaWiki run on PHP. Developers also use it for custom applications, including those built with Laravel. Websites without an off-the-shelf CMS need checking too. For a comparison of content management systems, see our CMS guide.

Wikipedia uses MediaWiki, while NASA, NASA Science and WhiteHouse.gov use WordPress. On 21 October, the Wikimedia Foundation said it had temporarily taken several supporting services, including Toolforge and Cloud VPS, offline until they could be safely patched. The team was working to avoid downtime for the wikis themselves. This was a precaution, not an announcement of a breach.

Your CMS and PHP are updated separately. An up-to-date WordPress installation with current plugins can still run on an unpatched PHP version. An attack that triggers before the application starts also precedes the CMS’s own checks.

How to check that your website has the fix

On managed hosting, start by asking support: “Does the PHP version used by my website have the fixes for CVE-2026-109618 and CVE-2026-109619?” If you or your administrator manage the server:

1. Check every PHP version serving web requests. Different websites on the same server may use different branches.
2. Install the fixed packages and restart the relevant PHP processes.
3. Confirm that the website uses the updated build. Command-line PHP may be different from the version serving your website.
4. Test pages, sign-in, forms and file uploads.

Can configuration changes provide temporary protection?

Only an update fully fixes the problem. The temporary settings described by the developers reduce exposure to specific attack paths but do not fix both vulnerabilities. If you cannot patch promptly, CERT-EU recommends considering temporary restrictions on public access to affected applications. Administrators can find the technical measures in the CERT-EU advisory linked above.