Even The NSA Got Involved

0:00PHP? Pwned. Node JS? Pwned. Light LLM? Pwned. GitLab? You guessed it, pwned. Open code? More like open pwned. And even Railway got railed. It seems like pretty much everything just got hacked. And the reason is cuz it did. This is horrible. This is one of the most unprecedented days in the history of software in terms of how many things just got destroyed. I've been trying to raise the alarm bells about this for a while now. It is not surprising to me that LLMs are now at the point where all

0:29of these types of things will happen. All that said, I actually feel a little bit bad about how I'm starting this video because it's almost misleading in a way. The reality is that two different things are happening at once right now. On one side, we have the CVEs like with Node, GitLab, PHP, Quick, Light LLM, and more. These are all real open-source things that people rely on every day they build their own software with, the dependencies in our stack, that have been discovered to have security issues that could be exploited in really scary, dangerous ways. Especially the PHP side, which I promise we'll talk a lot about

1:01the impact of. The rest, however, are different. They're attacks. Railway and Open Code are not at all like the hacks on the left side here because these are actual attacks. These are incident reports of bugs that exist in software that could be exploited. Both of these are bad, but they're bad for very different reasons, and I actually think the right side here is what we should be way, way more scared of, even though everyone seems really focused on the left side here. I'm particularly concerned about how I've seen people covering the Railway and Open Code hacks because there are important details as to the whys and hows here that I just

1:38don't see being covered at all right now. I initially planned to make this two separate videos with a clear line drawn between the CVEs and the attacks, but I've realized that if I do split these videos up, people are going to watch one and not the other and then say really stupid [ __ ] which is why this video is likely a lot longer than I want it to be. Okay, technically Light LLM was an attack. Well, we'll clear that up in a bit. I want to do everything in my power to make sure you guys understand what's actually going on here and what we should be scared about. As I imagine

2:06the comment section for this video, I feel my sanity draining from my body. So, we're going to have to take a quick break so my sponsors can cover my therapy. The insane capabilities of the models from labs like Anthropic and OpenAI have put us in a weird contradictory place. On one hand, has it ever been easier to build big complex software, but on the other hand, the same tools that made it possible to build this software are not making it possible to find the thing that matters, security issues. It's never been easier to put yourself in a position where you have these types of issues, but the

2:33models we use to actually try and fix things will refuse as soon as you try. That's why I'm so thankful for Code Rabbit. You might be confused cuz aren't they using the same models that we are? Wouldn't they hit the refusals, too? The Code Rabbit security platform has this all figured out. They use the best models they can for the things that they're approved for, and all the other models they need in order to do all of the rest. And the result is that you can get the security feedback that you need to make sure that you're shipping safe software. It all starts with the security dashboard, which keeps track of

2:59where security issues are appearing and how many exist over time. As you would expect, the Code Rabbit code review includes the security review for every PR as it's filed, but if your code base has been around for a bit or has anything in it that isn't being PR'd right now, it might miss things. And that's why their deep scan feature's even cooler. You throw it at a repo, wait half an hour to an hour or so, and then you get back a detailed report of all the potential security issues, many of which map to real known vulnerabilities from existing patterns, libraries, etc. Not only do they give

3:27you these detailed breakdowns, they also give you this one-click fix button, which doesn't seem that important cuz like you can screenshot this report and throw it at your agent until your agent refuses to fix it because Opus, Fable, Inso, and Astra just refuse to do so much modern security work. Keep shipping fast without compromising your security

3:43at swaito.link/coderabbit. Literally, as I am filming, Oracle got hit. This one's a CVE, does not appear to be an attack, so I'll put that in this column. I also think Light LLM does not quite fit here because it wasn't a bug or something wrong with the Light LLM in code base, it was a hijacking of GitHub actions that allowed for a sketchy malware version to be published

4:05on top of the existing Light LLM. Honestly, it doesn't really fit in what I'm talking about today, so I'm going to make the controversial choice to delete it because otherwise we will be doing this for far, far, far too long. As I mentioned earlier, the attack side is where things are most interesting and I would argue most important, but I have retention numbers to hit, so we're going to get there in a bit and start with all

