How a memory error in PHP can run a stranger's code on your server

Two critical bugs in the language under most of the web

On 21 October 2026 the PHP project published an advisory titled "Critical remote code execution vulnerabilities, update now". PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix two bugs, CVE-2026-109618 and CVE-2026-109619, that can allow unauthenticated remote code execution. Both score 9.2 out of 10 on the CVSS 4.0 scale. PHP says every installation serving web requests is at risk and rates mod_php highest, where "an unauthenticated request can trigger the attack before any application code runs".

That phrase is why a founder should care. Your login, your input checks and your framework are application code, and here none of them gets a say. The flaw sits in the PHP engine underneath.

W3Techs reports that PHP is used by 69.3% of all the websites whose server-side language it can identify. The figure shows 100 PHP sites split by version, as of 24 October 2026.

Switch to all sites. PHP 7 and older is 34.6% of PHP sites (26.8 plus 7.7 plus 0.1), and 34.6% of 69.3% is about 24% of all sites with a known language. The project no longer fixes 8.1 and older, and W3Techs does not split 8.x by minor version on that page, so 24% is a floor. The advisory does not say how far back the flaws reach, but the team prepared source fixes for 7.4, 8.0 and 8.1 "to help people building from source or without access to an LTS vendor", so I read those branches as affected.

Bug one: running out of memory at the wrong moment

CVE-2026-109618 is about what PHP does when it runs out of memory. A request passes through three stages: start up, where PHP builds the request's data, then your code, then shut down, which frees that data. When an allocation fails, PHP uses the C call longjmp() to leave the request at once. In some places the request's data can be reached before it is fully set up. The jump skips the rest of the setup, and shut down still runs and treats the half-built data as valid.

Switch to the second request. The allocation fails while slot 4 is being set up, slots 4 to 6 are never built, your code never runs, and shut down reads 3 of 6 slots that hold nothing valid. Corrupted memory is how a crash can turn into code execution. The CVSS vector marks attack complexity as high, which fits the advisory's warning that reliability depends on the PHP build, its extensions, the web server in front and how memory is laid out. On mod_php the advisory validated a complete unauthenticated attack over HTTP with default limits. On PHP-FPM it found the code susceptible but no complete exploit.

A stranger has to make PHP run out of memory without tripping your limits. The advisory lists ways. A multipart upload without a usable declared length passes the first post_max_size check and keeps supplying data. One part can carry any number of headers, and each is stored in memory.

Drag the slider to 250,000 header lines. At a made-up 30 bytes each that is 7.2 MiB sent, under an 8 MiB limit. At a made-up 600 bytes of memory each it is 143 MiB, over a 128 MiB limit.

Bug two: a worker that remembers too much

CVE-2026-109619 is a different failure. A PHP worker is a long-lived process that serves request after request, and it keeps global state: error, session, object and extension data. Some of that state points into memory owned by one request. If the request ends abnormally, with a fatal error or a timeout, the step that clears the pointer can be skipped while the memory is freed. The pointer now dangles, and the next request on the same worker can use it in an early step, before normal setup replaces it.

Run it both ways. The advisory says the request that leaves the pointer and the request that uses it are different HTTP requests on the same worker. Its strongest demonstrated trigger is PHP 8.5's fatal error backtraces. Session upload progress is another: it is on by default and needs no session_start(). The confirmed impact is unauthenticated use-after-free, memory disclosure and remote code execution with the web worker's privileges, validated on mod_php and, through the session path, on PHP-FPM. A fresh process for every request (pm.max_requests=1) removes the stale pointer; PHP lists it as a way to reduce exposure, at a cost in speed.

What a stranger could do with it, and where a startup is exposed

The advisories stop at remote code execution with the web worker's privileges. For a business that means code running as your web server's user. It can read the application's configuration, which usually holds database passwords and API keys, change anything the app can, leave a back door that survives the patch, and reach other machines the server can talk to. That is my reading of what code execution generally allows; the advisory describes none of it.

