A social media post was asking about the hassle of a secure connection to an ISP router (using TLS), and it reminded me of the early 1990s when we used to hand-craft TCP/IP networks on 3Com, Cayman, etc. as if it was serious engineering. All that’s ancient history because everything has been made so easy that anyone can connect securely.

That being said, vendors today aren’t really doing their part to make the easy stuff easy. For example, the German company FRITZ! still tells its customers to click through a certificate warning on their own router login.

That’s just nuts.

Its help page walks users through clicking past the certificate warning in every major browser and assures them that from the home network “This does not pose a security risk.” The same page tells them to ignore the browser warnings about an unencrypted login as well, because the interface opens inside the home network and the password stays off the internet.

Matthew Wallace and I covered this attack in Securing the Virtual Environment: How to Defend the Enterprise Against Attack, published by Wiley in 2012. That’s 15 years ago! Certificate warnings and operator fatigue were among the easiest attack vectors in the book. An operator who clicks through the same warning on every login will click through an attacker’s certificate the same way, because the two warnings look identical.

Come on vendors, what are you doing?

The certificate authorities way back in November 2011 (CA/Browser Forum) adopted Baseline Requirements that phased out publicly trusted certificates for internal names and reserved IP addresses, with November 1, 2015 as the latest permitted expiry. That’s a decade gone already since everyone was supposed to be doing internal networking the right way. Look at how Let’s Encrypt now issues IP address certificates, limited to public addresses it can reach for validation. A router at 192.168.178.1 can present only a certificate its owner chose to trust, so the vendor has to give the router a public name.

All of the pieces of this puzzle have been public for years.

Using bland generic marketing for internal name resolution has drawbacks. FRITZ! routers answer fritz.box from their own resolver, and .box is a public top-level domain. At the end of January 2024 an attacker registered fritz.box, and heise reported that the domain redirected to various websites and intercepted SSH connection attempts. AVM, now FRITZ!, won control of the domain through WIPO arbitration in May 2024. Because, duh. But also, why didn’t they think of this before? The name the vendor thought of as private had a public registration sitting open.

Netgear, by comparison, tried to shortcut the safety of real public names with a certificate. It procured a certificate for routerlogin.com and shipped the private key in its router firmware, where anyone could extract it from a router or from the firmware downloads on Netgear’s own site. The certificates were revoked after the key was exposed for being in the public. A shared key makes every router the same router, and anyone holding the firmware can impersonate it.

Plex solved the same problem in 2015 for home media servers. Plex bought DigiCert certificates for every server. Each server holds a wildcard for its own hash-named subdomain of plex.direct, and a name such as 192-168-1-7.hash.plex.direct resolves to the LAN address written into it. The key is only on a single device and the operator’s browser can verify the certificate against the name.

A router has the easier version of this, so it makes no sense why router vendors are delaying the proper solution. Plex had to tell users to switch off DNS rebinding protection, because resolvers filter public names that point at private addresses. The router is the actual resolver that DHCP assigns to every client on the network, so it can answer its own name with its LAN address directly.

Any vendor could ship this today, and regulators should demand it already.

1. The router generates its own key pair on first boot and keeps the private key on the device.
2. The vendor assigns each router a random, unique hostname under a domain the vendor owns and answers the DNS-01 challenge in its own zone, so the router stays closed to inbound traffic.
3. The router’s resolver answers that hostname with the router’s LAN address.
4. The friendly name and the bare IP serve a plain HTTP redirect to the unique HTTPS name, and the login form appears only there.
5. The router renews through the vendor automatically and falls back to its own individual self-signed certificate if renewal fails.

FRITZ! is sitting on all the pieces and just needs to put them together. Each box that registers with MyFRITZ! receives a random, unique address ending in .myfritz.net. Since FRITZ!OS 7 the box can obtain a Let’s Encrypt certificate for that address and renew it on its own. Each box also carries an individual self-signed certificate, so FRITZ! avoided Netgear’s shared key.

FRITZ! currently points at the Internet. The Let’s Encrypt certificate requires a MyFRITZ! account, and the box opens a port to the internet during validation. AVM’s release notes state that HTTPS to fritz.box or the local IP keeps the self-signed certificate.

The FRITZ! example is useful because the change is so trivial for them and so powerful for their customers. AVM issues the myfritz.net names under its own domain, so it can answer DNS-01 for every box in its own zone. The certificate belongs in the default setup, separate from remote access, with the box answering its myfritz.net name with its LAN address and fritz.box serving a redirect to it.

First setup remains the one exception. A new router reaches setup before its WAN connection is up, and a certificate installed at the factory would expire (public certificates are already capped at 200 days and drop to 47 days in March 2029). So the first session would be on the box’s own self-signed certificate, and the vendor can print its fingerprint on the label next to the Wi-Fi key it already prints.

