Is this the new cyber normal?

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? The bugs 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. PHP2Shell – CVE-2026-109618 and CVE-2026-109619 (a.k.a. “the big one in the news”) 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. Links: Hacker News: “Tell HN: 2x PHP RCE CVEs with CVSS 10.0 Incoming” (petecooper, 20 Oct 2026) PHP2Shell – official website – why does every vulnerability need a name, slogan, and website now? Wiz Research: “PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet” – these are one of the companies who found the bugs. PHP News Archive: “Upcoming Critical PHP Security Release” (20 Oct 2026) – how The PHP Group announced the vulnerability. Note the timelines. Wikipedia: PHP2Shell – not too detailed but at least they’re not trying to sell you anything. AWS Security Blog: “Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot” – they are trying to sell you something, but they’re still doing some interesting analysis. eMudhra (CVE-2026-111943 for Golang response) 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: Alt: RFC 1149.5 specifies 4 as the standard IEEE-vetted random number. From xkcd #221, licensed under CC BY-NC 2.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. Links: Mozilla Security Blog: “Protecting Firefox users following the compromise of eMudhra intermediate certificates” Scott Helme: “Eight Bits of Trust; eMudhra’s CA keys cracked in milliseconds” eMudhra press release: “eMudhra to Exit global SSL/TLS Certificate Business” eMudhra Intermediate CA Compromise – research announcement and trust store checker Railway bug 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). Links: Railway Blog: “Security Disclosure: Wednesday October 21st” Hacker News discussion of the Railway security disclosure GitLab (CVE-2026-97229 and CVE-2026-110264) 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.