GitHub: "We are investigating unauthorized access to GitHub’s internal repositories. While we currently have no evidence of impact to customer information stored outside of GitHub’s internal repositories (such as our customers’ enterprises, organizations, and repositories), we are closely monitoring our infrastructure for follow-on activity."
This reminds me of George Carlin standup routine about PTSD. If you want to make any bad news sound less bad, just wrap the concept around complicated jargon to sterilize it.
It's certainly not the right platform. It'd be one thing if they had any official communication on the matter anywhere else. Maybe they're ashamed and are trying to limit the visibility while only technically issuing an announcement.
They announced this exclusively on X.com, which ranks barely above Pinterest in terms of usage. That's below Reddit, Snapchat, WeChat, and Instagram, and requires a user account to view profiles and posts. And that's ignoring all the reasons X is a divisive platform with an extreme political bent.
GitHub chose not to announce this on any other social media either (BlueSky, Facebook, TikTok, YouTube, LinkedIn, or Mastodon, as of this posting, and with no emails sent on the matter.)
So? Is this where your corporate paying clients should find out about an issue of this severity?
Not to mention Twitter is not an open platform anymore! (A) I'm an employee in an organization paying for Github. (B) I don't have a Twitter account. I already have a Github account because of (A). Why should (B) stop/delay me from getting official comms about this?
> I can't imagine they'd spam every account with an email address
It's not "spam" if it is relevant to me, such as security incident disclosures.
Also, as tiffanyh pointed out, what's wrong with Github blog or is that exclusively for marketing fluff now? That would've been appropriate enough, without having to spend Sendgrid credits.
Probably the best option after sending a mass email when customers need to take action.
The status page is for reliability issues impacting end users & the blog is for in-depth analysis.
The security issue aside, seeing more companies push announcements like these on X as the only official source is a trend I'm not sure I like.
I can understand the rationale, this feels lighter and not something that belongs on status.github.com or the blog. Maybe what's actually missing is an official channel for ephemeral stuff on a domain they own, somewhere between a status page and a tweet? Just sharing an observation.
This is bad. If they came out announcing this, without a long winded explanation and further details, it's because they're staring at a bottomless pit and they haven't put the lid on it yet.
For a Fortune 100, to go out of your way to spook investors is the least desirable approach.
Letting people know promptly is also the right thing to do and probably mandated by (at least some) customer contracts. You can't tell just some people; it would leak anyway.
Can you cite this? It's not YAML execution syntax, surely Github doesn't do it, the only vector I can see is if you put it unquoted into a shell script inside of a GHA yaml.
All you need is user content containing `backticked`, and a github action referencing that via eg "github.event.issue.title" where the shell would normally execute `backticked` as a command (like echo, cat, etc).
Sympathy to engineers and everyone at github, it's good that they're being open even if findings are limited. I'm sure they will figure out the root cause and will publish results to be a learning experience for everyone else
As some of us stated in the last weeks: Microsoft is working hard to get people to reconsider GitHub. All those small issues keep on adding up. Something is seriously flawed at Microsoft here - those problems did not exist in that way 2 or 3 years ago. It coincides with the rise of AI.
I think AI has helped to a degree. I think a lot of people have known about massive gaps in security, but it's been a sort of "why would I?" and a gap that didn't feel worth hopping for attackers.
The gap is smaller now.
I've been talking about package worms for... fuck, a decade. Insane. I've even thought about publishing one to prove a point but, well, it's illegal obviously. And ethically questionable.
Someone just vibecoded up what we've all known was possible for a long, long time. Just like a lot of other vibe coded projects.
I remember talking to a malware author a long time ago and I think this would have been exactly what he would have loved. He liked building custom C2 protocols, tiny malware, etc, but when we discussed a particular idea for owning massive amounts of infrastructure his response was basically "that's a lot of effort to get a krebs article and FBI attention". Now it's not so much effort!
It's more likely that it isn't coincidental at all: software development-oriented LLMs became a lot better towards the end of 2025, and so there's a non-zero chance that people are using them to find new security exploits.
(People are not sleeping on this and it is not something people have failed to notice. I don't use LLMs at all and even I have noticed it - largely because there is approximately nobody that isn't talking about it.)
There is a 100% chance that people are using LLMs to find vulnerabilities and build exploits. If it was possible for something to be a 101% chance, that's what it would be.
Apologies to all - I am British. The phrase "non-zero" does cover every case other than zero, but the intent is that it covers some cases more than others. What I'm trying to say is: yes. My intent was just to push back on this specific (and slightly bizarre to me) instance of kind-of-vagueposting, to my eyes written to imply that it might be some sort of unnoticed conspiracy, detectable only by the most enlightened of observers, attuned to the subtle signals that most people miss: that people are using LLMs to find security exploits.
Right, no, what I'm snarkily saying is that basically everybody who has ever looked for a vulnerability before is now using LLMs to do it. It's a huge thing in exploit development right now.
I think the other side is much more important. With company mandates to use AI as much as possible, there has been a deluge of low-quality PRs. Everybody is feeling tired from reviewing those, and quite possibly numerous security issues have been introduced since.
Ahh, that's a good point, and I actually hadn't thought of that angle! I was thinking of it purely from the point of view of the attackers using LLMs to generate interesting new exploits, with a side helping of letting myself get mildly annoyed, possibly incorrectly, by the writing style.
But yes, it's also possible the defenders have been kind of forced into having the slop machine shit out a huge pile of shit-ass changes, one way or another, that end up making the attackers' job even easier. (Even assuming no mechanisation at their end! Which is of course in nearly-June of 2026, probably unrealistic. And LLMs do appear to be really quite good at that side of the equation...)
The most dangerous is where the new feature works well and is using safe APIs, but integration is quietly broken somewhere. The risk of incoherent state is way higher because you no longer have a small set of people that knows the complete theory of the software and can find discrepancies.
I heard an engineer at Anthropic was submitting 150 PRs per day. That's one PR every 5 to 10 minutes, so you can guess the level of review and quality control involved.
I think it's more about the popularity than the capability. The chances you might accidentally put a Github access token into an undesired security context goes up dramatically when you actually create and use one on a regular basis. The developers at GH are certainly using these tools just like the rest of us.
between all the Linux LPEs and Claude's known security flaws, alone, I'd be shocked if Github and Microsoft hadnt gotten hacked by now. reasonable bet we mainly hear it when big shops get bit
Before 2026 I hosted client code on GitHub, now it feels suboptimal, code is both an intellectual property asset and security risk. Especially if the company is software based, self-hosting your code just has a much better risk profile for almost no cost.
It's also one of those things that warms your team up and gets them ready for actual work, a team that has to self host their git and other infra, like self-hosting DNS servers with bind, will have a much better work ethic than engineers who click buttons on a SaaS and conflate their role as users of a system instead of admins of one.
Additionally, using github actions, and relying on Pull Requests (Tm) (R) (C) has always been (useful) vendor lock in (and a security risk in case of GH Actions). It wasn't enough to lock down a choice, but it tilts the balance in favour of less dependencies, which with the increase of CVEs and supply chain vulns, seems to be the name of the game for this new era. Build it in house, ignore the dogma.