Is this the new cyber normal?

0

23 October 2026 · 23 min read ·

Is this the new cyber normal?

#security#llms · Discuss on Lobsters Y Combinator

The last week has seen a flurry of severe and critical software vulnerabilities affecting thousands of major sites and sending people into a panic. What’s going on here, and what can we do about it?

If we want to understand what’s going on in the world of software security at the moment, we need to understand what’s going on with all these bugs. I’m not a cybersecurity expert, so I’m going to link to external explanations instead of going into the gory technical details myself as these people are always going to do a better job at that.

Two different security teams, one from California security company Calif (as part of OpenAI’s “Patch the Planet” program) and another from Israeli-U.S. cloud security company Wiz (they’re part of Google Cloud, apparently), both found these two Remote Code Execution (RCE) bugs in PHP. They were both using frontier AI models (a.k.a. LLMs, specifically GPT-5.6 Sol/Gemini 4 Argon) to find these vulnerabilities and build the exploits.

Interestingly, one of the bugs (CVE-2026-109618) was found by a security audit the PHP Foundation did in 2024 (funded by the Sovereign Tech Agency which is coincidentally one of the most interesting things happening in the open source space at the moment) but they basically ignored it because they had bigger concerns and couldn’t agree on a fix. The reasoning behind it was that no-one could really figure out how to create an actual exploit based on the theoretical issue.

One thing LLMs are very good at is taking a theoretical security vulnerability, even if that vulnerability is a vague description of what the issue could be, and building it into a full exploit. This has become a major issue in recent months as any notice of a security patch will immediately result in people pointing their LLMs at the codebase, whereupon the agents can very quickly read through diffs until they find something that looks like a security patch, then go backwards to the vulnerability it covers, and follow this all the way to an exploit.

This happens so fast, in fact, that at this point I think it is a reasonable that the moment you announce a security patch should be taken as a last possible date that the full exploit is not being publicly or privately distributed.

This PHP2Shell (as it’s being marketed, vulnerabilities seem to come bundled with their own marketing departments now) is estimated to affect upwards of 70% of the internet, with thousands of websites from Wikimedia Foundation to DeviantArt to much of the UK government and Japanese banking systems to The Traitors BBC programme website. Vulnerabilities do get found, but they don’t normally cause half the internet to shut their servers down, so what’s going on?

To understand this, let’s look at the original post from the PHP Group:

Someone called petecooper posted on Hacker News about the CVEs, apparently unaware that there even was an embargo. This (and other apparent leaks) prompted this hurried statement from the PHP Group and bringing the patch forward from Thursday 22nd to Wednesday 21st. However, the patch still wasn’t going to be available till the next day. This unintentional leak included CVSS scores of 10.0 (i.e. bad, although weirdly the actual scores were 9.2 instead).

Pretty much immediately, this news spread like wildfire and people started panicking. Even though this was found by “responsible security researchers” at “respectable companies”, by the time the security patch actually got released, it was already being exploited in the wild1. The PHP Foundation blamed Calif and a company called Chainguard by saying that Calif leaked a video of the exploit in action (with weird background music and a dancing anime girl) while Chainguard published fixes 6 hours before the embargo was due to lift, both allowing attackers to beat the systems administrators to the punch. The timeline is confusing, but it seems like multiple interconnected things have gone wrong here, all within the space of about 17 hours.

There’s been lots of discussion about whether AI really is the game changer that completely revolutionises computer security or not. The big AI companies (and they are big) obviously want you to think that it is. Some people argue that PHP2Shell is overblown because LLMs tend to be paranoid about vulnerabilities and come up with “exploits” that make bad assumptions (like that the server will run PHP code you upload yourself via some existing file inclusion vulnerability) or cheat in some way. As LiveOverflow points out, LLMs make it very easy to create exploit slop that proves nothing and doesn’t work, but that doesn’t mean that the vulnerability isn’t real and easy to exploit using AI. You can have 10,000 bad slop exploits that don’t work but if there’s one that does, that’s all that matters. Maybe we just need to get used to wading through slop to find the important stuff now.

Others point out that lots of governments (UK2, EU, Japan, USA) got overexcited and released urgent announcements saying everyone had to unplug their computers immediately, so people panicked. I think the reason everyone panicked is that everyone kind of knows that PHP is intensely insecure and they use it anyway, so they’re kind of primed for bad news and to overreact. Also, it actually is really quite bad, so maybe panicking is kind of the correct reaction?

The big takeaway for me from this is that – because of LLMs – the time from “hey I heard there’s a bad RCE in this project” to “there are sophisticated, automated, and concerted attacks using an exploit targeting this vulnerability” has gone from weeks/months to hours/minutes. The fact that there’s loads of non-working exploit slop just shows how genuine expertise is still required to make these things – if you don’t know what you’re looking at, you can’t tell whether the AI has cheated or made bad assumptions.

