Which layer did the vulnerability occur in? Telling language flaws apart from CMS design

Hi, I'm Takeshi Kashihara ("Kassy") at exc-D inc., the company behind Dixlase.

On October 21, 2026, critical vulnerabilities in PHP itself (CVE-2026-109618 / 109619, known as "php2shell") were disclosed.
What we ask of everyone running Dixlase is covered in our earlier post, "The PHP vulnerabilities (php2shell): how Dixlase is responding."

The PHP vulnerabilities (php2shell): how Dixlase is responding.

Since then, I've seen a range of reactions on social media around me, such as "PHP has a long history, so isn't its design just old?" and "Isn't it time to move to something built on another language?"
It's natural to feel uneasy.

But there are two things worth checking here.
One is which layer this vulnerability occurred in. The other is whether "PHP is risky because its design is old" or "another language would be safe" is actually true.
Looking at these two questions separately makes it much clearer what to do.

In this post, I'll walk through how to tell them apart.

A website is built from many layers

A website running on a CMS isn't a single piece of software. It's made of many layers stacked on top of each other.
A vulnerability can occur in any of these layers, and depending on the layer, who fixes it and what you need to do are different.

In the table below, the higher a layer sits, the closer it is to what users see; the lower it sits, the closer it is to the foundation the other layers run on.
A problem in a lower layer reaches every layer stacked on top of it.

The server itself (the OS and web server) is a foundation that sits even below the language.
Operations such as settings, passwords, and backups aren't confined to one place, though. They touch every layer.

php2shell is in the "language & runtime" layer

This vulnerability occurred near the bottom of the table, in PHP itself: one of the foundation layers.

That means it isn't a problem with any particular CMS.
Whichever CMS you use, and whether or not you use a CMS at all, every site or service running on PHP was affected.

Sources: The Hacker News / Help Net Security

Vulnerabilities in this layer are the kind that close once the language team releases a fix and users update to it.
This time, too, PHP released fixed versions on October 21.

Here, the one who updates to the fixed version is whoever manages the server, which isn't always the site operator.
If you run a small VPS, your own server, or Docker, the site operator often manages the server too, so that person updates PHP.
On dedicated or in-house servers where running the site and managing the server are handled by different people, the server team updates it. Site operators should confirm with them that the update is done.
On shared hosting, updating PHP is the hosting provider's job, and site operators can't do it themselves. Please check your provider's notices.

On the other hand, a problem in this layer can't be fixed from the CMS running on top of it.
That's why updating Dixlase didn't fix this vulnerability.
What a CMS developer can do is explain what to do quickly and clearly, and make what it distributes (for Dixlase, the Docker installer) easy to update.

What kind of vulnerabilities were they?

Both were caused by flaws in how memory is handled inside PHP itself, which is written in C. Either could let someone who isn't logged in make PHP run code remotely.

• CVE-2026-109618: When memory runs out partway through processing, half-built data is left behind, and the cleanup that follows treats it as valid.
• CVE-2026-109619: A use-after-free, where memory that has already been freed gets used later. State left over from one request is used by the next request handled by the same worker.

According to PHP, when PHP runs built into Apache (mod_php), it has been confirmed that the flaws can be hit before any application code starts running. That's why tightening login checks on the application side doesn't protect against them. With other setups, too, PHP still needs to be updated.

Sources: Tenable, "php2shell (CVE-2026-109618, CVE-2026-109619): Critical PHP RCE FAQ" / The Hacker News

"Old" and "risky" are two different things

After this incident, I saw a range of opinions on social media, such as "PHP has a long history, but its design is old. Maybe it's time to move to something newer."
It's true that this flaw had been sitting in PHP for a long time. But a long history, or an older design, doesn't directly translate into being less safe.

PHP, for example, is a language with about 30 years of history; its source code was first released in 1995.
Since then, it has been revisited with each new version. PHP 8 brought major improvements, such as stronger type handling and JIT (a way to speed up execution).

In 2010, PHP adopted a rule to ship a new version once a year. New versions still come out every year: 8.2 (2022), 8.3 (2023), 8.4 (2024), and 8.5 (2025).

Sources: PHP Manual, "History of PHP" / PHP 8.0 Release Announcement / PHP RFC, "Release Process" / PHP, "Supported Versions"

Vulnerabilities in the runtimes that run a language aren't unique to PHP, either.
The engine that runs JavaScript (V8) also had a vulnerability that was actively exploited and fixed in September 2026.

Source: The Hacker News (September 2026)

On October 21, the same day the php2shell fixes came out, Node.js, a JavaScript runtime, also fixed 10 vulnerabilities. One of them (in Brotli decompression) could allow remote code execution.

Source: Node.js, "Wednesday, October 21, 2026 Security Releases"

The systems around a language have their own risks too.
In 2025, an attack spread through the system that distributes JavaScript packages (npm) by taking over one package after another, and the U.S. agency CISA issued a warning.