Speaking of printing keys, here’s a fun history fact: when I met with 3Com in 1999 to evaluate their very first ever WEP-capable access point, the plastic case had the passwords embossed into it (AirConnect at Networld+Interop). Literally four hard-printed passwords in the white plastic. “What were you thinking” I asked with my mouth open in shock. “Nobody will ever use WEP if it’s not easy enough” they said. I’m not sure they were right, but I remember one of the worst concepts of secret keys ever. See also CVE-2001-0352.

SNMP agents in 3Com AirConnect AP-4111 and Symbol 41X1 Access Point allow remote attackers to obtain the WEP encryption key by reading it from a MIB when the value should be write-only…

Like, nobody at 3Com said “maybe a sticker would be better than designing the hardcase mold for the same four WEP keys to be fixed forever for everyone”. Talk about planned obsolescence. Sad history fact: 3Com is no more.

FRITZ! gets the Internet side right but still hasn’t closed the gap on the home network. They have had the solution since FRITZ!OS 7 and it’s long past time to get it done right, the easy way.

Public evidence for PHP2Shell has turned out to be far thinner than its headlines. It’s a bad bug, yes, but who caused so much attention to it instead of other bugs?

Wiz frames the reach of the flaw as 70% of the internet, and its write-up says the impact “cannot be overstated.” OpenAI called it one of the most impactful security issues in recent memory, a line that Fortune carried.

This is a pattern. In 2023 I noted Wiz’s Microsoft AI leak report was technically sound and overstated the risk to sell the product. OpenAI has become synonymous with overstatement and bellicose self-promotion. Weren’t they recently warning us the world already would be ended?

Attempts at compromise, versus actual compromises, are separate numbers. No vendor has published a confirmed compromise, and the exploit experts I have spoken to have seen none. TechTarget reports Cloudflare seeing attempts in the thousands to millions, and Amazon honeypots logging probes from 17 October. Recorded Future says the public evidence leaves the full extent of successful exploitation and confirmed compromises open.

The public proof-of-concept code is weaker.

SC World quotes a developer who tested the three most-starred GitHub repositories against a vanilla PHP server. Once again proving, as an aside, that stars are a worthless measure. Each “starred” code failed to reach code execution. Chainguard’s CEO told TechTarget that many of the public exploits were fake or were removed before they worked. Recorded Future adds that the author of the bundle later invalidated his own theory.

The leaked bundle that set off the panic was, in Kevin Beaumont’s reading, machine-generated and only half right, and the copies on GitHub that built on it inherited those mistakes.

The advisories explain part of this. Both CVE-2026-109618 and CVE-2026-109619 rate attack complexity as high (AC:H). Calif’s write-up shows why. The chain needs control over memory layout and, on PHP-FPM, cooperation from the application.

Compare that with a bug I reported to Qdrant that was just disclosed this week.

GHSA-frc7-44gm-99qq carries a CVSS score of 9.8, with attack complexity low, no privileges required, and no memory tricks. I reported it to the vendor in February and then again formally through the German BSI on 9 July, and it was published on 22 October.

I should point out PHP’s advisories use CVSS v4.0 and Qdrant used the old v3.1, which means the comparison depends on an attack complexity field. I mean, aside from the fact that the Swastikas run on Qdrant and the whole world runs on PHP.

Patch history

The history of patching is always a great story.

In January 2003, Slammer was a single UDP packet carrying 376 bytes against a Microsoft SQL Server bug patched six months earlier (MS02-039, 24 July 2002). It reached 90% of vulnerable hosts in ten minutes, doubling every 8.5 seconds. There were no funny memory tricks and no second request. The attack complexity was zero, so the whole story was six months of customers left vulnerable by (failing to patch from) the richest company in the world.

In May 2017, WannaCry ran on a Windows bug patched two months earlier (MS17-010, 14 March 2017) and shut down hospitals and factories that had not applied it. In June 2017, NotPetya ran on the same patched bug. That same spring, Equifax was breached through an Apache Struts bug whose fix (S2-045) had shipped in March; GAO put the exposure at least 145.5 million people.

In December 2021, Log4Shell was one line in a text field. The fix shipped in days, and the Cyber Safety Review Board called it an endemic vulnerability whose instances “will remain in systems for many years to come, perhaps a decade or longer.”

Every one of these had the kind of easy exploit that almost anyone could run. PHP2Shell does not rise to this level, yet. That is the difference between a bad week and a bad year, and so far PHP is getting a lot more attention than if AI hadn’t tried to convince everyone it was the only bug in town.

PHP history

PHP has been here twice before, three times if you know the secret.