How likely is an attack now? In an alert updated on 23 October, the Canadian Centre for Cyber Security said open-source reporting indicates a proof of concept is available and that it had identified no active exploitation, adding that this "can change quickly".

Two published figures give the stakes, and neither is about PHP. Verizon's 2026 Data Breach Investigations Report says 31% of breaches now start with software vulnerabilities, ahead of stolen passwords as the top way in (incidents from 1 November 2024 to 31 October 2025). IBM and Ponemon put the 2026 global average cost of a data breach at $4.99 million, up 12% and a record, across all kinds of breach.

Where a startup's version of this hides:

• A site an agency built years ago, still on PHP 7.4, on a server nobody signs in to.
• A container image built last spring. Patching the host does nothing for the PHP inside it.
• A shared host or managed platform where you never see the PHP version. Ask for it in writing.
• A vendor product that bundles PHP. The Cyber Centre tells teams to inventory third-party products and containers that include it.
• A server whose php -v looks old. Distributions can backport fixes without changing the version, so check the vendor's notice as well as the number.

What the stop-gaps close and what they leave open

For people who cannot update at once, PHP published settings, but updating is the only complete fix. The figure lines them up against five ways in.

Switch to the stop-gap settings. Three doors close, one narrows and one stays open. memory_limit=-1 removes the memory-limit failure, but a real allocation failure can still reach the bug, and a low post_max_size with input limits only makes that harder. session.upload_progress.enabled=0 and fatal_error_backtraces=0 each block only the confirmed path they name. Early warnings, other fatal errors and timeouts have no setting: PHP says there is no complete generic configuration mitigation.

What to do this week

Find every copy of PHP

List your servers, containers and vendor products, with the PHP version and how each serves the web.

php -v                              # version on this machine
apachectl -M | grep -i php          # a php module here means mod_php
docker run --rm your-image php -v   # the version baked into an image

Update, then restart

Move to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or your distribution's updated package, then restart PHP-FPM or Apache so running workers load it. On 8.1 or older, ask your vendor for a backport and plan the upgrade. The project's source backports for 7.4, 8.0 and 8.1 are for teams that build from source.

If you cannot update today

; PHP's partial measures of 21 October 2026. Restart every worker afterwards.
php_admin_value[memory_limit] = -1   ; in the FPM pool, so apps cannot change it
post_max_size = 8M                   ; 32M if you need uploads
session.upload_progress.enabled = 0
fatal_error_backtraces = 0           ; PHP 8.5 only

With the memory limit gone, put a container or cgroup memory limit around the workers so a runaway request cannot take the machine down, as the advisory suggests. Avoid RLIMIT_AS and RLIMIT_DATA, which can cause the very allocation failure the bug needs.

Watch for signs, and expect a third report

Read web server and application logs for unexpected processes, files, accounts and outbound connections, as the Cyber Centre advises. On 23 October PHP added CVE-2026-115560, an unlikely path that needs an application to switch session.serialize_handler to php at runtime with ini_set() while upload progress is on. Its full advisory is due with the next release; session.upload_progress.enabled=0 covers it.

How a patch moves through a real product

Wanguza, the school admissions CRM, runs on Next.js on Vercel, so these PHP bugs are not in it. Its release path is the useful part, because an emergency update is only calm when the normal release already is. Every pull request gets its own preview deployment, which works as a staging copy. Checks run there and the change is tried with test schools and test messages. Merging to main deploys to production, and if something goes wrong the previous deployment comes back in one step. See the case study.

Questions to answer today

1. Which PHP versions do we run, where, and who owns each one?
2. Does Apache serve any of it through mod_php?
3. Is anything on 8.1 or older, and who provides its fixes?
4. Which of 8.5.12, 8.4.27, 8.3.36, 8.2.35 or a vendor package is running now, and were the workers restarted?
5. If we have not patched, which stop-gap settings are on, and who confirmed it?
6. How many hours pass between a critical advisory and the fix reaching production, and how do we undo a bad release?
7. Who reads security advisories for us?