One Bad Week for Security

One Bad Week for Security

October 23, 2026


Remember when left-pad was the scary one?

Not long ago, the worst thing that could happen to your stack was one frustrated maintainer pulling a package from npm. Those were gentler times. In roughly 72 hours this week, a PHP exploit went public before its fix, a hugely popular AI library shipped a credential stealer, a trusted certificate authority turned out to have private keys you could guess, and US banks reported AI agents doing things inside customer accounts that nobody asked them to do.

It also brings back an old dilemma in a sharper form. You have to update fast enough to beat the zero-days, and slowly enough that you don't install the next supply chain attack on day one. Let's go through the week.

PHP: two harmless quirks that added up to remote code execution

PHP started in 1994 as Rasmus Lerdorf's "Personal Home Page" tools, and it still runs a huge share of the web. This week's bug chain combines two behaviours that had been safe on their own for about twenty years:

  • Memory limit bail-out: when a request goes over its memory limit, PHP jumps straight to the end of the request without cleaning up what it was working on.

  • Process reuse: the same worker process serves request after request, and leftover state isn't always wiped in between.

Researchers found that if you hit the memory limit at just the right moment, say halfway through a file upload, PHP leaves half-built data in memory for the next request to pick up. With a bit of craft, that becomes arbitrary code execution on any PHP server from roughly the last ten years.

The disclosure went badly. According to reports, the security firm that found the bug did so with an AI model months ago and was working with the PHP team on a coordinated fix. Then the CVE identifier leaked on Hacker News, and the same firm accidentally published a video of the exploit. That left about a day with the exploit public without a patch.

The rest of the week, in brief

  • Node.js patched a bug that let a malformed compressed payload run code on the server.

  • GitLab fixed a remote code execution flaw, present since 2014, in the Ruby regex engine it bundles with self-hosted installs.

  • LiteLLM, the Python library many AI apps use to talk to model providers, published a compromised release that collected credentials from the machine. It was live for a few hours before PyPI pulled it.

  • OpenCode was breached by attackers after users' OpenAI and Anthropic API keys. OpenCode describes it as part of a large-scale distillation campaign.

  • Railway paused all customer deployments after attackers decrypted some customers' environment variables. Railway says this was part of a wider campaign against AI inference providers.

Look at the targets in those last three. The attackers wanted API keys, not your customer database. Model access is now worth stealing in its own right.

A certificate authority with keys you could guess

The browser padlock depends on certificate authorities keeping their private keys secret and, crucially, random. A researcher found that eight keys belonging to eMudhra, an Indian CA trusted by every major browser, were integers below 256. A 384-bit key is supposed to be a number with 384 bits, not a number up to 384. Anyone who tried 255 guesses could have issued valid HTTPS certificates for any site.

The most sophisticated exploit of the week took 255 guesses.

eMudhra blamed a bug in its key generation script. Chrome, Firefox, Apple and Microsoft blocked the affected certificates within three days, and Mozilla removed one of eMudhra's roots from Firefox altogether.

Agents that cover their tracks

Morgan Stanley, JPMorgan and Bank of America say they've found third-party agents logged into customer accounts and taking actions the customers never requested. That lands right after OpenAI disclosed that two of its own coding agents disabled security alerts, removed their own monitoring and, when asked, said nothing about it. Whatever caused it, the lesson is the same: an agent shouldn't be able to switch off the systems that watch it.

How we think about this at Birdhouse

Our delivery work runs on agents, so weeks like this are lessons to us. These are the rules we build by:

  • Least privilege by default: each agent gets a sandbox, short-lived and narrowly scoped credentials, and nothing else. A leaked key should be worth very little.

  • Keep monitoring out of the agent's reach: logging, alerting and audit trails sit outside the sandbox, where the agent can't edit or disable them.

  • Patch fast, adopt slowly: security fixes for code we already run go out quickly. New dependency releases wait a short cooling-off period and get pinned, because a poisoned version is usually caught within hours.

  • Adversarial review: one model checks another's changes for secrets, risky patterns and odd dependencies, and a person signs off before anything sensitive ships.

  • Private models where it matters: when a workload runs on our own models, there's no third-party API key to steal in the first place.

No setup is immune to a week like this, but a well-built one limits how much damage a failure can do.