4:26of the CVEs that were discovered today. All right, at the very least were published today. For those who don't know, CVEs are common vulnerabilities. This is a government-funded program that tracks all of the different vulnerabilities that are discovered and disclosed in various pieces of software so that the severity of the incidents can be identified, discovered, and addressed, and there is a shared database effectively for tracking these things across various different companies, products, etc. The October 21st security release from Node is a good example of how this all works. This updates for 20, 26, 24, and 22 based versions of Node.js. Security release includes the following dependency

5:02updates to address public vulnerabilities. There are vulnerabilities found specifically on OpenSSL as it worked in Node 24 and 22. CR is which I'm not familiar with. The CR is DNS library that's used in Node had a CVE that has now been fixed on these three versions. SQLite and DC CA cert. This one's from the e merda compromise. e merda is one of the companies that had the ability to issue SSL certs. They had their private key set as the number four, literally. While four is a really good random number, it's not necessarily the best password, so not great that this key existed, much less is being abused the way it is. So,

5:42everything that honors their certs is screwed and you need to make sure you're on the latest version of your browser and that all you murder search are not considered valid anymore. You'll see here that all of the things they addressed have these CVE tags. These link to that shared database we were just on that show how severe the incidents are and how they have been fixed and addressed. This allows for companies to privately talk about these things before they go public. So a lot of these reports probably were filed quite a bit ago and only are now being shared publicly because the biggest issue with a lot of this stuff is that

6:17when you fix the problem, there is a window from when the code that fixes it ships and everyone can see the code now knowing that there might have been a bug or something that they could use for hacks and then the time from when that merge happens on the GitHub repo or wherever the code is to when people actually have the safe version, that window is dangerous. Historically, it hasn't been that dangerous because it would take enough effort to first off

6:44find the things that were patched. Second off, figure what exactly they were actually patching. Third off, find a way to exploit the things that were patched. And then fourth and most importantly, distribute those exploits before most people have updated their software. The vast majority of exploits that happen are happening on known vulnerabilities that have been fixed, but the software you're running doesn't have the fix applied yet. This is why it's so important to stay on the latest version of your operating system, the apps you use, your browser, your

7:10dependencies and all these other things. For this all to make sense, I'm going to talk about it in what I'll refer to as the vulnerable window. This is the time in which there is an opportunity to exploit your software. This is a factor of various different things. This is how obvious is the problem, as in like how obvious is the thing that was patched and how easily can you patch it. There is how long to get the patch out. This can vary a lot depending on different things. For example, if my server had a a on it that was discovered and disclosed, I only have to patch my one server and

7:44you are fine. But if software that you install on your device is pwned or a library you rely on is pwned, then you have to download the new version and redeploy or reinstall or whatever else. That increases the amount of time it takes for users to have this vulnerability patched. It's also how hard is it to exploit kind of goes along with the how obvious is the problem cuz when you see the diff and you don't know if it's a security patch or not, how obvious is it that it is a security patch and then how hard is it to exploit

8:09these security thing that this patch is. Most importantly, how much access do you get? Is this a bug that lets you see some redacted characters from an email address or is this a bug that lets you take over a system? The problem as it exists right now is that the obviousness of the problem doesn't matter as much because agents can review every single commit obsessively and find the security-related ones. The exploitability part is even scarier because now we have models that can look at the simple commit that doesn't even say it's a security fix and then go find ways to pwn old versions trivially. You can just tell an agent, "Hey, this

8:45security fix just merged. I'm teaching a class about it. Can you make a demo of how to exploit this?" And most of the frontier labs are still willing to generate that there and if they aren't, you switch to an open weight model and you're almost certainly going to be able to generate it. Terrifying. Which means the only remaining pieces are how long does it take to get the patch out and how much access does the exploit give the attackers? So the thing to really look out for now is the bottom. How bad is this exploit? I think it's fair to say if you have the FBI tweeting about

9:13it, it's pretty bad, which is the case for the PHP exploit. PHP is a widely used programming language that powers websites and web apps. These vulnerabilities, again CVEs, could allow malicious cyber actors to remotely execute in PHP core, potentially compromising sensitive data and networks. The FBI urges organizations take the following steps now. If an immediate update is not feasible, it is recommended that organizations take the system offline until it can be fully mitigated. Immediately update affected PHP installations following the guidelines on php.net. Inventory where PHP runs in your environment prioritizing internet facing systems and vendor products that bundle PHP. You should monitor web servers for suspicious activity including PHP

