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.

What website owners should do now

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. Temporary settings reduce exposure to specific attack paths but do not fix both vulnerabilities. If prompt patching is impossible, CERT-EU recommends considering temporary restrictions on public access to affected applications. Technical measures are described in CERT-EU advisory 2026-018.

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.

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.

Have exploitation attempts been reported?

AWS reported a PHP2Shell exploitation attempt in its MadPot honeypot system dating to 17 October, before public disclosure. This is an observed attempt against a honeypot, not confirmation that every affected system was successfully compromised. After patching, review logs, unexpected file changes and process execution; AWS recommends looking back at least to 17 October. AWS research.

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.

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 on Linux, FreeBSD and Windows

Updated on 22 October 2026. Fix availability depends on the repository, PHP stream and architecture. The following versions are confirmed for official Ubuntu and Debian packages:

Ubuntu and Debian: fixed packages

The table lists official packages from the named distributions. For Sury and other third-party repositories, check their own package versions. 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: fixes in production

AlmaLinux 8, 9 and 10: fixes for every shipped PHP stream are now in production. This includes previously excluded PHP 7.2, 7.3 and 8.0 streams on AlmaLinux 8 and PHP 8.1 on AlmaLinux 9. This exceptional fix does not promise ongoing support for retired streams. Fixed AlmaLinux package versions.

Compare the full package version with AlmaLinux’s table, for example using rpm -q php-common. Fixes are backported, so php -v alone is not enough. If you enabled almalinux-testing earlier, it is no longer required for these fixes.

Arch, RHEL, SUSE, FreeBSD and Windows

Checked against the official Arch Linux announcement of 21 October, FreeBSD Ports and VuXML, the Red Hat advisory, SUSE’s database and downloads.php.net/~windows/releases. Details: FreeBSD Ports, RHSA-2026:87080, SUSE statuses.

PHP updates in hosting control panels and CloudLinux

Status checked on 22 October 2026. Distinguish website PHP, the panel’s own PHP and CloudLinux packages: their updates are separate.

cPanel

The official advisory confirms EasyApache4 fixes: ea-php74 7.4.33-19, ea-php80 8.0.30-12, ea-php81 8.1.34-5 and the patched PHP 8.2–8.5 releases listed above. Fixed panel releases are cPanel & WHM 110.0.153, 134.0.66, 136.0.50 and 138.0.18. This is separate from website PHP updates. cPanel advisory.

DirectAdmin

Developer fln confirmed releases in current and stable: PHP 8.2–8.5 updated, with patches added for PHP 7.4, 8.0 and 8.1. The official forum gives da update and da build php. Updating the panel alone does not rebuild PHP unless CustomBuild automation is enabled. Also check version pins in custom_versions.txt.

Plesk

NCSC-NL’s published assessment confirms fixed Linux builds of PHP 8.2–8.5. Older branches, Windows builds and the internal sw-engine require separate checks: patched website PHP does not establish that the panel itself is fixed. We have not confirmed availability for every one of these components.

CloudLinux

Its 22 October status confirms fixed alt-php in stable for CloudLinux 7/8/9; CloudLinux 10 fixes are available through its designated repositories. Fixed ea-php52–85 are released too. Some native OS PHP packages are still rolling out; distinguish them from alt-php and ea-php. Current CloudLinux status.

Imunify360 delivers WAF rulesets 8.83–8.85 automatically, but they do not replace PHP patches. CloudLinux also warns that security-only updates may not list the fixed packages until security metadata is published; check regular updates and package changelogs.

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.

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.