Critical PHP vulnerabilities (CVE-2026-109618 and CVE-2026-109619): what happened and what to do

On 21 October 2026 the PHP project released fixes for two critical flaws, and CERT-EU published advisory 2026-018 the same day. Both are rated 9.2 and both are described as remote code execution without authentication. If you run a WordPress site, a shop or any other PHP application, this concerns you, and the fix is an update, not a setting. This article explains what is known, how the attack gets in, and what to do. Status: 22 October 2026, based on version 1.1 of the CERT-EU advisory.

What happened

PHP announced a security release on 20 October and published the fixes on 21 October at 13:30 UTC. CERT-EU titled its advisory “Critical Vulnerabilities in PHP” and lists two CVEs: CVE-2026-109618 and CVE-2026-109619, each with a score of 9.2. CERT-EU also writes that technical details are now discussed publicly and that first proof-of-concept code has started to circulate. The advisory does not confirm attacks in the wild, but it says this makes it more likely that attackers are already exploiting the flaws. Treat it as urgent.

Who is affected

The affected versions are every PHP release below the fixed one in a supported branch, and every end-of-life branch.

CERT-EU names PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. According to the PHP team, mod_php carries the highest risk. Products that embed PHP can be affected too; CERT-EU points to a list from the Dutch NCSC at the end of this article. Any installation that serves web requests counts, whether or not it has an upload form.

How an attacker reaches the first flaw

Nobody has to log in. According to CERT-EU, a demonstrated exploit shows that a single unauthenticated request can trigger the attack before any application code runs. That is the point most people miss: it does not matter whether your WordPress is current, whether your plugins are patched or whether your contact form is protected. The request reaches the PHP engine first.

The first flaw, CVE-2026-109618, works like this:

1. A request arrives at an address that PHP serves. No login, no account.
2. PHP starts reading the request body. CERT-EU names the parsing of form-based file uploads as an example.
3. PHP enforces its memory_limit with longjmp(). When the limit is exceeded, it jumps out of whatever it was doing and ends the request.
4. If that happens in the middle of setting up internal request data, that data is only half built.
5. The cleanup afterwards treats the invalid data as valid and frees memory that was never initialised. That memory can still hold data from earlier allocations that the attacker controlled.
6. From there the advisory describes remote code execution on the server.

We deliberately do not describe how an attacker steers the last step. It is enough to know that the entry point is not your application, and that is why nothing inside your application can stop it.

The second flaw: state that outlives its memory

CVE-2026-109619 is a different mechanism with the same result. PHP keeps internal state for each request. After certain failures, such as a fatal error, that state can remain even though the memory underneath it has been freed. The next request handled by the same worker can then use this stale state before it is reset in the normal way. The attacker needs two requests that land on the same worker; CERT-EU rates the outcome the same as the first flaw: remote code execution.

What to do today

1. Find out which PHP version actually serves your site. php -v on the command line shows the command-line version, which can differ from the one your web server uses. Check php-fpm -v, your hosting panel or a page that calls phpinfo(). On shared hosting, ask your provider.
2. Update to a fixed version: 8.5.12, 8.4.27, 8.3.36 or 8.2.35. Distributions often backport fixes without changing the version number, so look for the CVE numbers in your vendor’s security notice. In containers, rebuild from an updated base image. The PHP team notes that rpms.remirepo.net had no updates on the day of release and recommends distribution packages or a source build.
3. Restart every PHP worker. An update on disk does not change processes that are already running. Restart PHP-FPM or the web server, then check the running version again.
4. If you cannot update today, isolate the server from public networks until the fix is in and checked. CERT-EU is clear that only an update fully fixes these flaws.
5. If you are on PHP 8.1 or older, ask your vendor for the backport or move to a supported branch. These versions get no regular updates.

Workarounds that reduce the risk but do not fix it

CERT-EU lists measures that make an attack harder. It states plainly that they do not make an installation safe. Use them while you prepare the update, not instead of it.

• Against CVE-2026-109618: set memory_limit=-1 in a way applications cannot override, for example with php_admin_value in the FPM pool, and check that no pool, directory or application entry sets a finite limit again. Set a low post_max_size (8M without uploads, 32M with) and keep upload_max_filesize below it. Limit request size, field count, multipart parts, header count and nesting depth at the web server or proxy. Use a container or cgroup memory limit as an availability boundary, but not RLIMIT_AS or RLIMIT_DATA, which can trigger the vulnerable allocation failure.
• Against CVE-2026-109619: set session.upload_progress.enabled=0 in php.ini, the FPM pool or a server configuration that applies before request parsing (not with ini_set() or .user.ini), and restart all workers. On PHP 8.5 also set fatal_error_backtraces=0. Remove invalid or outdated per-request settings that print diagnostics before initialisation, and fix fatal errors and execution timeouts that an attacker can reach.

What SilentShield can and cannot do here

This is not a bot problem, and we would rather say so than let a product page imply otherwise. The attack hits the PHP engine before anything of ours, or any CAPTCHA, plugin or firewall rule inside your application, sees the request. A bot protection on a form does not stop it, and nobody should tell you it does. The only complete fix is the PHP update.

The SilentShield API and dashboard are not written in PHP. The WordPress plugin and the PHP SDK run inside your own PHP, so for them the update has to happen on your server. After you have updated, the usual protection against bots and form spam is as useful as before; it just was never the answer to this.

Sources

• CERT-EU Security Advisory 2026-018: Critical Vulnerabilities in PHP
• PHP announcement of 20 October 2026
• GHSA-w8hw-w9fx-j79w (CVE-2026-109618)
• GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
• NCSC-NL php2shell: products that embed PHP