PHP Just Got Two Critical CVEs. Neleto Never Had to Patch.

On Tuesday, October 20, the PHP security team announced a critical security release before any details had been published. They only do that when it's serious. Two vulnerabilities, both rated CVSS 9.2, with the patch scheduled for today, October 21, at 14:00 UTC. CERT-Bund scored it 9.8 (critical). CERT-EU went further: the flaws could lead to remote code execution, and they affect every PHP version from 5.0 onward.

If you run WordPress, Laravel, Drupal, or any of the tens of millions of other sites on PHP, that last sentence is a fire drill. Patch now, or take your internet-facing apps offline until you can.

What the CVEs are (so far)

The two identifiers are CVE-2026-109618 and CVE-2026-109619. At the time of writing, no technical details have been published. The PHP team reserved the right to ship the release early "should details of either vulnerability become public, or should evidence of active exploitation appear in the wild."

That clause is the scary part, because it means the fix may be racing attackers. Without public details there's nothing to evaluate yet. All you have is a deadline.

Why Neleto was never in the blast radius

Neleto's request-serving path has no PHP interpreter in it.

The backend is Rust, built on axum, talking to Postgres through sqlx. Pages render through our handlebars engine, and Caddy sits in front as the gateway. The admin panel is a Vue 3 SPA. None of that is PHP, so there is no interpreter on the serving path for these CVEs to run inside.

You can't be hit by a PHP interpreter bug if you never load one. We didn't plan for this particular CVE. It follows from the choice we explained in why we wrote the backend in Rust.

Any runtime can rot

The problem this week isn't specific to PHP. Every language that ships a runtime has it.

An interpreted language carries its interpreter with it, on every server, behind every app. That interpreter is one large shared program, compiled once by the language team and inherited by every application that runs on it. A bug in it affects every app on every machine running that version, no matter how careful the application author was. The developer who wrote your CMS didn't write the vulnerable line. They inherited it along with the language.

PHP isn't alone here. Ruby, Python, Node.js and the JVM all ship a runtime, all of them have had runtime-level CVEs, and all of them will have more. The runtime is a big codebase that every app on top of it shares, and it's usually older than those apps. When it has a bug, every app pays for it, whether it wanted to or not.

Why compiled languages are inherently better here

A compiled backend bakes its code into its own binary. At request time there is no interpreter between the request and the code, so there is no interpreter attack surface to inherit. The kind of bug PHP just got hit by, a flaw in a shared runtime underneath every app, doesn't exist in a compiled backend.

So for this kind of vulnerability, compiled languages are inherently better: no runtime, no runtime bugs.

That doesn't make "compiled" a synonym for "safe." C and C++ are compiled, and they are still famous for buffer overflows and use-after-free bugs. Removing the interpreter closes one attack surface and leaves another. You stop inheriting the runtime team's bugs and start owning the ones the application author writes.

Rust goes one step further. The borrow checker rejects a whole class of memory-safety bugs at compile time, so many of the bugs that make C and C++ scary never compile in the first place. For this class of problem, the ranking looks like this:

1. Interpreted runtime bugs, PHP's problem this week.
2. Compiled-but-unsafe memory bugs, C and C++'s problem.
3. Rust, where the compiler catches a large slice of both before they ship.

Another reason we chose Rust

When we picked the language, we wrote it up as a performance and cost decision. Both reasons held up, and the numbers are in the benchmarks post. But this week reminded us of a benefit we'd underweighted: with a compiled backend, we patch our code, not someone else's interpreter.

A PHP CVE hits millions of servers at once. Everyone shares the same upgrade window and installs a patch they didn't write and can't fully audit. A bug in Neleto is in code we own, and the compiler already argued with us about it before it shipped. When the next critical bug shows up, it's ours to fix, not buried in a decades-old interpreter we depend on.

What Neleto isn't immune to

Neleto is not immune to everything, and anyone who tells you otherwise is selling something. The admin frontend is TypeScript running in a JavaScript runtime, just in the browser instead of on the server. And every server depends on system libraries, OpenSSL above all. A compiled language shrinks the attack surface. It doesn't make it zero.

What the serving path does rule out is this week's failure mode: one flaw in a shared interpreter putting millions of apps at risk at the same time. When a bug does land in Neleto, it's in code we can read and audit ourselves, not in a runtime we inherited from 2004.

What this means for you

If you run PHP today: the release is out, go patch. CERT-EU's advice was blunt. Identify your PHP assets and upgrade as soon as fixed versions are available, or isolate internet-facing apps from the public network until you can.

If you're choosing a CMS for the next few years, ask a question most comparison articles skip: what language is the backend written in, and does it ship a runtime? The interpreter is part of your attack surface whether you wrote it or not, and this week showed what that costs when it breaks.

Sources

• PHP security team announcement, October 20, 2026
• CERT-Bund, WID-SEC-2026-4055: "PHP: Mehrere Schwachstellen ermöglichen nicht spezifizierten Angriff"
• CERT-EU, Security Advisory 2026-018: "Critical Vulnerabilities in PHP"

Fast websites. Easy content. Agent ready.

Start free at neleto.io, a CMS whose backend doesn't share a runtime with half the web.