On the evening of Tuesday 20 October, the PHP security team announced in advance that an urgent security release addressing two critical vulnerabilities would be issued the following day. Details of the vulnerabilities had been leaked prior to the official announcement, so the release was brought forward by one day. At 16:00 (CEST) on 21 October, the php.net team itself released the patched versions.

The attackers reacted swiftly to the leak: several security firms (including watchTowr, Hadrian and Patchstack) detected active exploitation, whilst Cloudflare reported the first attacks even before the patch was released. According to a report by Amazon Threat Intelligence, the first attempts began as early as 17 October.

Why is it critical?

The two errors lie in PHP’s memory management:

• CVE-2026-109618: if memory runs out whilst processing a request, PHP runs a clean-up operation with partially prepared data, which leads to a memory corruption.
• CVE-2026-109619: a later request running on the same PHP process could exploit a pointer left over from a previous request that points to memory that has already been freed.

Both have a CVSS score of 9.2 (critical). Using a specially crafted web request, an attacker can execute code on the server with the privileges of the PHP process. Researchers have also demonstrated that the contents of the PHP process’s memory can be leaked, which may include passwords, tokens or API keys.

As PHP processes the request before the application code, even the CMS login protection offers no defence. The greatest risk comes from Apache’s mod_php, but PHP-FPM, LiteSpeed and FrankenPHP are also affected under certain configurations.

Affected versions and fixes

The bugs affect PHP version 5.4 and later.

Important: the table below shows only which branches the PHP.net team (the PHP project itself) has released official patches for. This does not mean that other versions are actually left unprotected: maintenance teams for operating systems and software vendors (such as CloudLinux, cPanel, TuxCare, Debian, Ubuntu or AlmaLinux) may backport the patch to other, older PHP versions, and in practice they often do so. The situation on a given server is determined by the status of the package used there, not by the PHP version number.

PHP branch	Updated version from PHP.net	Comment
8.5	8.5.12
8.4	8.4.27
8.3	8.3.36
8.2	8.2.35	Support for PHP.net will end on 31 December 2026
8.1 and earlier	PHP.net does not release official versions	The PHP team has released a source-code-level patch for the 7.4, 8.0 and 8.1 branches; distributions and vendors may also release their own backported patches for these (and even older branches)

The table therefore shows the official support provided by PHP.net, not which version is secure on a particular server. With us, for example, the CloudLinux and cPanel (EasyApache) plans include patches for older PHP branches as well, so older versions are also protected on these servers.

Why does the version number remain the same?

Some vendors (such as CloudLinux) backport the fix to their older version numbers. In such cases, the PHP version number does not change (for example, it remains 8.5.11), only the package build number; however, the build number is not visible in the version. The package’s changelog confirms that the fix is included.

For this reason, checks that only look at the PHP version number may give a false reading. If a WordPress plugin (such as HelloPack) indicates that the site is using PHP 8.5.11 and needs updating, this does not automatically mean that the patch is missing. If you see such an alert, please contact us and we will verify the status.

The ‘Build Date’ in the phpinfo() output is also helpful: if the date is after 21 October 2026, the package has probably been recompiled following the patch. The surest way to check is to consult the package’s changelog.

What have we done?

• Even before the patch was released, we had already implemented ModSecurity rules on our servers to provide some protection in the meantime. This is supplementary protection; it is not a substitute for the PHP update.
• On our servers: We installed the patches within 5–15 minutes of their release. Patches were being released continuously for the various PHP versions, and due to the high load on the package repositories, downloading them also took longer than usual.
• Restart: the fix only takes effect after the affected services have been restarted, so we restarted Apache and PHP several times (not the entire server). This caused a total interruption of just a few minutes.
• If your site is hosted behind Cloudflare, Cloudflare has also introduced its own security rules: these came into effect by default via the WAF rules from 05:02 on 21 October 2026 (CEST). This applies even to free Cloudflare subscriptions.

What can you do?

1. You do not need to do anything to apply the PHP patch. The patch must be installed by the server operator or maintenance team; it cannot be applied from within the web application itself.
2. Check your website. Suspicious signs may include unknown or recently modified .php files, unknown users or administrators in the CMS, unknown scheduled tasks (cron jobs) in your hosting account, as well as unexpected redirects, spam or unauthorised content. If you find any of these, please report them to us and do not delete anything before we have discussed it.
3. Consider changing your passwords. Unless there are any signs of a breach, this isn’t mandatory, but as a precaution – particularly if the site handles logins or payments – it’s worth changing your control panel, FTP, database and CMS administrator passwords. The vulnerability could also leak the contents of the PHP process’s memory. We cover how to change your cPanel password in a separate article.
4. Keep your CMS and plugins up to date. This is no substitute for updating PHP, but it does reduce the attack surface.
5. Be wary of phishing emails. Following this news, there may be an increase in fake emails claiming to be ‘urgent security updates’. We will never ask for your password via email.

