PHP2shell: Kritische Sicherheitslücken

Schallbert — Wed, 21 Oct 2026

Step 1: Recognition: We have a problem.

TL;DR: PHP currently has two critical vulnerabilities that allow for Remote Code Execution. Their identifiers are CVE-2026-109618 and CVE-2026-109619. Since the root cause lies within the engine itself, rather than the frontend, the only solution is to update to PHP 8.5.12, 8.4.27, 8.3.36, or 8.2.35.

“I don’t use PHP on my website,” I think to myself upon receiving the following message this morning:

“Hi, quick heads-up: You might want to […] disconnect anything that uses PHP for now; […] a patch is coming later today.”

Or am I affected after all…? I do use a managed Nextcloud instance, and isn’t Nextcloud written in PHP, among other things…? As I write these lines, a fix for Nextcloud is becoming available. Everything has to happen very quickly. There will certainly be a lot of overtime worked today.

Status: October 21, 2026, 10:30 AM CEST

Let’s rewind ten hours. There is no fix yet. Information about the CVEs has leaked and is already a few hours old. According to Wikipedia, 69% of all websites use PHP. Exploiting such a highly critical vulnerability (with a score of 9.2) in such a widely used technology naturally has a huge blast radius. Consequently, “the internet” is quite nervous.

“[…] organisations should consider isolating internet-facing applications from public networks until a fix is applied and verified.” — CERT-EU, accessed October 21, 2026, 10:40 AM

Interesting. The recommendation is to “take it offline for now.”

Step 2: Immediate Measures: Taking Nextcloud Offline

To get ahead of a potential attack, I attempt to take my instance offline. I log in to my hoster’s platform, navigate to the “Settings” tab, and click on the ownCloud Console section. This is Nextcloud’s command-line interface.

Once there, I discover that there is no command available to shut down or “de-publish” the instance. So, I opt for the next best thing:

occ maintenance:mode --on

So, I put my instance into maintenance mode. This prevents new logins and freezes the database. Afterward, I read up a bit on the CVEs to see if this step is sufficient.

Apparently, it is not.

Through various forums and HackerNews, I learn that an unauthenticated request can trigger the attack before any PHP code is even executed on the server side.

In other words, it doesn’t matter what state I set my instance to, as long as it is connected to the network, it remains vulnerable.

Step 3: Interim Containment: Having the Nextcloud Instance taken offline

Even after several online searches, I cannot find a way to shut down my managed instance myself. I briefly consider killing the name resolution and DNS routing, but I quickly realize that by the time those changes propagate, the fix will likely already be available.

Status: October 21, 2026, 11:43 AM CEST

So, I submit a support ticket to my hoster, requesting assistance in taking my instance offline.

Status: October 21, 2026, 12:01 PM CEST

I receive an email from my hoster!

Sure enough, I can no longer access the instance. I’m met with an ERR_CERT_COMMON_NAME_INVALID error. Dismissing that, a message appears: REQUESTED PAGE LOCKED. Well done. The provider’s response time, including notifying the customer, was just 18 minutes.

Now, I shift from participant to observer. I’m seeing initial exploit attempts (or at least claims of them) circulating online, which brings to mind a slide from a presentation I recently watched: Security in the LLM age (at the 11:24 mark).

In it, a Linux kernel expert points out that, as of 2026, exploits are appearing in the wild an average of seven days before a patch for the affected software is even released.

discover --> disclose --> patch --> deploy

This traditional sequence of events only works well against “slow” attackers. We need something that allows us to get back ahead of the situation.

Step 4: Monitoring the Situation - Patch Availability and Initial Deployment

According to The Hacker News, the patch is set to become available around 4:00 PM CEST. I am obtaining the RSS feed from my hosting provider and awaiting further updates.

Status: October 21, 2026, 14:20 CEST

The Federal Office for Information Security (BSI) has also issued an IT security advisory, which classifies the vulnerability as having a “criticality level of 3/Orange” and notes the following:

“Der Patch für die Schwachstelle ist heute 16 Uhr deutscher Zeit (14:00 UTC) angekündigt und sollte unverzüglich zu diesem Zeitpunkt installiert werden.” - BSI, 21.10.2026

Status 21.10.2026 16:34 CEST

