2026 October: Two critical PHP bugs

On 21 October 2026 the PHP project released fixes for two critical bugs, CVE-2026-109618 and CVE-2026-109619. PHP scored each one CVSS 9.2. On a server that answers web requests with a PHP build that lacks the fix, someone who is not logged in can run their own code.

Apache with mod_php is the highest risk. A request can hit the first bug before your application code runs.

On the hosted servers Kolmisoft manages, we installed the PHP security updates. If you run the server yourself, install the updates today.

What the two bugs do

Memory handling and error handling run on a normal PHP request. A quiet page stays exposed when the worker behind it lacks the fix.

Memory runs out at the wrong moment

CVE-2026-109618 (GHSA-w8hw-w9fx-j79w) is a fault in how PHP handles an out-of-memory condition. A request that reaches memory_limit at the wrong moment interrupts PHP while internal request data is half set up. Cleanup then treats that invalid data as valid and corrupts memory.

On Apache with mod_php, a request from someone who is not logged in can reach this path before your application code runs. PHP demonstrated code execution in that setup with default settings. PHP also confirmed code execution on PHP-FPM, through paths in application code.

The next request inherits a dead worker’s state

CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp) is state left behind after a fatal error. The error hits at the wrong point, and internal data points at memory that belonged to a previous request. The next request on the same worker can use that freed memory before normal startup clears it.

PHP confirmed a use-after-free and a worker crash. The reporter demonstrated code execution against a real application on Apache with mod_php.

On 20 October 2026 a CVSS score of 10.0 circulated with the two CVE ids. PHP scored each bug 9.2.

Which installs are exposed

PHP lists every install that serves web requests: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed. The highest risk is mod_php.

A voice server is exposed when any of those processes answer HTTP. The softswitch can be a different program and the box can be exposed. Look for a database admin panel, a customer website, an old billing screen, or a container that runs PHP. The Swiss National Cyber Security Centre makes the same point for appliances and internal admin tools, not for the public website alone.

Check PHP that the internet can reach first. Then check PHP that staff alone can reach, when that process can see customer records or the billing database.

php -v
pgrep -a php
apachectl -M 2>/dev/null | grep php

php_module in the Apache module list means mod_php. That is the setup PHP ranks as the highest risk. An empty pgrep is a good result for that machine. It says nothing about a second server, a container, or a panel on another port.

Say you SSH to a server you administer. php -v prints 8.3.35, and apachectl -M shows php_module. That host needs PHP 8.3.36, or an OS package whose changelog names CVE-2026-109618 and CVE-2026-109619. Install it and restart Apache. If you installed upstream 8.3.36 and php -v prints 8.3.35, the worker is the September build. If the package came from your OS vendor, read the changelog. The printed number can stay 8.3.35.

Install these builds

The PHP downloads page has the source packages and the Windows builds. Linux distributions received the patches before the public release. Install your OS vendor’s package when they have published one.

A backport can sit inside a version string you recognize. If the package prints 8.3.35, read the vendor advisory before you treat the number as proof. The Swiss NCSC states the rule in one line: an unchanged PHP major version does not mean the patch is missing, and it does not mean the patch is present. The package changelog is the proof.

Servers we manage, and servers you run

On the hosted servers Kolmisoft manages, we installed the PHP security updates.

If the server is yours, the update is yours. Install the vendor package, or one of the four fixed releases, today. Then restart PHP so the workers load the new binary. The old workers keep running until you restart them.

Restart php-fpm, Apache, or both, the same way the site runs. For a container, rebuild the image and start the new one. Check that php -v, and the version the web worker reports, name a fixed release or a package your vendor marks as fixed.

Limits that do not replace the update

PHP says an update is the complete fix. The settings below cut some paths and leave others open. Use them for the hours it takes to get the package onto the machine.

For CVE-2026-109618, set memory_limit=-1 where the application cannot put a finite limit back. php_admin_value in the FPM pool or in the Apache config is the place PHP names. This removes the PHP memory-limit failure a caller can aim at. An allocation failure under that limit can reach the bug. If you set RLIMIT_AS or RLIMIT_DATA, the process can hit that same allocation failure.

For CVE-2026-109619, set session.upload_progress.enabled=0 in php.ini or in the FPM pool, then restart each worker. ini_set() and an FPM .user.ini apply too late. This blocks the session paths PHP confirmed. Other paths stay open. On PHP 8.5, set fatal_error_backtraces=0 and restart.

A web application firewall does not close these bugs. The Swiss NCSC says the same about stopping at the temporary steps.

If a PHP app is reachable from the internet and you cannot update it today, remove it from the internet until the package is on.

After the new binary is running

Read the logs for the window before the restart. The update does not undo a compromise that happened earlier. The Swiss NCSC tells operators to look for unusual requests, crashes, modified files, and unexpected processes.

The older PBX security notes tell you to apply a supplier advisory when it ships. This PHP release is one of those advisories. A patched PHP worker does not stop a stolen SIP password from placing calls. We wrote that case up in Your firewall passed. Your balance didn’t.

FAQ

Do I install this if Kolmisoft hosts my server?

We installed the PHP security updates on the hosted servers we manage. If you run a separate machine, a VM, or a container that we do not manage, you update PHP there.

The switch is not written in PHP. Can I skip this?

Skip the update when the server has no PHP process serving web requests. A panel, a website, or an admin tool on the same host is enough for these bugs to apply. Run the process check above before you decide.

php -v still shows 8.3.35. Is that the fix?

No. The fixed release on PHP 8.3 is 8.3.36. A distribution package can ship the fix under a different package version. Read that vendor’s security note, restart the workers, and check the binary that is running.

Update the servers you run

Read the PHP security advisory and install the fixed build today on each server you administer. The advisory lists the temporary limits, including request-size caps, for the hours before that package is on the machine.