PHP CVE-2026-109618 / 109619: Emergency PHP Update

Sounds familiar?

Tick what applies to you

How I solve it

What I build

I find which PHP actually serves each of your domains and bring it to a release that contains both fixes: 8.2.35, 8.3.36, 8.4.27 or 8.5.12, or a vendor build that carries the patches. Then I restart every PHP worker that runs it, because a fixed package does nothing until the old processes are gone, and I check that the site still works: pages, login, forms and checkout. If the update cannot happen today, I apply the stopgap settings from the advisory and tell you in writing that they are not a fix.

What was announced on 21 October 2026

The PHP project published a critical security advisory with two vulnerabilities in PHP itself: CVE-2026-109618, remote code execution via OOM corruption, and CVE-2026-109619, remote code execution via stale global state. Both are rated CVSS 4.0 9.2. php.net says they affect all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed, and that only an update is a complete solution.

Fixed PHP versions

PHP branch	First release with both fixes
8.5	8.5.12
8.4	8.4.27
8.3	8.3.36
8.2	8.2.35, end of life on 31 December 2026
8.1, 8.0, 7.4	No release from the PHP project. Source backports are published; check your vendor build.

Where the risk is confirmed

Apache with mod_php: remote code execution confirmed for both CVEs. For CVE-2026-109618 the attack runs before any site code starts.
PHP-FPM, including behind Nginx: for CVE-2026-109619 remote code execution was validated under specific conditions; for CVE-2026-109618 the risk comes from source analysis.
FrankenPHP and LiteSpeed: named by php.net as affected; exploits there are described as likely but not demonstrated.
Static sites and Node.js, Python or Go apps without PHP are not directly affected by these two CVEs.

The process

How it works

Map the domains

For each domain I find the server or container, the way PHP runs (mod_php, FPM, CGI, FrankenPHP or LiteSpeed) and the exact version that answers requests.
Pick the update path

Distribution security packages, the hosting panel, a rebuilt Docker image, or a vendor build for PHP 8.1 and older.
Back up first

A copy of the PHP configuration and a way back before anything changes.
Update and restart

Install the fixed release, then restart every FPM pool, Apache or container that runs PHP.
Check the site

Version confirmed per domain, then pages, admin login, forms and checkout tested.
Write it down

What ran before, what runs now, and anything that still needs a decision, such as an unsupported PHP branch.

Handover

What you get

Every domain mapped to the PHP that actually serves it, before and after.
PHP on a release with both fixes, or a written reason why not yet and the plan for it.
All PHP workers restarted, so the fix is really running.
A short check of the site after the update.
A written summary you can forward to your host, agency or insurer.

Built with10 parts

PHP-FPM
Apache mod_php
Nginx
LiteSpeed
FrankenPHP
Docker images
Debian and Ubuntu security packages
cPanel and Plesk
WordPress Site Health
Composer

Proof

Done before, with dates and numbers

Before → after

Before, one “update now” email and no clear owner of the server. After, each domain runs a PHP release with both fixes, the old processes are gone and the site has been checked. This page describes the service; it does not claim a completed client case for these two CVEs.

What you can look at

A per-domain sheet: domain, server or container, PHP mode, version before, version after, workers restarted, site check result. Shown here as a synthetic example; client data is never published.

Capability page written on 21 October 2026 from the php.net security advisory and the two PHP GitHub advisories. No completed client remediation of these two CVEs is claimed. I run my own Docker and Nginx infrastructure and have worked on WordPress, WooCommerce, Magento, PrestaShop, OpenCart and Drupal sites.

Price and timeline

What it costs and how it runs

A Technical Working Session costs USD 195: one server or hosting account checked live and updated in the session where the access allows it, with a short written summary. Several servers, containers, custom builds or PHP 8.1 and older need a Focused Fix from USD 450, with the scope and date in writing first. Discussing the task is free.

QuoteFixed before work starts

Price: Technical Working Session USD 195: one server or hosting account checked live and, where your access allows it, updated in the same session, with a short written summary. Focused Fix from USD 450 for several servers or containers, custom PHP builds, or PHP 8.1 and older that needs an upgrade path. Discussing the task is free.
Timeline: I start once access is confirmed, the same working day where possible, Europe/Madrid. A Working Session is up to 60 minutes plus a short written summary; a Focused Fix gets a written date before work starts.
First step: Describe the task. I reply within one working day, free, and tell you which option fits — or that you can fix it yourself.

Describe a task like this

A note from Daniilbefore you decide

When you don’t need this

If your site is static or runs on Node.js, Python or Go without PHP, these two CVEs do not apply to it. If your managed host has already confirmed in writing that your plan runs a fixed release and the workers were restarted, you only need to check the version shown for your site.

— Daniil

Questions

What people ask about this

Is my WordPress or WooCommerce site affected?

If the PHP that serves it is older than 8.2.35, 8.3.36, 8.4.27 or 8.5.12 and has no vendor patch for both CVEs, yes, it is in scope. Updating WordPress, the theme or plugins does not fix it: the flaws are in PHP itself. WordPress shows the PHP version under Tools → Site Health → Info → Server.

We run Nginx with PHP-FPM, not Apache. Are we safe?

No. PHP-FPM is in scope. The risk is highest for Apache with mod_php, where an exploit was shown before any site code runs, but for CVE-2026-109619 remote code execution was also validated on PHP-FPM under specific conditions. Nginx in front does not remove that.

php -v on our server already shows a new version. Are we done?

Not necessarily. The site may be served by a different PHP: a container, a separate FPM pool or a version picked in the hosting panel. And a fixed package only protects you after every running PHP worker has been restarted.

We are on PHP 7.4, 8.0 or 8.1. What now?

The PHP project no longer ships releases for 8.1 and older. Its security team published source backports for 7.4, 8.0 and 8.1, and some Linux distributions and LTS vendors ship patched builds. I check whether your vendor build carries both fixes; if not, I plan the move to a supported branch.

Can a config change fix it without updating?

No. The advisories say only an update is a complete fix. Settings such as session.upload_progress.enabled=0, a lower post_max_size or, on PHP 8.5, fatal_error_backtraces=0 reduce the risk for a while. I use them only as a stopgap and say so in writing.

Is my Shopify store affected?

The store itself runs on Shopify, so there is no PHP of yours to patch there. A custom app, integration or webhook receiver you host yourself and that is written in PHP is in scope.

What access do you need?

Shared hosting: the hosting panel, where the PHP version is chosen. A VPS or dedicated server: SSH with sudo. Containers: the repository or registry and the deploy pipeline. I do not need passwords sent in chat; we set access up the safe way first.

Tick what applies to you

What I build

Fixed PHP versions

Where the risk is confirmed

How it works

Map the domains

Pick the update path

Back up first

Update and restart

Check the site

Write it down

What you get

Done before, with dates and numbers

What it costs and how it runs

When you don’t need this

What people ask about this

More like this

Have a task like this?

Discuss your task

Talk to Daniil