On the exact same day (20th October 2026), Mozilla announced that they were blocking 8 intermediate certificates signed by Indian certificate authority eMudhra. This happened after a pseudonymous security researcher known only as “Wayne” reported to several big tech firms (such as Mozilla, Apple, Google, Microsoft, etc.) that the certificate authority were using laughably poor quality private keys for their intermediate certificates. Where a secure key might be a 100 digit number, eMudhra were using keys like “115”, “56”, and “4”. They must’ve been following RFC 1149.5:

There are no indications that this was found or exploited using AI or LLMs, although researcher Scott Helme notes that given a single prompt, Claude was able to recover the private keys of the intermediate certs.

At the time of writing (23rd Oct), eMudhra has announced that it will be retiring from the certificate authority space. In unrelated news, a farmer has announced that he has shut his stable door, following reports of an escaped horse.

The next day, cloud provider Railway announced that they found evidence that hackers had accessed and even decrypted environment variables from their platform, which often hold secrets such as database credentials, API keys, etc. In their statement, they said that they believed that this was part of a concerted effort aimed at compromising companies that provide AI inference.

What would the end goal be here? At the time of writing (23rd Oct), we have very little information to go on. Is this “unauthorized third party” (official announcements of “some randos got into our computers” always find a way to make it seem like a terms of service agreement, maybe that way they think people won’t pay attention to it) trying to spy on people using AI inference to see what they’re doing, even stealing new models or research? Or maybe they’re trying to build a network of compromised inference providers for their own nefarious generative AI purposes (like finding more PHP bugs).

On 12th October 2026, GitLab warned of a max severity bug in GitLab CI/CD’s regular expression parsing that could enable attackers to execute arbitrary code (another RCE) using a specially crafted regex. This is a CVSS score of 10.0 which is the maximum possible, meaning “this is pretty much as bad as they come”3. This was followed on 21st October 2026 by yet another regex integer overflow RCE, another 10.0.

This follows hot on the heels of yet another 10.0 CVSS CVE from last month (CVE-2026-85706), that time related to path traversal. All three of these bugs were reported through GitLab’s HackerOne bug bounty program. When it became clear that LLMs could research vulnerabilities and write exploits, there was a lot of talk about shutting down bug bounty programs because they didn’t make sense anymore. I’m sure GitLab are glad they didn’t do that now.

Although GitLab is used very widely across academia, government, and private companies, this doesn’t seem to have got as much attention. CVEs in GitLab are obviously very serious, especially for private companies, as a lot of their vitally important intellectual property is stored in there, and having that leak could be disastrous. Often, companies put their GitLab instance behind a VPN/firewall so that they aren’t publicly accessible, which greatly reduces the risk associated with this. It’s also not entirely clear whether these CVEs require specific conditions like publicly accessible projects, user self-registration, etc. It does seem like CVE-2026-110264 requires at least one public project, but I can’t find any information on the conditions around the earlier CVE.

There’s no indication that these were discovered using AI or LLMs. They may have been, but there’s no reason at this point to think they were.

On 21st October, a bug in musl’s libc related to regex (libc has regex? Apparently…) was announced that leads to denial of service at least, if not code execution. As far as I can tell, this is entirely coincidental in timing and not related to the GitLab bugs, which both also seem to be integer overflows when parsing untrusted regular expressions, one reported on the exact same day. Who knew a regex engine was such a security issue – is regex the new font rendering? The GitLab bugs were both found by a Swede called Johan Carlsson (joaxcar) while the musl bug was reported by Julien Voisin, a French self-proclaimed “open sourcerer”.

Ah, hello my old friend LiteLLM. Proving that, when you’re made of metal and 200 feet tall, lightning can in fact strike twice. It’s not a good sign that when someone asks whether you’ve heard of the big 2026 LiteLLM compromise, you have to ask “which one?” In a piece of good fortune, the whole PHP2Shell and all the others have cannibalised much of the attention, meaning this isn’t getting quite the same traction as last time in March, despite being similarly bad.

This time, it’s a malicious version on the Python Package Index (PyPI) and Docker images. For those who don’t remember, LiteLLM had a very similar thing happen back in March, where a malicious package was uploaded to the litellm package on PyPI that used the .pth files to autoload malicious code (yeah, it was bad).

This compromise again took advantage of .pth files and this time also the sitecutomize.py file for autoloading malicious payloads, running in the preload step as soon as the Python interpreter starts up. According to the analysis from Wiz, the payload has “strong indications of LLM-aided development” – things like overly verbose variable names, overly defensive error handling, brittle edge cases, and all the comments saying “this is where it really bites”, “it’s worth sitting with that”, “lean into that”, and “that stays yours” repeatedly4.

According to LiteLLM, the incident occurred because the attacker had access to credentials for GitHub CLI which allowed them to run CI jobs. LiteLLM note that Claude Code will apparently sometimes embed a user’s GitHub CLI OA