My hoster reports that patches are now available and that implementation has begun. Affected systems include not only the Nextcloud instances but also the hoster’s entire administration interface and their webmail service.

Status 21.10.2026 19:52 CEST

My hoster reports that the patches have been successfully applied to their web hosting services and managed servers.

Status 21.10.2026 22:40 CEST

Hetzner’s KonsoleH application, which I use to manage my Nextcloud instance, is down.

Status 21.10.2026 23:00 CEST

KonsoleH is back online (and patched).

Step 5 Insights and Conclusions

What have I learned from the events of this turbulent day? How should I handle security vulnerabilities in the future? And how can I even tell when a problem exists?

It is not just the service as a whole that is vulnerable, but its individual components as well. –> Know all your components and keep an eye out for vulnerabilities and patches!
Adversaries have become incredibly fast (thanks to LLMs). –> Expect exploits to appear even before patches are available!

I am currently compiling a list of reliable sources for information on vulnerabilities, news, and patches. Once the list is finalized, I will share it.

Step 6 Actions

Remove sensitive data from the network whenever possible. Line of thought: What if this were to disappear? Would availability within the LAN/intranet suffice?
Improved monitoring and abuse detection are the logical next steps: detect early, block early, report early, shut down early, and patch immediately.
Identify standard sources for information regarding the software in use. Perhaps build a CVE list scanner? Or a Hacker News filter?

Addendum: Oct 22, 2026, 09:30 CEST

The hoster has patched my Nextcloud instance and brought it back online. All of my systems are back to normal. There is now also a Wikipedia entry on the subject, which is kept very up to date.

Step 7: Initial Reflection

A few days have passed since the two security vulnerabilities were publicly disclosed and patches were made available. Let’s take a look at the current landscape across the web.

Status: October 24, 2026, 16:30 CEST

There are now many, many proofs of concept (PoCs) demonstrating how to exploit these PHP vulnerabilities. Most notably on the platform GitHub.

Personally, I am not an expert in this field, so I have to rely on the assessments of others regarding the quality of these PoCs, the actual feasibility of exploiting them “in the wild,” and the reasons why this particular vulnerability accumulated such significant media attention.

In general, the rule is, of course: “Patch first, ask questions later.” That is exactly what I did. To quote Felix von Leitner once again:

“One of the lessons learned from 20 years of working in the security field is that when one person claims a bug exists, and another claims it isn’t exploitable, it almost always turns out, in hindsight, that it was exploitable after all.” - Feliks von Leitner, alias Fefe, April 12, 2014, accessed October 24, 2026

Regarding exploitability, flare.io which describes itself as a threat intelligence site, notes that most proof-of-concept (PoC) exploits for PHP2shell only functioned within laboratory environments. They are rarely applicable to real-world targets. Either because they require internal operational knowledge of the systems being attacked, because they depend on other vulnerabilities (such as the disabling of memory randomization), or because the PoCs themselves are merely “AI-slop”: poorly validated, hastily written software that promises more than it delivers.

eliastaylor expresses a similar view:

“There isn’t an easy exploit for this PHP vulnerability.” - https://eliastaylor.com/noexploit/, accessed October 24, 2026

Writing less than ten hours after the attack vector and patch were released, he argues that:

none of the proof-of-concept (PoC) exploits actually work. Not even on a standard installation and configuration of a pre-patch version of PHP
these two CVEs are far less critical than other historical security vulnerabilities (citing Heartbleed in OpenSSL as an example)
the exploits were not crafted by actual humans, but rather generated with the help of LLMs.

The core of the argument is that people are delegating their cognitive work to language models, failing to verify whether the system is actually doing what it claims to do. Let alone reading, understanding, or improving the code the system generates. Malicious botnets are still crafted by human hands, a process that takes time, especially when the vulnerabilities are not obvious or trivial to exploit.

As a brief exercise to help form an own assessment of the situation, I recommend scanning the “issue” discussions found on the GitHub repositories for many of these “PHP2Shell” PoCs.

However, the significant media attention has some advantages: it seems the world is patching quickly. I’ve taken a look at the discourse across various German and international forums: everywhere, people are pushing their hosting providers to apply patches, discussing the potential impact, and tracking which vendors have already released updates.

That still leaves the question of who actually benefits from all this. I have a few theories. However, it is still too early to draw conclusions or form a judgment.

PHP on Schallbert's Blog