So Wednesday night I'm trying to push a tiny CSS fix, nothing dramatic, and git push just... sits there. No error, no timeout, just a blinking cursor for a solid two minutes before it finally goes through. I figured it was my crummy apartment wifi again (still havent forgiven Comcast for that install appointment that took three separate visits back in January) but then Thursday morning the whole site is doing it. Clone times through the floor, pull requests not loading, the works.
Turns out it wasnt me. GitHub has been getting hammered by what a lot of people are calling the biggest DDoS attack in the site's history, and it started ramping up right around Thursday the 26th. Their status page has been lit up red on and off for days now.
Heres the part thats actually interesting and not just "big website has a bad week." The traffic isnt hitting GitHub broadly, its aimed at two specific repos: mirrors of GreatFire.org and a Chinese-language version of the New York Times, both of which exist to help people route around the Great Firewall. And the traffic itself is bizarre, its coming from ordinary browsers all over the world that got a little bit of malicious JavaScript slipped into ad requests, apparently through Baidu's analytics script, and that JS quietly makes each browser hammer those two GitHub URLs over and over in the background. So if youve loaded some random Chinese website this week with an ad on it, theres a decent chance your laptop was part of a botnet without you doing anything at all. Thats the kind of detail that makes my skin crawl a little, honestly, way more than the outage itself did.
I dont know who exactly is behind it and I dont think anyone outside a few networking researchers does yet, but the pattern (a government-adjacent actor recycling normal web traffic as attack traffic against anti-censorship tools) is not subtle. People are already speculating this is a new tool entirely, not just a bigger version of the usual Great Firewall stuff, since the Firewall normally blocks things rather than actively weaponizing outside traffic like this.
What I keep coming back to, sitting here annoyed about my CSS fix, is how much of my actual job runs through one company's servers now. Not just my own repos, though thats bad enough, but half the build tooling I use pulls dependencies straight off GitHub at deploy time. A shell script here, a gem sourced from a repo instead of a gem server there. When GitHub sneezes, apparently three or four of my client projects catch a cold, and I had genuinely never thought about that as a single point of failure until this week forced the issue. Its convenient right up until it isnt.
Credit where its due, GitHub's ops team has apparently been fighting this thing nonstop and keeping the core service up even while specific pages get buried, which is not a small feat when youre absorbing traffic from what's effectively an accidental botnet of regular internet users who have no idea theyre involved. I dont envy whoever got paged for this at 3am.
Anyway. My CSS fix eventually shipped. Twenty minutes for one small push is nothing in the scheme of things, and I know that, but it's a good reminder that the plumbing under most of our daily dev workflow is a lot more fragile, and a lot more politically entangled, than the little green commit squares let on. Worth keeping an eye on where this goes over the next week, because if this really is a new attack technique and not a one-off, it's not going to stay pointed at just two repositories.