Source: CISA, "Widespread Supply Chain Compromise Impacting npm Ecosystem" (September 23, 2025)

This doesn't mean PHP or JavaScript is bad. Every language, and every layer, carries risk.
What matters, I believe, is that fixes come out quickly when a vulnerability is found, and that users are set up to apply them right away.

AI has changed how fast vulnerabilities are found

AI played another role in php2shell.

According to reports, researchers used AI models to greatly speed up the work of confirming that long-standing flaws could actually be exploited. They say one person did in about a week what would otherwise have taken a team months.
Reports also say PHP's developers had noticed the issue in 2024, but the fix stalled because they couldn't agree on how to make it.

Sources: The Hacker News / The Next Web

It isn't only defenders who got faster.
Amazon points out that AI-assisted analysis is making it cheaper and faster to turn a fix into a working attack. The time between a vulnerability's disclosure and the start of attacks is likely to keep shrinking.

Source: Amazon Threat Intelligence

OpenAI, one of the parties that found these vulnerabilities, says this is just one of several significant vulnerabilities it has already found and is working to fix, and that it expects similar findings to increase sharply in the coming months.

Source: OpenAI, "Patch the Planet: global response coordination as agents uncover critical vulnerabilities" (October 21, 2026)

We don't think this is only about PHP.
The longer software has been in use, the more likely it is to have problems that went unnoticed for years. With AI's help, new vulnerabilities may well be found in other languages and software too.

More vulnerabilities being found can seem frightening.
But software becomes safer as problems are found and fixed. What matters is that they're fixed quickly once found, and that users can update right away.

Extension safety is about design, not language

The "plugin vulnerabilities" that often come up when people talk about CMSs belong to the extensions layer in the table. They're a different thing from language vulnerabilities.

Some CMSs are built so that plugins run in the same place as the core and can do almost anything the core can.
Dixlase is like that today. Our official plugins don't do anything that would break the core, but by design, they could.

Letting plugins do what the core can do is convenient, but it also means a hole in a single plugin can affect the whole site.

We think how to contain this is decided by the CMS's design, not by its language.
For example, there are approaches like these:

• Limit permissions: decide in advance what each plugin is allowed to do
• Verify where it came from: check that a distributed plugin is exactly what its author released
• Isolate it: run plugins in a place separated from the core

Any language, PHP included, can adopt these ideas.
Switching languages doesn't automatically make things safe. Whatever the language, protection has to come from design.

In Dixlase

For the extensions layer, Dixlase currently has these protections:

• Permission declarations: a plugin declares in advance what it will do
• Signature verification: we check that official plugins haven't been altered after distribution
• Health score: before a plugin is installed, we inspect its contents and score it

On the other hand, we don't yet have a way to run plugins isolated from the core (a sandbox). I want to be upfront about that. Sandboxing plugins is something we'll be exploring going forward.
So today's Dixlase can't fully prevent plugin vulnerabilities.

The reason Dixlase builds protections like multi-factor authentication, passkeys, and tamper detection into the core rather than into plugins is to reduce, as much as possible, the need to add plugins just for security.

Even static sites don't get rid of layers

After this incident, I also saw people saying, "Let's move to a static site."
It's true that a static site has no PHP or CMS layer, so it isn't affected by vulnerabilities like this one.
But the other layers remain.

• Web server: In October 2021, a vulnerability in the Apache web server (2.4.49) that could expose files outside the published directories was found and actively exploited. Under some conditions, it could also allow remote code execution.
• Scripts loaded from elsewhere: In June 2024, the source of a JavaScript file that many sites loaded from outside passed to a new owner, and malicious code was inserted into the script it served. More than 100,000 sites were affected, and visitors were redirected to scam sites.
• Server accounts and the tools that build your site: If a password is stolen, or a package used in your build is taken over, the HTML and JavaScript themselves can be rewritten.

Sources: Tenable, "CVE-2021-41773" / BleepingComputer (June 2024)

Moving to a static site is a choice to reduce the layers you protect. It isn't a choice to get rid of them.

When you see vulnerability news

When you see news about a vulnerability, checking these three things first will help you respond calmly:

1. Which layer is it in? The language, the CMS core, a plugin, or your server settings?
2. Is your site affected? Does it apply to what you use, and to your versions?
3. Is a fix available? If so, update. If not, follow the developer's guidance and put a stopgap in place.

Closing thoughts

Vulnerabilities happen in every language, every CMS, and every layer.
That's exactly why I think it matters less to ask "which one is absolutely safe" and more to know "when something happens, what gets fixed, by whom, and how."

Dixlase can't claim to be absolutely safe either.
We'll keep fixing problems quickly when they're found, and keep explaining clearly what you need to do.

Feel free to share your thoughts through a GitHub issue or on social media.

Update history

• 2026-10-28: Published
• 2026-10-30: Added "What kind of vulnerabilities were they?"