I would be very surprised if you didn’t hear about any of the security vulnerabilities that were disclosed last week. There were several high profile bugs that could lead to Remote Code Execution (RCE). The vulnerabilities for PHP were so widespread that governmental bodies were advising website owners to take their sites offline until they can implement the latest patches when they became available. Brotli’s core implementation had a vulnerability which crosses programming language boundaries. And LiteLLM had a supply chain compromise that shipped multiple malicious packages to PyPi. My content creator friends were eating well last week, figuratively.

The ElePHPant in the Room

The most prominent CVEs last week were the PHP ones. They have been present since PHP 5.4 which was released in 2012. This is especially troubling since it’s said that ~70% of the internet runs on some version of PHP. To put that in perspective, Censys has this microsite that reports ~42 million PHP installations that were vulnerable at the time of disclosure. Since then, ~10 million have been patched, but that leaves a large portion of the internet still vulnerable to these two CVEs.

The interesting part here isn’t that an RCE was found. It’s that these vulnerabilities are buried deep within the internals of PHP and are exploitable before any application code even runs. They sit in places that pen testers often would overlook.

Additionally, what makes this even more interesting is the combination of the size of the blast radius of these issues and a critical breach of what is called an embargo. When security researchers discover such critical issues, they disclose them in private to give maintainers a chance to create the necessary patches for version of the software that are still within maintenance windows. That is done so that when the public is notified of a problem, they can patch things as quickly as possible. Since PHP runs in places like government agency websites and apps, there was a large chance for an attacker to gain access to very sensitive information. This caused some government officials to recommend taking websites down entirely to prevent wide scale attacks.

To .br or Not to .br

Maybe this heading is a bit confusing, but for those unaware, the commonly accepted file extension for brotli-compressed files is .br. For the even more unaware, Brotli is a Google-created compression algorithm in the same vein as Gzip. Brotli can compress text payloads by about 15% to 25% more than Gzip and allows clients to decompress faster by up to 64% in some cases.

The vulnerability was found in the core C library that Google publishes. That core is used by almost every Brotli implementation in most popular programming languages, including:

• Node.js
• Python (brotli and brotlicffi packages)
• Bun
• .NET
• Envoy Proxy & Istio
• Java (brotli4j)
• Other tools/services such as ClickHouse, FFmpeg (via JPEG XL), and Apache Arrow

Note: The rust implementation (rust-brotli) open sourced by Dropbox is safe.

The root cause is an improper bounds check that “causes an out-of-bounds write when processing a specially crafted, compressed Brotli stream.” This sounds bad, but luckily there haven’t been any known exploits of this vulnerability in the wild. While it has been proven in a lab setting, the public proofs of concept have been limited to denial-of-service (DOS) crashes on standard deployments but full code execution has only been reproduced on intentionally weakened systems.

The thing I find most interesting is how the issues was originally labelled “Node2Shell” even though it is applicable to many more environments than just Node.js. This could probably be attributed to the amount of libraries in the Node.js ecosystem that are vulnerable by proxy like Express.js, Koa, Fastify, and core Node libraries like fetch and node:zlib. But, as many have pointed out, a better name is probably something like HTTP2Shell or Broccoli2Shell.

LiteLLM Supply Chain Compromise

The LiteLLM compromise is an interesting one. But first, we should point out what LiteLLM even is. It’s an AI Gateway and LLM Proxy that you can host and maintain similar to OpenRouter’s cloud offering. This is especially attractive for organizations that want to give their devs access to a wide range of AI models without giving up control of that routing to a third party. Companies making use of LiteLLM include Okta, IBM, Nvidia, and many other massive corporations. That should help you understand how important this supply chain attack was. The malicious packages could have potentially had access to enormous amounts of sensitive information.

The original compromise was through a thing called Trivy which is a security scanner that was used by LiteLLM internally at their organization. TeamPCP, the attackers that compromised Trivy at LiteLLM, then published several malicious packages to the Python package repository PyPi under the LiteLLM org. Once they packages were installed at the consuming enterprises, they ran a post-install script that scraped for environment variables, cloud credentials (AWS, GCP, Azure), SSH keys, Kubernetes configs, and LLM API keys which then got encrypted and shipped to a remote server controlled by the attackers. While there aren’t any hard numbers, it was reported that the attackers immediately began using the stolen LLM API keys and were able to run unabated for 4.5 hours. At Anthropic API prices, that usage could easily bankrupt most individuals.

The Wild Frontier

Many content creators have made excellent videos about these incidents and you should probably go watch them. This one by Theo sums up a lot of it in a clean way.

But, it makes me think about a conversation a group of us “and Theo” had during one of the nights after CascadiaJS just earlier this year. I’m pretty sure he has even made a video about it but I was too lazy to try and track it down. He expressed genuine concern about the changing landscape around how easy it is to turn AI agents loose on watching patches to various open source repos and determining if they are preemptive patches to vulnerabilities before they get disclosed publicly. This is something attackers have been doing for ages, but now you can automate so many more repos being watched that no repo is safe. This is largely why the cal.com team made their repos closed-source. They weren’t confident in their ability to patch their vulnerabilities in time before they might leak sensitive customer data. Even though they aren’t in as many privileged environments like PHP, Brotli, and LiteLLM, they are still subject to the risk of leaking things that could kill their reputaion as a company. And, at this point reputation is becoming a crucial moat for some organizations.

But, there is a silver lining. If it’s trivial to turn an agent loose on watching for security related patches for evil, it’s also pretty easy to do so for good. In fact, it may be easier for blue teams because the frontier models have such strong security guardrails on their consumer level offerings while the more security-capable models are kept behind heavily vetted private offerings like Project Glasswing, Daybreak Blue, and the Fairwind Program.

The New Normal

Consumer-level models are still useful as evidenced by a levels.io tweet. I don’t always agree with a lot of his tech opinions, but this is a good one.

Luckily for us I think the attack and defense capabilities of AI models seems to somewhat match? So as long as we keep typing “do a security audit” regularly into our clanker we can keep it safe

I think there is a lot of doom and gloom out there. Maybe some of it is a bit of “the sky is falling”. But, in general, I feel like this isn’t the end of security on the web. It’s simply a new way that the security arms race is proliferating. As long as we update our practices to meet the attackers head on, we can get the same level of “best effort” security that we’ve had all along, since nothing is ever truly secure. At least until Quantum Computing changes cryptography as we know it…