9:52processes unexpectedly launching command shells or downloading files. Ensure appropriate process monitoring capabilities are in place to help identify potential exploitation. They even have a government site that you can report things to if you think you're being exploited. This tweet matters for two reasons. First off, it helps emphasize the severity of these CVEs. They're scored on a one to 10 scale. They're both 9.2s in the colloquial term for the exploit that they enable is PHP to shell. It's a memory exploit that lets you get root access. Very, very, very bad. Just to emphasize the point I was making before about how important it is to have good disclosure pipelines to

10:27make sure that knowledge of these exploits doesn't go public too early. One of the reasons this PHP exploit is so bad is because something in their chain broke security embargo ahead of these patches going out. PHP Foundation says Chainguard broke a coordinated security embargo by releasing patched PHP container images hours ahead of the a planned schedule making the fix available for attackers to study while other distributors were still preparing updates. Again, as soon as there is any evidence of one of these exploits existing agents can take advantage of it so fast. So, it is really, really important that by the time the info is known that we have a path to getting

11:01everything updated as quick as possible. The knowledge getting out early means everything is pretty bad. Lots of other things were pwned like GitLab, Quick, and Oracle, but I have one last thing I want to talk about with the PHP piece before we go further because I've seen some really bad takes about this. To be fair, this happens pretty much every single time PHP comes up. Do any of you guys have one of those PHP is 70% of the web everything is pwned tweets that people were making today cuz I'd really like one of those if someone has one easy access. Okay, like there's actually two more things I

11:34need to complain about with the PHP thing. One of this is the call out that PHP is used to run an estimated 70% of websites. I'll complain about that in a minute cuz there's a much funnier thing I want to mention in here. The PHP exploits weren't found with modern models. They were found with GPT 5.6 Soul. This shows both how long it takes for these things to become public because again they have to try and protect these incidents and not make it as well known, but also that a model as bad as 5.6 Soul is able to find these exploits. There are multiple open weight

12:06models that are nearly as capable as 5.6 Soul at this point. We are very screwed. Apparently, another group Wiz also independently discovered and reported these vulnerabilities. This is the other scary thing is if only one party is aware of these security issues, cool, awesome, get it fixed before it's public. But if two can find it

12:25independently, that's a lot scarier. Similar to how we just had four independent groups rewrite all of TypeScript in Rust in roughly the same time window. If any one group is able to get modern models to discover an exploit, there are probably lots of others that are figuring it out around the same time. This also helps destroy this idea of private disclosures in order to prevent public software from being exploited as badly. Everything is

12:49falling apart is what I'm trying to say. Very slight silver lining is on the 70% of websites thing. I've been trying all day to come up with a good analogy for why this is really stupid. Okay, I have one. Did you know that the average person spends less than 1 hour a year on a screen? I know it seems insane cuz all of us have crazy screen time, but the average screen time for a human is under an hour a year. It's probably even less than that because I didn't specify living humans. If you include every human who ever lived and you average out all humans,

13:23the number goes down a bunch. It's similarly, if you measure websites by the number of URLs served by PHP, you're doing a thing that's really [ __ ] stupid. Because the vast majority of websites on the internet are dead. I would bet if I check my open tabs in Chrome right now, almost zero of them are PHP websites. We got Railway, definitely not PHP. We got YouTube chat, which is slow as it is, also crazy

13:48enough isn't PHP. Twitter isn't PHP. Twitch, been through it, definitely not PHP. More Railway, not PHP. GitHub, not PHP. YouTube, not PHP. All of my other services here, things I built mostly, none of that is PHP. The point I'm trying to make here is, yeah, sure, 70% of websites are PHP, but that's a useless number because none of these are getting any traffic at all. I don't care if your old unmaintained WordPress blog from 2014 is pwned. I really don't. So, yeah. Is this going to be bad for the preservation of the web? Yeah, but WordPress is already bad for the preservation of the web. The If I

