Given this week's events with PHP, let's talk a little about CVEs. For once I will try to make an episode that is not about LLMs. Try. I will also try to keep it readable for the non-techy crowd, so I am leaving out a lot of details on purpose and simplifying plenty. Simplified, but still fairly accurate. Fellow cowboys, bite your tongues on the well-actuallys.

First of all, wtf is a CVE? It stands for Common Vulnerabilities and Exposures, a public catalog of known security holes, run by MITRE since 1999 and paid for by the US government (cve.org). Every hole gets an ID, so we all yell about the same bug. This week's are CVE-2026-109618 and CVE-2026-109619. How bad a hole is gets a score from 0 to 10, and this week's two got 9.2. Not great.

In short, a CVE is something you need to worry about the moment your code faces the internet. Coding projects roughly come in three tiers: personal fun tools, internal professional tools and publicly available tools. Each step up that ladder adds a new pile of things to worry about, and the last step adds the whole internet. I might go deeper on the tiers in a later episode.

PHP CVE

As most of you are aware by now, two vulnerabilities became public this week. I spend most of my time in the CLI, and I don't really read news from there. Logs, on the other hand, I read more often than my email, as confessed last week. That is how I found out. I am the maintainer of notiduck.com, a website monitoring service, and suddenly the watchducks started quacking at a lot of users about their sites being down. On my end that showed up as an unusual spike of activity in the logs. My first thought was: did AWS or Cloudflare mess up again? Hmm, no, not widespread enough. Maybe React had a new CVE. PHP, the boring old school workhorse? Would never have guessed it. But PHP it was, and plenty of sites were deliberately pulled offline until they could be patched.

I will not go too deep on the actual issue, but in short, two independent teams, Calif and Wiz, had discovered some serious security issues. The first report reached PHP back in August, and it stayed secret until this week. That is how it is supposed to work. Fix it quietly first, then tell the world. Here is the strange part. AWS logged an exploitation attempt in its honeypots on 17 October, 4 days before it became public, and they can't explain how the attacker knew. Details also leaked early, which pushed the release forward by a day, but that does not explain 17 October. Me and my tinfoil hat smell a leak, either human or perhaps even LLM. Guess we will never be told for sure, which, if you ask my hat, points to the latter.

NOT THE FIRST RODEO

As a software developer, I find it interesting that this one got so much mainstream media attention. I guess it is because PHP is considered a fairly safe language. And remember my first guess, React? Not a random guess. The one I remember best is the infamous React2Shell CVE of 2025 (CVE-2025-55182, CVSS 10). It sat in React Server Components, the part of React that runs on the server, and Next.js runs that by default even when you only use it for frontend. The servers running my SaaS tools suddenly started to mine crypto. Pretty scary. That led me to harden my monitoring tool, so it does not only report when a site goes down, but also when it starts to sweat. Like when my servers were redlining the CPU on crypto mining, but only at a level where the sites were still happily returning 200, tutto bene. Likely a topic for a future episode.

It is so easy to hate on React that I won't even bother. Yes, I dislike it a lot, but it is so convenient for making pretty buttons and other irrelevant frontend stuff I do not enjoy spending my time on, that I have had to swallow my pride and go for it, simply to satisfy the UI designers' wishes.

A much cooler CVE was the xz backdoor (CVE-2024-3094), an astonishingly impressive and sneaky human achievement. A still unknown actor, going by "Jia Tan", spent about two and a half years becoming a trusted maintainer of xz utils, a boring compression library that most Linux systems ship. On some distros, sshd loads it indirectly through systemd, and that was the way in. Credit where credit is due. Whoever is behind Jia Tan, one person or a whole team, pulled off years of patient, sneaky, evil but brilliant work. Pure human ingenuity, no LLMs credited.

It was discovered by a Microsoft hero. Yes, you heard me, a hero from Microsoft. Andres Freund noticed that ssh logins on his machine took about half a second longer than they should and used too much CPU (his original report). Half a second. Most of us would have blamed the Wi-Fi and moved on. Thanks to him, it was caught before it reached the stable releases of the big distros. Had it not been noticed, the unknown actor would have held a master key to most of the servers on the internet, and those servers run your bank, your email, your hospital and plenty of government systems. On a day of their choosing, they could have deleted the data or locked it with a ransom, all of them at once, plus any backups they could reach from there, and nobody would have seen it coming. Picture waking up to that day. Card payments don't go through, so no groceries and no fuel. The hospital can't open your records, so no prescriptions and no surgery. No email, no news sites, and the government systems that should coordinate the cleanup are down too. Everyone calling the same IT people at the same time, and the only way back is whatever someone kept offline in a drawer. And to be fair, for the truly critical stuff, someone did. Banks, hospitals and governments keep backups locked away with no internet connection, the same idea as the Svalbard Global Seed Vault, which stores seeds for the world's crops inside an Arctic mountain. So not the end of the world, but weeks or months of a very bad time. I have seen this movie before, it is called Die Hard 4.0, and I did not like it. Except this was not a movie, it was a near miss, saved by one guy annoyed by half a second. To me, this should have been front page news everywhere, but I never saw it outside nerd corners. Maybe exactly because our hero caught it in time. A disaster that never happened makes a lousy headline.

WHAT IS A SHELL

So what does the "2Shell" in PHP2Shell and React2Shell actually mean? A shell is the command line interface, the thing I live in all day. Whoever has a shell on a machine can tell it to do anything. Well, almost anything.

On Linux, every file has an owner and a list of who may read it, change it, or run it. Your diary might be readable and writable by you, and off limits to everyone else. Programs work the same way. Every program runs as some user and can only touch what that user is allowed to touch. Your website usually runs as a weak user with access to little more than the website itself. Then there is root, the boss, who can touch everything.

Normally a website only answers requests. Show me this page, log me in. An X2Shell bug is a hole where an attacker sends a specially crafted request, and the server ends up running it as commands. PHP to shell, React to shell. Now they can type commands on your machine as if they were sitting at your keyboard, as the weak website user. Weak, but enough to read your site's database password, rewrite your pages, or start a crypto miner, which is what happened to me with React2Shell. From there, the attacker tries to climb to root, and if that works, the machine is theirs, not yours.

FEWER DEPENDENCIES, SAME PROBLEM

I am already working on removing npm, React and other external dependencies from my tools. npm is the app store for JavaScript code, and a typical project quietly pulls in hundreds of little packages written by strangers. npm has had its own Jia Tan moments. In 2025, a single maintainer got phished, and attackers slipped crypto-stealing malware into packages like chalk and debug, downloaded billions of times a week. Fewer dependencies means less code from strangers on my servers, and fewer Jia Tans. But this week's incident makes me wonder if even vanilla JS is safe. In the browser it mostly is, because it runs sandboxed on the visitor's machine, not mine. The catch is on the server. PHP2Shell was not in some plugin or framework, it was in the PHP engine itself. A "Hello World" page was enough. The same can happen to Node, Python, or whatever runtime I pick, and no amount of dependency cleanup protects me from the runtime under my code.

So the plan is boring. Keep the dependency list short, patch fast, and keep watching the servers for sweating, not just for being down. Half a second of sweat once saved the internet, so I am not ignoring my CPU graphs anytime soon.

Thanks for “listening” to my yap, see ya next week.