If you want to check your own website, you can use, for example, Searchlight Cyber’s open-source php2shell-scanner tool or Aikido’s free URL checker. Please ensure you only use these to test your own server and your own website!

Timeline

All times are given in Central European Summer Time (CEST), in the YYYY-MM-DD HH:MM format.

Date	Event
2026-10-17	According to the Amazon Threat Intelligence report, the first exploitation attempts began at this time, prior to the public disclosure.
2026-10-20 21:33	The PHP security team has issued an advance notice of an urgent release addressing two critical vulnerabilities. Details have leaked ahead of the official announcement, and CERT-EU has also issued a warning.
2026-10-21 05:02	Cloudflare enables its security rules by default on WAF packages.
2026-10-21 09:43	Cloudflare reports the first attacks.
2026-10-21 11:08	The first rule set for the Imunify360 WAF blocks publicly circulating attack patterns.
2026-10-21 13:35	Hadrian enables large-scale utilisation, primarily through the session upload process.
2026-10-21 16:00	The php.net team has released the following updated versions: 8.5.12, 8.4.27, 8.3.36 and 8.2.35.
2026-10-21 16:19	watchTowr confirms that it has detected active exploitation attempts targeting both vulnerabilities. CISA and the UK’s NCSC have also issued warnings.
21 October 2026 – ongoing	cPanel has also issued a statement regarding the updated cPanel and EasyApache 4 plans.
2026-10-21 19:50	AlmaLinux is releasing the patched PHP packages for testing (they will be added to the production repositories from 21 October 2026 at 23:15).
2026-10-21 22:55	CloudLinux has released the patched ea-php packages (ea-php52–ea-php85).
2026-10-21	Ubuntu has released USN-8948-1: updated PHP packages for Ubuntu 22.04 LTS (php8.1, 8.1.2-1ubuntu2.28), 24.04 LTS (php8.3, 8.3.6-0ubuntu0.24.04.13), 26.04 LTS (php8.5, 8.5.4-0ubuntu1.5) and 26.10 (php8.5, 8.5.9-0ubuntu2.1) releases.
2026-10-21	Ubuntu has issued advisory USN-8948-2 for older releases: 20.04 LTS (PHP 7.4, 7.4.3-4ubuntu2.29+esm5) and 18.04 LTS (PHP 7.2, 7.2.24-0ubuntu0.18.04.17+esm14) via the ESM; updates for 16.04 and 14.04 require an Ubuntu Pro Legacy Support subscription.
2026-10-21	Debian has also released updated packages: trixie (Debian 13) php8.4 8.4.27-1~deb13u1 (DSA-6574-1) and bookworm (Debian 12) php8.2 8.2.35-1~deb12u1 (DLA-4848-1). In the unstable (sid) branch, the fix has not yet appeared in the Debian tracker.
2026-10-22 02:07	The updated alt-php packages for CloudLinux are now available in the stable repositories (CloudLinux 7, 8, 9: PHP 5.2–8.5).
2026-10-22 03:19	TuxCare has released all patched packages (alt-php, the distributions’ own PHP packages, PHP for Windows).
2026-10-22 14:05	An open-source scanning tool (Searchlight Cyber php2shell-scanner) is being released.

Frequently Asked Questions

Will this affect my WordPress site or my online shop? Yes, it could affect any PHP-based website, as the error lies in PHP. The fix is carried out on the server.

Is it enough to update WordPress or its plugins? No. The error is resolved by a PHP fix; updating the CMS alone will not fix it.

Is my website down? For a short time, yes: the Apache and PHP restarts caused a total of just a few minutes’ downtime.

Can I continue to use PHP 8.1 or an older version? PHP.net has not released an official version for these branches, but operating systems and vendors (such as CloudLinux, cPanel and TuxCare) may release backported patches for them, meaning that older versions on affected servers may also be protected. In the long term, we recommend upgrading to a supported version (8.3 or 8.4) if your website is compatible with it. Before making the change, take a backup, then test your website. We explain how to change the PHP version in cPanel in a separate article.

• cybersecurity
• php
• cloudlinux
• cpanel
• news