14:25recall, the majority of websites, like over 50%, are WordPress. And WordPress is even more fragile than PHP by itself and has had a lot of incidents that I have personally been affected by, like when I built my uncle a website for his like small fishing charter when I was in high school and then forgot about it and didn't maintain it, it got pwned to hell because I wasn't maintaining it. And that's the problem here. It's not just dead websites, it's dead people not maintaining their websites or people who left their job not updating their

14:55websites or random government stuff. Like things like that are [ __ ] That is a really big deal. The vast majority of websites getting actual traffic today are not using PHP. So, don't get too scared of these 70% numbers. I really wish we would stop talking this way because nobody thinks this way. Okay. I have said everything I really want to

15:16about the CVE side of things today. Believe it or not, that was the less interesting and also less scary side. Cuz now we have to talk about the attacks. I'm going to start with the Open Code attack. For those who aren't familiar, Open Code got pwned a few days ago. This isn't like they got access to all of your data cuz like it's running on your own devices. Usually, they're not even collecting that much data. The thing that was affected by the Open Code hack was API keys. Not the Open Code

15:44ones, they rolled all those obviously. The issue is if you brought your own API keys to Open Code in their dashboard and on their server side. So, if you set up Open Code with your account to have an API key for Anthropic, OpenAI, Gemini, or whatever else, those keys all could have and often did get found and exploited. Many devs were reporting that their OpenAI and Anthropic API keys got consumed and their OpenAI accounts were suspended. Did Signal just get

16:10exploited? I saw people reporting abuse numbers from their leaked keys as low as 400 bucks and as high as 3 grand all in minutes from when the accounts and keys got found and exploited. Kind of crazy. Lots of people were banned, lots of people got a lot of money spent. Thankfully, Open Code has been working closely with the labs to get people refunded, to get their accounts reinstated, to deal with all of this, and also to automatically roll all of the keys. So, why would somebody hack Open Code just to get a bunch of API keys that all get revoked a few minutes later? Well, guess what? They did the

16:43same thing to Railway. Earlier this morning, Railway detected anomalous activity involving systems that store customer environment variables. After further investigation, our investigation to date indicates that an unauthorized third party may have accessed encrypted environment variables and for some of them obtained the decrypted contents. Environment variables may contain secrets such as API keys or database and registry credentials. This one really pissed me off because I have a bunch of [ __ ] deployed on Railway, all of which is down currently because not only are the environment variables compromised, they also took down deployments. So, I've been unable to redeploy with the new environment variables after rolling them. So, Railway had their environment

17:24variables stolen and their deployments taken off entirely. Open code just had the environment variables stolen. What is going on here? Well, I'm going to do another one of these split in half things because the Railway thing is two separate pieces. You have the API keys that I mentioned before and Open Code also had those get stolen and Railway

17:44separately has a full deployment outage. The reason I'm separating these is I feel obligated to call out my sponsors when they're up to some [ __ ] The API key thing sucks, but this happens. This is like things get exploited if you have sensitive data, people will target it. We'll talk more about what's going on there in a sec because I need to crash out a little about this side. I'm currently filming this video at 5:30 p.m. Deployments have been down on Railway since 1:00 a.m. It has been 16

18:17hours since I could deploy to Railway. This is unrelated. This is not because Railway got hacked. The hack might have resulted in them doing things that caused this, but the inability to deploy and roll keys and fix your stuff on Railway is because Railway is incompetent. I would love for them to prove me wrong here, but I've been burned many a time and I am frustrated and I am annoyed and I will be reconsidering hosting important software on Railway in the future because side note, this is not the first time that their weird incompetence around how they

18:48manage their platform has burned me. These comments are going to cost me tens of thousands of dollars because I have two pending ads with them, one of which I just recorded that I was actually quite excited about because I do love using the Railway platform. It is absurdly good value. It is very well priced. The file storage S3 stuff that they do is incredible, one of the best blob stores there is. My agents love using it, too. This is inexcusable. If this was the first time it happened, that'd be one thing, but Railway is consistently one of the most unstable

19:16parts of my infrastructure ecosystem. It's getting up there with GitHub at this point. And to those mentioning fly.io, they were one of the few brands I cut off from sponsorships because their platform was so inconsistent I couldn't even film ads without it crashing. So, I do not recommend fly at all. I don't know what I recommend yet. I'll come back to y'all soon. You get the idea though, the full deployment outage has very little to do with the hack and very much to do with Railway itself, which means the only remaining thing we have to talk about is the thing that actually matters here, the API

