Security Panic Retrospective

Setting the stage

October 21, 2026 was surely a day to remember in the cybersecurity space. We start the day before (the 20th) with someone disclosing that the private key for one of eMudhra's signing keys is 4. Yep, you read that right, just 4. Now, this wouldn't be so bad if eMudhra was some nobody, but it turns out that they chain to several roots that are trusted by your standard trust stores, Microsoft, Apple, Mozilla, Google, etc, and therefore by many other downstream trust stores. We are still not quite sure how they were able to become an intermediary CA with such poor cryptography but what's done is done. You can check to see if you are still vulnerable by visiting eMudhra we have a problem. As a consequence of this disclosure, a lot of people, including me, found out how everybody likes to vendor their own root stores, so making sure that all devices and other services were updated was a lot more annoying.

The downside is that these certificates are still likely buried in the root stores for a bunch of IoT devices. Luckily for us, the attack surface for these devices is not large. There is not much reason for an off the shelf router to visit a random webpage and trust any of their certificates, and proper mTLS implementations should be checking for a signature from a specific certificate, but it does feel kind of bad. Especially in the case of old medical equipment, which may have to send data to a web service. However, such an attack would likely require prior compromise on the local network or be the result of a larger network infrastructure attack, both of which have more severe consequences to worry about.

In the end, though, eMudhra is now no longer an intermediate CA and has stepped away from the certificate business.

Data breaches and other vulnerabilities

We were also notified of large number of data breaches on the same day, several of which demonstrate somewhat concerning behavior. Railway was breached, and all users are recommended to rotate secrets. For some reason, they decided that sitting on this information was the best course of action. Apparently NCC Group sat on a year old audit report for TiDB and it also got breached a month later.

LiteLLM suffered another supply chain attack and a malicious version was published featuring a credential stealer. Gitlab released a patch for an RCE. NodeJS also had its own RCE.

PHP

And thus we are at the elephant in the room. Two separate but related bugs lead to essentially zero click RCE on any PHP server. You can read the detailed writeup by Calif here. This is definitely a huge bug. PHP powers over half of the web. Wordpress, Laravel, MediaWiki, etc, all run on some form of PHP. We should certainly sound the alarms for a MUST UPDATE TODAY announcement. However, the news surrounding this bug seems to have been fear mongered into oblivion. Several cybersecurity posers who have never exploited a single live memory corruption vuln have told me that this has the security community quaking in their boots. In reality, nobody is really panicking. We go to our software distributor and we download the newest version of PHP, and we systemctl restart php-fpm.service. At the end of the day, all the "public" PoC scripts were mostly LLM slop and none of them work against a vanilla PHP installation. In fact, many of the public PoCs also require additional vulnerabilities coexisting on the PHP server, such as local file inclusion, which is roughly synonymous with cat /etc/passwd levels of damage. So in that sense, maybe it is not as easily exploitable as the true "we're fucked" vulnerabilities of times past, i.e.

1. Log4Shell, by setting User-Agent: ${jdni:ldap:}
2. Heartbleed, by setting Content-Length: 99999999
3. Rails YAML, by sending any POST body with some bad YAML
4. EternalBlue, resulting in the 2017 ransomware apocalypse

There are probably a lot reasons this particular RCE has gotten the press that it has gotten, mostly in part due to

1. The prevalence of LLMs. A lot of people now believe they are experts in fields they really are not.
2. We like to clown on PHP.
3. Some PHP team member said this was cataclysmic.
4. The looming AI apocalypse.

But the reality of the situation is that the exploit is not so easy. It took over 19 hours for an attacker to exploit a public challenge for $2000 in BTC, several days after the vulnerability was disclosed. It's not like threat actors are suddenly going to switch their MO to exploiting a specific PHP vuln when it is not their specialty. @MalwareTechBlog explains it best.

Anyone claiming they were "easily" able to generate a working php2shell exploit with AI is either:

a) a world-class exploit developer with an extreme case of imposter syndrome.

b) currently looking at some very confident-sounding but wrong LLM output.

And that is with AI assistance. There are certainly live and working exploits, but these are in the hands of very skilled exploit developers. Given how finnicky this exploit seems to be in practice, it is certainly not as world ending as it may have initially seemed.

Funnily enough, patching your system to protect against the eMudhra certificate issue (affects everyone) likely takes more effort than upgrading PHP (only affects PHP server owners). Of course, this is not to downplay how severe the vulnerability actually is. It exists, is exploitable, and results in a RCE under a lot of conditions. However, on the scale of meh to we're fucked, perhaps this time the exploitability of php2shell was vastly overstated.

Personal upgrades

As a result of these vulnerabilities, I begrudgingly updated many personal services. My mail server was running an old version of dovecot, as version 2.4 introduced breaking config changes that I never bothered migrating last year. Therefore, upgrading PHP meant also upgrading dovecot since Archlinux is a rolling release distribution.

My home router is a pfSense installation. It was running 2.4.5-RELEASE and at some point I had tried doing a manual upgrade and broke my pkg-static binary, in the sense that the new binary that I had was not for FreeBSD 11.3, and thus had broken syscalls. This was back in 2024. Fast forward to 2026, and my router is still chugging along on 2.4.5. The entire pfSense web configurator runs on PHP, and there's a near zero-click PHP RCE going around. Granted, the web configurator was only accessible on an internal subnet, but this finally prompted me to perform the upgrade. I don't know why the new installation process uses this crazy store download product, so what I did was download a 2.7.2 ISO from a mirror, backed up my config.xml, and went to town. I reinstalled pfSense, which only took like 5 minutes after booting into the USB image, spent another 5 figuring out how to mount a USB drive and manually restore the old config because I could not access the web configurator, and then 2 more system upgrades to 2.8.1 and 2.9.0. Luckily, the system upgrades were fast, and took around 7-8 minutes each on a gigabit connection.

As a side effect of upgrading my pfSense, though, I could no longer host my Unifi controller software on the machine. Ubiquiti somehow decided that they would release an all-in one software for all their products that only runs on Windows, Linux, or macOS. Luckily, I was prepared and exported by network config, reset my UAP-AC-Lite, imported the old config into the new software on a different machine, readopted my AP, and reprovisioned the networks. I then discovered the next day that my Elgato light no longer wanted to connect to the network it used to be set up with so I had to reset that as well. So I guess I am in the market for a more sane managed access point when I decide to upgrade.