PHP vulnerabilities CVE-2026-109618 and CVE-2026-109619: what to do now with your website

On 21 October 2026 at 16:00 Swiss time, the PHP project released versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35. They fix two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, which under certain conditions allow an attacker to run code on a web server without authentication and without any user interaction. The same day the Swiss National Cyber Security Centre (NCSC) recommended installing the updates without delay.

PHP is the language behind WordPress, Joomla, Drupal, Magento, Laravel and Symfony applications and a great many online shops and business tools. If your website runs on one of these, this concerns you. Below are the verified facts, the versions to install and a practical checklist.

What happened

According to the php.net security advisory, both flaws sit in the PHP core, in memory management and error handling, parts that almost every request passes through:

• CVE-2026-109618: when a request runs out of memory at the wrong moment, PHP can leave internal data only partially initialised and later treat it as valid, corrupting memory.
• CVE-2026-109619: internal state tied to a request can survive after its memory has been freed; a later request handled by the same worker can reuse it.

Both are rated 9.2 out of 10 under CVSS 4.0, which is critical. The score of 10.0 that circulated on social media before the release was wrong, as the PHP Foundation points out. In the media the flaws are also called "PHP2Shell", by analogy with Log4Shell in 2021.

The vulnerabilities were reported by the security firms Calif and Wiz and by OpenAI. Publication was planned for 22 October, but on 20 October the CVE identifiers began to circulate online and the PHP project brought the release forward by one day.

Who is affected

According to php.net, every PHP installation that serves web requests is at risk: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The risk is highest for Apache with mod_php, where an attack was demonstrated in which an unauthenticated request triggers the flaw before any application code runs. Vulnerable versions range from 5.4 to 8.5.11; Germany's BSI refers to all versions going back to at least PHP 5.

The NCSC stresses that checks should not stop at public websites: PHP can also sit inside admin interfaces, internal applications, hosting platforms, containers and appliances, sometimes without the operator knowing.

The threat situation

At the time of release no confirmed exploitation was known. The BSI did, however, mention unconfirmed reports of existing exploits, and the Canadian Centre for Cyber Security reports that a proof of concept is available. According to the BBC, Cloudflare's chief technology officer said he was seeing early attacks emerging.

Several public bodies took their websites offline as a precaution until the fix was installed: in Germany, for example, the Baden-Württemberg state government and several universities (tagesschau); according to the BBC, also the Finnish government's public web services. These were not successful attacks but precautionary measures.

The versions to install

• PHP 8.5: version 8.5.12
• PHP 8.4: version 8.4.27
• PHP 8.3: version 8.3.36
• PHP 8.2: version 8.2.35 (end of support on 31 December 2026)

PHP 8.1, 8.0, 7.x and older no longer receive official updates. The PHP security team has published minimal source backports for 7.4, 8.0 and 8.1, and some Linux distributions provide fixed packages, but the recommended path is to move to a supported version.

Watch the version number on Linux servers: distributions often apply the fix to their own package version. On Ubuntu 24.04, for example, the fixed package is 8.3.6-0ubuntu0.24.04.13 (USN-8948-1); on Debian 13 it is 8.4.27-1~deb13u1 (DSA-6574-1). What counts is the exact package version given by the vendor, not just the number PHP shows.

What to do now

On managed hosting

If your site is on shared or managed hosting, updating PHP is the provider's job. Ask them for written confirmation that the fix is installed, as the NCSC also suggests. In the control panel, check which PHP version your site uses: if it is 8.1 or older, plan the move to 8.3 or 8.4 now, testing it first on a copy of the site.

On a VPS or your own server

1. Take a backup or snapshot of the server, including databases and uploaded files.
2. Update the PHP packages from your distribution's package manager (on Debian and Ubuntu: apt update and an upgrade of the PHP packages).
3. Restart PHP-FPM and the web server: without a restart, running processes keep using the old code.
4. Check the version actually in use with php -v and the package version, including for the process that serves the site.
5. Rebuild and redeploy any Docker images that contain PHP.
6. Check the logs for unusual requests, crashes, modified files and unexpected processes: an update does not undo a compromise that has already happened.

One more good practice: set expose_php = Off, so the server does not announce its PHP version in HTTP headers. It does not protect against the flaw, but it gives less information to anyone scanning for unpatched servers.

If you cannot update right away

php.net lists some temporary measures, such as session.upload_progress.enabled=0 and a low post_max_size. They only reduce individual attack paths and do not make an installation safe. According to the NCSC, a web application firewall on its own is not enough either. For critical applications, consider taking them off the internet temporarily.

Quick checklist

1. List the websites, online shops, business tools and panels that use PHP.
2. For each one, note who runs it and which PHP version it uses.
3. Ask your hosting provider to confirm that the fix is installed.
4. On your own servers: backup, update, restart services, verify the version.
5. Plan the move from PHP 8.1 or older to a supported version.
6. Also update your CMS, themes and plugins, which is a separate matter.
7. Keep an eye on the logs and site files over the coming days.

Frequently asked questions

Is my WordPress site at risk?

WordPress runs on PHP, so yes, if the server uses an unpatched PHP version. The problem is not in WordPress but in the language underneath: updating WordPress and its plugins is useful, but it does not replace a PHP update.

How do I find out which PHP version my site uses?

In your hosting control panel, usually under PHP or the site settings. In WordPress, go to Tools, Site Health, Info, Server. On your own server, use php -v and check the installed package version.

My site still runs PHP 7.4: what should I do?

PHP 7.4 no longer receives official updates. The minimal backports published for 7.4 are meant for people who build PHP themselves or have no vendor with extended support. For a business website, the right path is migrating to PHP 8.3 or 8.4, tested first on a copy of the site.

Is a firewall or a service like Cloudflare enough?

No. They can filter some known attacks, but the NCSC states that a web application firewall alone is not sufficient. The only complete solution is the update.

Can the update break my site?

An update within the same branch, for example from 8.3.35 to 8.3.36, is a security release and normally does not change behaviour. Moving to a new branch, for example from 7.4 to 8.3, should be tested on a copy first, because old themes, plugins or code may not be compatible.

I have updated: is there anything else to do?

Restart the PHP services, check the version in use and review the logs. If you notice modified files, unknown admin users or strange processes, treat the server as compromised.

Our approach

ElaraTeq Sagl runs websites and applications for SMEs and public bodies in Ticino with hosting in Switzerland. We can check which PHP version your site uses, install the fix or plan the migration away from an unsupported version. For ongoing maintenance there is the service described in Orbit; for a check, get in touch.

Sources

• PHP, "Security advisory: Critical remote code execution vulnerabilities, update now", 21 October 2026: php.net
• PHP, GitHub advisories GHSA-w8hw-w9fx-j79w (CVE-2026-109618) and GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
• The PHP Foundation, "Today's PHP Security Release", 21 October 2026: thephp.foundation
• Swiss NCSC, "Critical vulnerabilities in PHP: Install security updates immediately", 21 October 2026: bacs.admin.ch
• BSI, "PHP – Kritische Schwachstellen bedrohen Webanwendungen weltweit", 21 October 2026: bsi.bund.de
• Ubuntu, USN-8948-1; Debian, DSA-6574-1
• Canadian Centre for Cyber Security, AL26-026
• tagesschau/SWR, 21 October 2026: Baden-Württemberg websites taken offline as a precaution; BBC, 21 October 2026: Websites taken down worldwide