Critical PHP vulnerabilities CVE-2026-109618 and CVE-2026-109619: what you need to know

On October 21, 2026, the PHP security team released PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35 to fix CVE-2026-109618 and CVE-2026-109619. Both are rated CVSS v4.0 9.2 and can lead to unauthenticated remote code execution on any PHP installation that serves web requests. The PHP team considers mod_php the highest-risk deployment, with a demonstrated exploit that fires before any application code runs. Updating is the only complete fix. Red Sift has scanned the Hardenize customer base for PHP-backed hosts and notified affected customers directly.

• Every PHP version from PHP 5 onward may be affected, across PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed.
• PHP 8.1 and older get no official release. Use a vendor backport, the PHP team's source-only patches for 7.4, 8.0 and 8.1, or upgrade.
• Configuration changes reduce exposure to known attack paths but don't make an installation safe.
• PHP is often bundled with appliances and third-party products, so a version check on your own servers isn't the full picture.

PHP runs a large share of the server-side web, from content management systems to admin panels on network appliances. A bug that lets an anonymous request execute code in the PHP runtime itself, independent of the application on top, is about as broad as web vulnerabilities get.

The PHP team gave advance notice on October 20 and shipped fixes the next day. National CERTs moved quickly. CERT-EU told organizations to prepare for immediate patching and to consider isolating internet-facing PHP applications until fixes land. The UK's NCSC asked organizations to take immediate action, starting with finding every system that runs PHP.

Both bugs sit in how PHP manages per-request state inside a worker, not in any application code.

• CVE-2026-109618, RCE via out-of-memory corruption (GHSA-w8hw-w9fx-j79w). An out-of-memory condition can interrupt PHP while internal request data is only partly initialized. Request cleanup then treats the half-built data as valid, thereby corrupting memory. Under the right conditions, an attacker who can push a request into the OOM path can exploit that corruption to execute code.
• CVE-2026-109619, RCE via stale global state (GHSA-6wmf-4rv5-p3rp). Request-owned internal state can outlive the memory that backs it. A later request handled by the same worker can use that stale state before normal initialization resets it, giving a use-after-free across requests.

The second bug matters most for long-lived workers, which is how PHP-FPM, mod_php, and FrankenPHP all run. The PHP team rates mod_php as the highest-risk setup because its demonstrated exploit triggers during request parsing, before your application sees the request. A web application firewall rule tied to application routes won't catch it.

Any PHP installation that serves web requests is in scope. That covers PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed. CERT-EU notes that every version from PHP 5 onward could be affected, so an old version number isn't a reason to deprioritize a host. It's a reason to move it up the list, because PHP 8.1 and older won't get an official package.

The harder part is the PHP you didn't install yourself. Appliances, hosted services, and third-party applications often ship PHP as an internal component. Those products only get fixed when their vendor releases an update. NCSC-NL maintains an inventory of software with a PHP dependency that may be affected, which is a good place to start that part of the search.

Ahead of the PHP release, we scanned the hosts we monitor across the entire Hardenize customer base to find which ones run PHP. We then mapped those hosts back to each customer and contacted everyone directly affected with a list of hostnames that may be exposed, the release time, and links to the official advisories. That gave teams visibility into their exposure before the fixed versions were published, so they could schedule maintenance windows instead of starting discovery after the release.

If you're a Hardenize customer and you didn't receive a notification, we didn't find PHP on the hosts we monitor for you, but we advise that you still run cursory checks on your end. External scanning only sees what a host reveals and covers only the assets in your account. Internal systems, hosts outside your monitored scope, and products that hide their PHP runtime still need to be checked by you.

Patch what you can as soon as possible if you've been affected. Everything on this list is for hosts you can't patch today.

• Find every PHP install, starting with internet-facing hosts. Don't filter by version, since all versions may be affected. Include containers, base images, and anything built from source.
• Update to a fixed release. Move to 8.5.12, 8.4.27, 8.3.36, or 8.2.35, or install your distribution's patched package. Linux distributions and LTS vendors received the patches in advance. If you use rpms.remirepo.net, the PHP team recommends switching to distribution packages or building from source, because that repo didn't have same-day updates.
• Handle end-of-life branches. On 8.1 and older, use a vendor backport, build from the PHP team's source backports for 7.4, 8.0, or 8.1, or upgrade.
• Restart every worker. A patched binary does nothing for FPM pools or Apache children still running the old code.
• Chase bundled PHP. Check vendor advisories for appliances and products that embed PHP, and apply their updates as they land.
• Mitigate or isolate what you can't patch. Apply the interim measures below. If you can't, CERT-EU and NCSC both advise taking the internet-facing application offline until it's fixed.
• Look for compromise on hosts that stayed exposed. NCSC recommends checking for backdoors before or alongside remediation on any system you couldn't update quickly.

• Set memory_limit=-1 in a way applications can't override, such as php_admin_value in the FPM pool or Apache config. Make sure no pool, directory, or app setting puts a finite limit back. An underlying allocation failure can still reach the vulnerable path.
• Lower post_max_size to 8M where uploads aren't needed, or 32M where they are, and keep upload_max_filesize below it. Enforce request size, field count, multipart part count, header count, and nesting depth limits at the web server or proxy, including for requests without a usable Content-Length.
• Use a container or cgroup memory limit that kills only the affected worker. Don't use RLIMIT_AS or RLIMIT_DATA, which can trigger the vulnerable allocation failure.

• Set session.upload_progress.enabled=0 in php.ini, the FPM pool or server config, then restart every worker. ini_set() and .user.ini apply too late to help.
• On PHP 8.5, set fatal_error_backtraces=0 and restart every worker.
• Remove invalid or deprecated per-request settings that emit diagnostics before initialization. Suppressing output with error_reporting, display_errors, or @ doesn't help.
• Fix fatal errors and execution timeouts an attacker can reach, including in callbacks, upload or import processing, and cleanup.

These measures block the confirmed attack paths, not every variant of them. Treat them as a bridge to patching.

The first instruction in both the CERT-EU and NCSC advisories is the same. Find where PHP runs. For most teams, that's the slowest step, because the answer is spread across cloud accounts, acquired domains, marketing sites, and vendor appliances that nobody has on a list.

Red Sift Hardenize continuously discovers and monitors your external-facing and cloud assets, so when a runtime-level vulnerability like this is discovered, the list of exposed hosts already exists. That's what lets us notify customers with specific hostnames before the fixed versions are shipped.

• PHP security advisory and release announcements, October 20 and 21, 2026
• GHSA-w8hw-w9fx-j79w, CVE-2026-109618
• GHSA-6wmf-4rv5-p3rp, CVE-2026-109619
• CERT-EU Security Advisory 2026-018
• NCSC, Critical security issue affecting PHP
• NCSC-NL php2shell inventory of affected software