October 23, 2026

Two critical PHP flaws, and why we build Justflows in TypeScript

PHP just published two 9.2-rated remote code execution bugs that hit every supported version. Here is what they are, how to patch, and why they show that PHP's design has had its day.

Two critical PHP flaws, and why we build Justflows in TypeScript
On 21 October 2026 the PHP project published two critical security advisories, CVE-2026-109618 and CVE-2026-109619. Both score 9.2 out of 10. Both let an attacker with no account and no password run their own code on your web server. Every supported PHP version is affected.
We build Justflows in TypeScript, so these bugs do not touch us. We still read them closely, because they show something about PHP that is bigger than one bad week. First, though, the part that matters if you run PHP today.

Bug one: running out of memory, on purpose

The first advisory (GHSA-w8hw-w9fx-j79w) is called "RCE via OOM corruption". When a PHP request runs out of memory, PHP stops it with longjmp(), a C instruction that jumps straight back to an error handler and skips everything in between. If that happens while some request memory is only half set up, the cleanup code that runs afterwards reads memory that was never valid. The failed allocation does not even have to be related to the broken memory.
So an attacker only needs a way to make PHP run out of memory at the right moment. A file upload form is enough. The advisory lists several ways in:
  • Multipart uploads without a usable content length can keep sending data past the post_max_size check.
  • Each multipart part can carry unlimited headers, which take far more memory inside PHP than they do on the wire.
  • Empty file fields do not count toward max_file_uploads, but still create arrays, and nested field names multiply the work.
The PHP team confirmed remote code execution over plain HTTP against mod_php, with PHP's default memory and input limits. PHP-FPM and FrankenPHP look vulnerable from the source code, though no full exploit was shown for them. More workers make an attack take more tries. They do not stop it.

Bug two: yesterday's request, still in memory

The second advisory (GHSA-6wmf-4rv5-p3rp) is "RCE via stale global state". PHP likes to describe itself as shared-nothing: every request starts clean. In practice a PHP worker is a long-running process that keeps global state between requests, for errors, sessions, objects and extensions. The engine is supposed to reset all of it after each request.
When a request dies halfway, through a fatal error, a timeout or running out of memory, some of that state can be left pointing at memory that has already been freed. The next request on the same worker then uses it. That is a use-after-free, the classic memory-safety bug, and here it leads to code execution.
The confirmed attack uses session upload progress, a feature that is on by default. It was shown to work against both mod_php and PHP-FPM. Even a warning about a bad setting in php.ini or an Apache .htaccess file can be the step that reads the stale state. Turning down error_reporting does not help.

Not a bad week. A design that shows its age

Every language has security bugs, so it is fair to ask why these two say anything about PHP itself. Look at what they have in common:
  • Hand-managed memory in C. Both bugs are use-after-free and uninitialised-pointer errors (CWE-416, CWE-824) in the engine. Every PHP extension written in C adds more code of the same kind.
  • Error handling that skips cleanup. longjmp() jumps past whatever was in progress. The fix replaces it with a delayed "soft" out-of-memory and an immediate _exit() of the whole process. That is a good fix, and it shows how deep the problem went.
  • A clean slate that has to be faked. The promise that each request starts fresh only holds if the engine resets every global, after every possible failure, including failures in the middle of cleaning up from other failures.
  • Configuration as attack surface. php.ini, per-folder .htaccess overrides and the warnings they emit are part of the exploit path.
None of this is a recent mistake. It is the request model PHP was built on in the 1990s, for a web of small scripts. PHP has added a lot since then: a JIT, types, enums, readonly properties. But the engine underneath still works the same way, and these advisories are what that looks like in 2026.

Why Justflows is written in TypeScript

When we started Justflows we chose TypeScript on Node.js for the whole stack: server, admin, editor, plugin SDK and themes. These advisories are a good illustration of why.
  • Memory is not the request's job. JavaScript is garbage collected. No line of Justflows code allocates or frees memory by hand, and an error is an exception that unwinds through try/finally, so cleanup code always runs.
  • State is explicit. A Node server is one long-lived process, and nobody pretends otherwise. We design for that: request data lives in objects that belong to the request, not in engine globals that something has to remember to wipe.
  • Types from the database to the browser. The same types describe blocks, the API, the plugin SDK and the admin UI. A whole class of "this was null at runtime" bugs becomes a compile error before anything ships.
  • One language everywhere. The editor in your browser, the server that renders your pages and the plugins you install are written in the same language, with the same tools. There is no PHP-for-the-backend, JavaScript-for-the-frontend split.

To be fair

TypeScript is not a security guarantee, and we will not pretend it is. Node.js and V8 are written in C++ and have their own CVEs. npm has had supply-chain attacks. You can write an injection bug in any language.
What changes is where the risk lives. In a TypeScript app, the memory-unsafe part is the JavaScript engine itself: V8, which runs in billions of browsers and is fuzzed and attacked around the clock by some of the best security teams in the world. Your application code, and every plugin, cannot corrupt memory or leave a dangling pointer for the next request. In PHP, that risk sits in an engine and a pile of C extensions that have to get the request lifecycle exactly right, every time.

So, is PHP outdated?

For the web it was built for, PHP did a great job, and a big part of the web still runs on it. But for a new project in 2026 we do not think it should be the default anymore. A memory-safe language with a real type system, one language across server and browser, and a runtime that does not have to fake a fresh start for every request is simply a better foundation.
If you run PHP, patch today. When you plan your next site, have a look at the stack underneath it. We would be happy if you looked at Justflows.
About Justflows Read GHSA-w8hw-w9fx-j79w Read GHSA-6wmf-4rv5-p3rp
✌️

Thanks for reading!
Find more posts on the blog or star Justflows on GitHub.