19:43keys. Why do people want these? Especially if they can't keep using them. Like, if I had two options personally, I could have an API key that worked for a day with unlimited usage, or had an API key that worked for a year with $100 of usage a day, I'd pick the one for a year without question, even for a month. Cuz I don't know what I personally would do with millions of

20:04dollars of inference in a given day. Like, I actually cannot fathom what I would do with that. And obviously, once these keys start getting exploited, they are going to get rolled, they are going to stop working. The amount of time you get with one of these keys is relatively low. So, who in the world would want unlimited inference

20:25for a few hours? Let's think about this. Who are the groups, the parties, the companies, the individuals who would want to get an Anthropic API key and an OpenAI API key knowing that like they can only use it for so much time. I see people speculating that this is being used for scammers in order to do like generated responses to things. You can do that on cheap open weight models, it costs almost nothing. Not worth burning hacks like this. I see people saying hackers that want to use it to hack other things. I see people mentioning crypto for some reason, which is nonsense. There's only one reason you

20:58would want this. Say it with me, chat. Distillation. What the hell do I mean? Okay, hear me out. Let's say you're an AI lab that's trying to make a new, really capable model. Let's come up with something entirely random. Let's say Seep Deek. You run this company called Seep Deek and you're trying to make the

21:20world's greatest models. As a researcher at Seep Deek, you want to use the best tools available to you. So, you go and register for We'll go with Denise. Okay, it's easier to just say Claude. I'm just saying Claude, [ __ ] it. So, you want to use the best in class models to help you with your work, to get data, to do all the things that you want to do because your goal ultimately is to make a model similar in capability to what Anthropic puts out with Claude. Anthropic knows this. They know that the data that you can get from Claude is useful, not just for helping

21:51you write code to make your own models, but for generating the data that you can use to train the model. If you have enough examples of how Claude solves problems, you can do crazy things. Because the harsh reality is that the data that we trained models on is both hard to get now because the internet has been locked down, and it's also not as valuable for things like coding with agents because there just aren't that many examples online or anywhere in the world of how an agent would solve a task when it starts to differ more from how humans do, in particular when you start

22:20doing it inside of a bash terminal. Because of this, data that shows how LLMs handle complex tasks that they can do with the tools they have is incredibly useful data. But, that data is not just stuff you can download from the internet. It's data that kind of needs to be manufactured. And this is why so many companies wants to collect all of your history with Claude and with OpenAI models because they can use that to refine and train new models with similar capabilities. This allows for companies that aren't Anthropic and OpenAI to start to catch up faster to where Anthropic and OpenAI are because they can use all of this data to train

22:56the model more effectively without having to build all the systems and environments that were used to make the data exist in the first place. Okay. With all of that said, why would they not just buy the tokens then? That's cuz when this goes the other way, they get banned, not allowed. Anthropic has went out of their way to ban all attempts from Chinese labs to try and collect enough data to distill. They've even banned companies in the US. Like they banned Wind Surf temporarily cuz they

23:21thought Open AI was going to buy them. Because they don't want other companies getting access to their data to train a model with similar capabilities, they say because those capabilities won't have the same level of safety. I say it's a combination of that and also they're protecting their monopoly here. What this means is there's a lot of demand from companies like a hypothetical Seep Deek here that wants to use a lot of money to generate lots of Claude tokens to get data they can use to train their models, but Claude is not willing to sell to them. Claude is not just unwilling to sell to Seep Deek

23:54here, they're also more than willing to ban other companies that seem totally legit because they might be reselling the same data and tokens to Seep Deek. This includes a bunch of companies in South Korea that were paying Anthropic a ton of money, some of which were even investors, that Anthropic has chosen to cut off because they had reasons to believe that other Chinese labs were using those API keys to get the data they need for distillation. In order to prevent all of this, Anthropic has put a bunch of measures in place. Obviously, they try to detect distillation looking for certain archetypes and shapes of requests that are similar to when people