In May 2012, CVE-2012-1823 leaked by accident from PHP’s own bug tracker. The rushed fix was broken within hours and the second fix followed a week later. Scanners still probe for it. In June 2024, CVE-2024-4577 was patched on a Thursday and in ransomware by the weekend. Both were argument-injection bugs, one request, again no memory layout to manage.

The secret is the lineage Calif lays out. Stefan Esser found the first PHP memory_limit remote bug in 2004 and withheld his exploit. In 2020 a report of long multipart variables causing out-of-memory conditions sat in the tracker as a minor bug. In 2024 an OSTIF and Quarkslab audit found a related issue, could not prove exploitation, and it went unfixed.

And so a very old bug was turned it into code execution in August 2026 with an AI assistant and a history that said where to look.

Twenty-two years from first sighting to patch. The hard part was never finding the bug. It was proving there is an exploit, and then getting one to work, which is where everyone except the discoverers still sits today.

Patching now

Patching is the gap that’s easy to measure. Censys counts 3,082,629 hosts and 56.7 million web properties running PHP. Its dashboard at php2shell.censys.com updates hourly. In the latest update, PHP 7.4, 8.0 and 8.1 received source-only backports with no compiled release. The older branches stand as follows.

Given all that, if you ask me, the risk is low. The potential is high, higher than before AI made a big deal about it, still not as high as other bugs getting no attention at all.

An RSA key opened a Tor exit server at 04:38 UTC on 28 August 2026. It wasn’t in the authorized_keys file. Surprise?

Dan Goodin at Ars Technica ended his reporting of 333 hijacked exits on this silent key, calling it a last perplexing finding. The relay operators called it an open question on the tor-relays list.

But I looked at their own post and see an answer.

Ebury loads keys from memory. ESET documented the method in October 2017: on a backdoor connection the implant sets sshd’s AuthorizedKeysFile to /proc/self/environ and hooks open(), so the attackers’ RSA public key is read from the process environment and authorized.

The authorized_keys file is bypassed. The operators pulled the implant configuration from process memory on their own servers and printed it: AuthorizedKeysFile /proc/self/environ, UsePAM no, LogLevel QUIET, HISTFILE=/dev/null. A key that logs in with that configuration in place leaves exactly the trace we see here, an accepted login and an empty file.

So, it stands to reason, the key worked silently because Ebury was already inside sshd on Switzerland2 when the key arrived. The flow of events in UTC:

The install they can see came one second after the login. The login needed trust that was already in place, so whatever granted it was there first. On the backdoor reading, the sudo at 04:38:01 was a reinstall onto a host the attacker already owned, run with the operator’s sudo password because they had it.

The operators themselves seem to arrive here as well. They give two possibilities, a line in the main sshd_config or an earlier backdoor, and then report that the main sshd_config came from the hosting provider’s VPS image and that the attacker replaced it on 30 September. Both of their possibilities say trust was established on Switzerland2 before 28 August, by someone other than the operators.

The hosting layer is where Ebury has lived for a decade, and in this case it has a name. Switzerland2 was a FranTech VPS. An analysis of public directory data posted to tor-relays counts the relays of the 58 other affected operators: 71 of 101 on FranTech switched to the attacker’s policy, against 13 of 9,054 hosted everywhere else, and each of those operators had their affected relays all on FranTech or all off it. Kaba counted 26 of the 27 compromised servers outside the Quetzalcoatl family at FranTech and asked the list whether they were compromised at the hoster level. ESET’s May 2024 paper documents hosting providers whose infrastructure was compromised so that Ebury landed on the servers they rented out. ESET rented one and had Ebury within seven days. One provider lost 70,000 servers in 2023. Tor exit nodes are on ESET’s victim list.

Kaba, who found the 333 exits by scanning every exit with exitmap, names the hosting company as the open theory.

Marc-Etienne Léveillé, who investigated Ebury at ESET for more than a decade before leaving the company, told the list that version 1.8.3 has circulated since at least June 2026, that ESET has seen providers whose management servers ran Ebury and whose customers’ virtual servers ended up infected, and that with 400,000 servers compromised since 2009 there are most likely other compromised relays still running.

Every check the operators ran on the host passed. dpkg -V passed because the packaged library stays intact and only a symlink moves. ldd on sshd passed because the implant loads through libkrb5 into sshd-session. A shell reported a clean /proc/self/maps because the implant hides from the processes it lives in. One of their review passes declared the server clean on those results. The true findings came from outside the host: the public CollecTor archive showed the exit policy had changed, process memory showed the implant, and the Tor network health team saw the policy change in the directory data before the operators saw anything on their own machines.

The password reuse is the stated root cause. It explains 03:19 and it explains 04:38:01. It has nothing to do with 04:38:00. That second belongs to a backdoor that predates the password, and the burning question now is who put it there.