Two weeks, three control-plane breaches

The sharp incident of this fortnight is the PingCAP breach, which has its own post. The reason it deserves company is that the same two weeks produced two more intrusions with the same shape: the host's control plane failed, not a crashed database. Lay all three on the table and the pattern becomes harder to call bad luck.

Railway, October 20 to 22

Railway's incident is the build-system kind. An attacker got into the platform's build systems and decrypted a subset of customer environment variables. The preliminary report puts the blast radius at no more than 1.85% of workspaces, with a caveat nobody should skim past: because of envelope encryption, Railway cannot say exactly which keys were taken, which converts every customer secrets store from "probably fine" to "prove it, and prove it on your own."

The practical response was the only sensible one. Everyone who signed up before October 21 got told to rotate the secrets they had stored there. Deploys were paused while running applications kept running. As of October 29, new signups were still paused, which is a platform making the responsible-but-expensive call in public. We covered the details, including the rotation instructions, over on the Layerbase blog.

Zeabur, October 14 and 15, then a shutdown

Zeabur is an app host rather than a database company, which is exactly why it belongs in this list. The attacker ran commands inside customer database containers.

Zeabur's own report reads like an already-won argument for basics. Long-lived administrative credentials were stored in plaintext and reachable from the public internet, including a token minted in January 2024 and never rotated even after an earlier breach in August. From that foothold, the attacker read 3,218,965 environment-variable records and 321,810 accounts, signed in as root on 101 Google Cloud servers, and ran commands in 865 database services.

Then the part with a clock on it: Zeabur is closing. Shared clusters pause on December 1 and everything stops on December 31. For its customers the breach and the migration deadline are the same event, and the calendar does not care which one motivated you.

The pattern that makes three a trend

One host's incident is an incident. Three hosts' incidents in two weeks, with the same anatomy, are a category: the database "fine", control planes leaking keys, query history, environment variables, and account records on top.

The noisy week Supabase had (short log delays, management-API errors, and the management-grant change on October 30, which we covered over on the Layerbase blog) is real, but it belongs in a different league: an availability and disclosures story, not a demonstrated intrusion. Padding it into this list would inflate it and deflate the three above.

The takeaway worth repeating at your next architecture review, then: when you size a host's risk, audit the account layer with the same suspicion you give the storage layer. Where do the keys live, who can read the query history, what happened to the tokens minted in 2024? An outage tells you the whole story within minutes, and a control-plane breach says nothing until it has already said everything.

From the desk that wrote this

This blog is run by the team behind Layerbase, so every post comes with a conflict of interest attached rather than concealed behind it.