Anatomy of a Very Expensive Typo: Inside the Leaked Key That Nearly Sank a Manchester Startup
Photo: Software: KDE developers Wallpaper: KDE developers Screenshot: Nate Graham, GPL, via Wikimedia Commons
It started, as these things always do, with a deadline. A small Manchester fintech startup — we'll call them Northern Ledger — was three days from a client demo. A developer needed to test a document-scanning API, so they did what most of us have done at least once: they pasted the key straight into a config file, committed it, and pushed.
The repo was public. It was public for eleven hours.
By the time anyone noticed, the cloud provider's billing dashboard showed charges approaching £4,000 — crypto mining workloads spun up in a region nobody on the team had ever touched. Hence the nickname the team now uses internally: the £4 API key. Technically it cost a lot more than four quid. But the first thing the attackers did with that key was provision exactly four GPU instances, and the number stuck.
Eleven Hours: How the Leak Actually Unfolded
The timeline matters, because it shows how little time you have once a secret is exposed.
Hour zero. The commit lands at 6:40pm on a Friday. Classic. The developer had been fighting the company's secrets manager integration, fell back to a hardcoded string "just to test", and never went back to clean up.
Hour one. Automated scrapers — and there are many, running continuously — pick up the new commit. Bots crawl public repos looking for key patterns: AWS-style access tokens, Google API keys, anything with sk- prefixes. This isn't sophisticated. It's a solved problem, which is exactly why it happens so fast.
Hour two. The key is validated against the provider's API. It works. The attackers enumerate permissions: can it spin up compute? Can it create new keys? Can it delete logs? Northern Ledger's key could do all three.
Hour three onwards. Compute gets provisioned. Not enough to trigger obvious alerts, but enough to generate serious money by Monday morning.
Monday, 9:15am. A billing alert — set at £100, more as a formality than a tripwire — finally fires. By then the damage is done.
Catching the Culprits (Sort Of)
Here's the unsatisfying truth: they never caught anyone. The cloud provider's logs showed activity from IP ranges associated with commercial VPN services. The workloads were mining cryptocurrency for wallets that will never be traced. The startup's account manager offered sympathy and, eventually, a partial goodwill credit — but the provider's terms were clear. Keys in a public repo are the customer's problem.
What the forensics did reveal was instructive. The attackers hadn't just used the key — they'd used it politely. Small instance types first, ramping up gradually, presumably to stay under radar thresholds. They also attempted to disable the audit logging twice. If the team hadn't had billing alerts, the compromise could have run for weeks instead of a weekend.
The Checklist That Would Have Prevented All of This
Northern Ledger's post-mortem produced a list that any UK team can implement this week, mostly for free.
1. Turn on secret scanning — today. GitHub offers it free on public repos and cheaply on private ones. GitLab has equivalent tooling. There is no excuse for a team of any size not having this running. It would have flagged that Friday evening commit within minutes.
2. Add a pre-commit hook that actually blocks. Tools like gitleaks or trufflehog can scan staged changes before anything leaves your machine. The key word is blocks — a warning nobody reads is worth nothing at 6:40pm on a Friday.
3. Move secrets out of code entirely. Use a proper secrets manager, or at minimum environment variables loaded from files that are gitignored. Better yet, use short-lived credentials that expire in hours, so a leaked key is a dead key before the scrapers even finish their coffee.
4. Set billing alerts that mean it. A £100 threshold on an account that normally spends £30 a month is a real tripwire. Make sure alerts email more than one person.
5. Scope your keys narrowly. The attackers could create compute and delete logs because the key had admin-level permissions. Least privilege is boring advice that saves thousands of pounds.
6. Know how to scrub git history before you need to. Rotating the key isn't enough if you want it gone — tools like git filter-repo can rewrite history, though honestly, rotation plus provider-side revocation does 95% of the job. Rotating first is the critical step; don't spend an hour cleaning history while the key is still live.
The Bit Nobody Talks About
The financial hit hurt. What hurt more, the founder admits, was the demo. The client's due diligence questionnaire suddenly had an awkward answer in it, and the funding conversations that autumn included a question about security posture that hadn't been there before.
That's the real cost of a leaked secret. Not the £4,000 on the invoice — painful, but survivable. It's the year spent proving to everyone else that it won't happen again.
Eleven hours of exposure. One Friday evening. One hardcoded string. Every single control that would have stopped it is free and takes less than a day to set up. If your repo doesn't have secret scanning right now, close this tab and go turn it on. The bots certainly aren't taking the weekend off.