24:28are trying to distill. They also do some know your customer stuff to in certain cases try to get you to verify your identity with an ID card or your license, passport, something like that to make it less likely that you're a foreign national trying to steal data. They also have thresholds on how much API usage you can do until certain like levels of usage and age of account are hit. And there's a lot of things that can only be done on old accounts that can't be done on new accounts. And of course, they have hard bans on certain IPs and regions to make it harder for

24:55people in certain places like China to register for and use Anthropic's inference over Anthropic's APIs. What I'm trying to say here is seep deek can't just go register for a Claude account and expect to have a whole lot of luck with it. But this is an opportunity for people in between. If you're a hacker, a dishonest person, or otherwise just want to get a bunch of money out of one of these labs, all you need is a bunch of Claude API keys. You don't even need credit cards. You don't even need to forge identities. All you need is these API keys people have made on Claude and forgotten about because

25:30once you have those, you now have everything you need to generate a bunch of tokens. It will get banned, obviously, but you can get a lot in before that happens and you don't have to pay a cent cuz it's somebody else's billing, somebody else's account. As such, there is a ton of demand for Claude API keys, for OpenAI API keys, things that people have on accounts that they are not monitoring very well. And I'll be real, I don't monitor our OpenAI spend particularly well. I was very nervous today when Railway got pwned, looking to make sure none of my accounts were getting hit because I just haven't

26:01had to check in a while. This is because the Chinese labs and other parties that wants to make smarter models, but are banned from Anthropic and OpenAI, need ways to get the tokens in order to distill their models. And I'm going to stop pretending that this isn't happening. It very obviously is. All of the Chinese labs are trying incredibly hard to get all the possible data they can to make their models act similar to

26:21Claude. This is one of those attempts. Since Anthropic is not willing to sell inference to these companies that want these tokens for a reason that we can argue the validity and all we want, Anthropic's desire to not let them get those tokens and not let them have that inference is causing a weird downstream effect where users, customers, builders like Railway, OpenCode, and more are now targets in ways they've never been before. Pwning Railway honestly doesn't get you a whole lot, especially if it happened before the AI era. Everybody was hosting these keys on their railway deployments. Because generally, if you get into everyone's databases, by the

26:59time you've dumped enough data to even vaguely be useful, you've been locked out. Then how useful is that data? Good luck figuring out. But if you get a bunch of passwords that can be used to generate between a hundred and a few thousand dollars of value before they're killed, and then you resell those for cheap to companies that want to do sketchy things with it, that is a huge opportunity. What I'm trying to say is every platform that hosts API keys is a target now because there is so much demand in these sketchy black markets for Anthropic and OpenAI API keys. I would say Gemini, but I'll be real, I

27:31don't think anyone's trying to distill Gemini right now, even Google. You get the idea though. Everything's kind of [ __ ] I have a bad feeling it's going to get a lot worse before it gets better. It's weird to frame it as Anthropic's unwillingness to sell to these companies is getting other companies poned in the middle. But that's what's happening. A lot of us are going to get caught in the crossfire here. Whether or not Anthropic is doing the right thing is up for debate. I think it is their right as a company to choose who they do and don't want to sell to. It is just a very

28:01painful, strange, and arguably hellish side effect that we are now getting poned in the ways we are because of the demand for those keys. And on top of all of this, we can't use the bottles from OpenAI and Anthropic to figure out what's wrong and fix it because they'll start refusing cuz they think we might be the hackers. So, once again, OpenAI and Anthropic have put us in this position and aren't really here to help us. It's going to be bad. And it's not going to get better. It's going to get a lot worse first. I said six months ago in a podcast that we have three to nine

28:30months. Weird how spot-on I was. Okay. Actual last thing cuz I already foresee the comments and I probably should have mentioned this earlier because the type of people who leave these comments don't watch the whole video. If you think the PHP hack and the Railway or open code hacks are related. I hope that you aren't too tied to this software dev thing because you're going to be replaced by Claude very, very soon. It is so very obvious. These things have nothing to do with each other and I've nothing else to say about it. It does feel like the start of the end. So, I guess there's no better time

29:06to end the video, right? Seriously, protect your [ __ ] keep everything up to date, keep an eye online to see where things are happening and make sure your API keys are very well protected, very well separated, and easy to revoke because this is going to get a hell of a lot worse before it gets better. I think that's all I have to say. So, until next

29:20time. Peace, nerds.