Security is speeding up

Binance lost $6.3 billion, a backdoored Claude Code extension went out to developers, and Polymarket was drained through someone else's monitoring script. That was just the last 48 hours.

Insane.

Here's the full list:

• Binance lost $6.3 billion. It's the largest crypto theft on record, about four times the size of the Bybit hack from last year. Most of it left in about 20 minutes.
• The Claude Code extension in Cursor's marketplace was backdoored. Someone published a tampered build under the official extension ID. It added an attacker's SSH key to the machine and set up persistence. It was live for about 11 hours and reached up to 5,000 developers. These are developers, so their laptops have production credentials on them.
• Polymarket got drained through somebody else's script. Attackers compromised DebugBear, a website performance monitoring service. Its monitoring snippet started serving malicious JavaScript that used logged-in users' sessions to move funds. Over $2 million was taken. DebugBear has asked all of its customers to remove the snippet while it investigates.
• Hetzner warned customers about a UEFI firmware flaw (CVSS 9.5, 16 years old) in the network boot code that runs before the operating system, and before Secure Boot can do anything about it. It affects their dedicated servers and UEFI cloud VMs.
• A maximum-severity GitLab flaw is being exploited in the wild, according to CISA. Federal agencies got a few days to fix it.

Meanwhile, in the Linux kernel, a TCP bug was quietly re-scored from 5.9 to 9.8, which means unauthenticated remote code execution. As of Thursday, Ubuntu and RHEL still hadn't shipped patched kernels. There's also a 9.3 bug that lets a guest VM read host memory, and a local root bug that CISA says attackers are actively exploiting.

The week before that, two critical PHP flaws dubbed "PHP2Shell" allowed unauthenticated remote code execution on basically any server running PHP 5.4 or newer. Governments didn't wait to find out whether they'd been hit. Finland, the Dutch parliament, the Dutch data protection regulator and parts of the Canadian government took their websites offline until they could patch. Around the same time, a backdoored release of LiteLLM (a popular AI gateway library) appeared on PyPI. Japan Airlines and ANA disclosed passenger data leaks, both through Amadeus, a vendor they share.

That's one freaking week.

Honestly, I need a drink.

Falling into a black hole

The closer something gets to a black hole, the faster it falls. Gravity gets stronger with every meter, so the acceleration keeps increasing. That's what the security world feels like right now.

It's speeding up in both directions. The PHP2Shell bugs were found by independent researchers using AI tools. The same tools help attackers turn a fresh CVE into a working exploit in hours instead of weeks. Defenders are using AI too, to audit code, find bugs before release and patch faster. Both sides are accelerating, and the time between "vulnerability published" and "vulnerability exploited" keeps shrinking.

Look at the list again: most of those incidents didn't start with the victim's own code. They started with an extension, a monitoring snippet, a firmware driver, a library or a vendor's booking system. The victim simply trusted something, and that something got compromised.

We run a helpdesk, and our customers keep a lot of sensitive stuff in it: employee issues, customer data, passwords people really shouldn't be emailing but do anyway. So here's what we're changing.

What we're doing at Jitbit

1. Removing third-party dependencies and subprocessors. No exceptions.

The Polymarket attack came from an innocent performance monitoring script. Nothing was wrong with Polymarket's own code. They had simply loaded JavaScript from someone else's server onto their pages, and that someone got hacked.

So we're cutting every third-party service we can live without. No more JavaScript error monitoring. Analytics cut down to the bare minimum. If code runs inside your browser session while you're logged into your helpdesk, we want to have written it and to serve it from our own servers. The same goes for subprocessors on the backend: every vendor that touches customer data is one more company whose security we'd have to trust, and we're shrinking that list.

Yes, this means giving up some convenience. Error monitoring services are genuinely useful. But "useful" isn't a good enough reason to give a stranger's script access to your support tickets.

CORS, CSP, sha-256 hashes for scripts, all the "nice to haves" you've been putting off - are now critical.

2. Patching and monitoring

This sounds obvious, and it is. What has changed is how fast we have to do it. A month ago, "patch within a week" was a reasonable policy. Now exploits can show up before the advisory has finished making the rounds. So we watch the advisories ourselves instead of waiting for a monthly maintenance window, and we patch as soon as fixes come out.

3. AI agents that keep attacking our own app

If attackers use AI to find holes, we'd better find them first. We run AI agents in a loop that scans the Jitbit codebase and the running app for security problems, over and over again. They don't get bored, and they don't decide that some code is "probably fine" because it hasn't changed in years. Whenever they find something, we fix it, and the loop starts again.

4. Removing anything we don't need

Every package, library, server component and open-source tool we have installed is a potential CVE waiting to happen. Look at the UEFI bug: it lived in a PXE network boot driver for 16 years, and most servers never PXE-boot at all.

So we're going through all of it: server software, OS packages, dependencies, OSS components. If we can't explain why something is there, it goes. Code that doesn't exist can't be exploited.

5. Blocking everything at the firewall

Our firewalls start from "deny all", and we only open what absolutely has to be reachable. If a port doesn't need to be open, it's closed. If a service only talks to one other machine, only that machine can reach it. It's boring, and it means a lot of bugs never get the chance to be exploited, because the attacker can't reach the vulnerable code in the first place.

6. CrowdSec in front of everything

We use CrowdSec to block IP addresses with a bad reputation before they even reach our servers. It's crowdsourced: when an IP starts scanning or brute-forcing someone else's servers, it gets flagged, and everyone in the network blocks it. Most of the automated garbage that hits the internet every day (exploit scanners, credential stuffing, bots probing for the latest PHP bug) never gets to us.

The honest part

Our whole team now spends more time on devops than on coding. That's not how we'd like it to be. We'd rather be shipping features. But we've looked at this week's news, and we don't think we have a choice. We've shipped more security fixes in the last week than we have in the last 6 months.

And it will keep speeding up.

Stay safe out there.