Even The NSA Got Involved Transcript

00:00 PHP poned Node.js poned light LLM poned GitLab you guessed it poned open code more like open poned 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.

00:24 It is not surprising to me that LLMs are now at the point where all of 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 CVE like with Node, GitLab, PHP, Quick, Light LLM, and more.

00:46 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 the impact of. The rest, however, are different.

01:03 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.

01:28 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 wise and hows here that I just don't see being covered at all right now. I initially planned to make this two separate videos with a clear line drawn between these CVEes 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

01:56 it to be. Okay, technically LightM was an attack. We'll 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 the 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.

02:13 The insane capabilities of the models from labs like Anthropic and OpenAI have put us in a weird contradictory place. On one hand, it's 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 ever been easier to put yourself in a position where you have these types of issues, but the models we use to actually try and fix things will refuse as soon as you try.

02:36 That's why I'm so thankful for Code Rabbit. You might be confused because 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.

02:51 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 at the security dashboard which keeps track of where 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.

03:05 But if your codebase has been around for a bit or has anything in it that isn't being PRD right now, it might miss things. And that's why their deep scan feature is 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.

03:26 Not only do they give you 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, and Soul, and Astra just refuse to do so much modern security work. Keep shipping fast without compromising your security at soy.code /code rabbit.

03:43 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 codebase. It was a hijacking of GitHub actions that allowed for a sketchy malware version to be published on top of the existing light LLM.

04:07 Honestly, that 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 of the CVEEs that were discovered today or at the very least were published today.

04:29 For those who don't know, CVEEs are common vulnerabilities. This is a government-f funed 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.

04:50 The October 21st security release from Node is a good example of how this all works. This updates for 26,24 and 22 based versions of Node.js. Security release includes the following dependency updates to address public vulnerabilities. There are vulnerabilities found specifically on OpenSSL as it worked in node 24 and 22. CS which I'm not familiar with the CS DNS library that's used in node had a CVE that has now been fixed on these three versions.

05:19 SQLite undcerta is one of the companies that had the ability to issue SSLerts. 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, everything that honors theirs is screwed. And you need to make sure you're on the latest version of your browser and that allurerts are not considered valid anymore.

05:51 You'll see here that all of the things they address 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 when you fix the problem, there is a window from when the code that

06:19 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 That window is dangerous. Historically, it hasn't been that dangerous because it would take enough effort to first off find the things that were patched.

06:46 Second off, figure out 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.

07:04 This is why it's so important to stay on the latest version of your operating system, the apps you use, your browser, your dependencies, 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.

07:24 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's how long to get the patch out. This can vary a lot depending on different things. For example, if my server had a vulnerability on it that was discovered and disclosed, I only have to patch my one server and you are fine. But if software that you install on your device is pawned or a library you rely on is pawned, then you have to download the new version and redeploy or reinstall or whatever

07:53 else that increases the amount of time it takes for users to have this vulnerability patched. There's also how hard is it to exploit kind of goes along with the how obvious is the problem because 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 the security thing that this patches?

08:11 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.

08:32 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 pone old versions trivially. You can just tell an agent, hey, this security 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.

08:53 And if they aren't, you switch to an openweight 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 it, it's pretty bad, which is the case for the PHP exploit.

09:15 PHP is a widely used programming language that powers websites and web apps. These vulnerabilities, again, CVEes could allow malicious cyber actors to remotely execute in PHP Core, potentially compromising sensitive data and networks. The FBI urges organizations to take the following steps now. An immediate update is not feasible. It is recommended that organizations take the system offline until it can be fully mitigated.

09:38 Immediately update affected PHP installations following the guidelines on PHP.NET. Inventory where PHP runs in your environment, prioritizing internetf facing systems and vendor products that bundle PHP. You should monitor web servers for suspicious activity, including PHP processes unexpectedly launching command shells or downloading files. Ensure appropriate process monitoring capabilities are in place to help identify potential exploitation.

09:58 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 CVEes. They're scored on a 1 to 10 scale. They're both 9.2s, and the colloquial term for the exploit that they enable is PHP to shell. It's a memory exploit that lets you get root access.

10:18 Very, very, very bad. Just to emphasize the point I was making before about how important it is to have good disclosure pipelines to make 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 Chain Guard broke a coordinated security embargo by releasing patched PHP container images hours ahead of the planned schedule, making the fix available for

10:46 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 everything updated as quick as possible. The knowledge getting out early means everything is pretty bad.

11:05 Lots of other things were pawned 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 pawned tweets that people were making today because I'd really like one of those if someone has one easy access.

11:31 Okay, I lied. There's actually two more things I need 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 wanted to mention in here. The PHP exploits weren't found with modern models. They were found with GPT 5.6 soul.

11:49 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 wellknown but also that a model as bad as 56 soul is able to find these exploits. There are multiple openweight models that are nearly as capable as 56 soul at this point. We are very screwed. Apparently another group whiz also independently discovered and reported these vulnerabilities.

12:15 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 independently, 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.

12:41 This also helps destroy this idea of private disclosures in order to prevent public software from being exploited as badly. Everything is falling 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?

13:06 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, the number goes down a bunch. Similarly, if you measure websites by the number of URLs served by PHP, you're doing a thing that's really [ __ ] stupid.

13:31 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 as slow as it is, also crazy enough isn't PHP. Twitter isn't PHP. Twitch, been through it. Definitely not PHP. More Railway, not PHP.

13:54 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 pawned. I really don't.

14:15 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 recall, 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 pawned to hell because I wasn't

14:46 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 the job not updating their websites 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.

15:07 I really wish we would stop talking this way because nobody thinks this way. Okay, I have said everything I really want to about the CVE side of things today. Believe it or not, that was the less interesting and also less scary side because 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 pawned a few days ago.

15:33 This isn't like they got access to all of your data because 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 ones, 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.

15:51 So if you set up open code with your account to have an API key for anthropic, open AAI, 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 exploited? Uh, I saw people reporting abuse numbers from their leaked keys as low as 400 bucks and as high as three grand all in minutes from when the accounts and keys got found and exploited.

16:22 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?

16:41 Well, guess what? They did the same 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.

17:00 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.

17:22 So Railway had their environment variables stolen and their deployments taken off entirely. Open code just had the environment variable 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 separately has a full deployment outage.

17:49 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.

18:10 Deployments have been down on Railway since 1 a.m. It has been 16 hours 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

18:43 the future because sadly this is not the first time that their weird incompetence around how they manage 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.

19:00 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 parts of my infrastructure ecosystem. It's getting up there with GitHub at this point.

19:20 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 keys.

19:44 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 I had an API key that worked for a year with a $100 of usage a day. I'd pick the one for a year without question even for a month because I don't know what I personally would do with millions of dollars of inference in a given day.

20:06 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 for 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 open AI API key knowing that like they can only use it for so much time.

20:39 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.

20:56 There's only one reason you would 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 SED. You run this company called SEDDeek and you're trying to make the world's greatest models.

21:20 As a researcher at SeepdeDeek, 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 Enthropic puts out with Claude.

21:44 Enthropic knows this. They know that the data that you can get from Claude is useful, not just for helping you 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's been locked down and it's also not as valuable for things like coding with agents because there just aren't that

22:11 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 doing it inside of a bash terminal. Because of this data that shows how LLM 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.

22:32 It's data that kind of needs to be manufactured. And this is why so many companies want 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 the model more effectively without having to build all the systems and environments that were used to make the data

22:59 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 because they thought OpenAI was going to buy them because they don't want other companies getting access to their data to train a model with similar

23:27 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 seepde here that want to use a lot of money to generate lots of claude tokens to get data they can use to train their models.

23:47 But Claude is not willing to sell to them. Claude is not just unwilling to sell to seepde here. 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. This includes a bunch of companies in South Korea that were paying Anthropic a ton of money. Some of which were even investors that Enthropic 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

24:17 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 are 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.

24:40 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 people in certain places like China to register for and use anthropics inference over anthropics APIs.

25:02 What I'm trying to say here is seepde can't just go register for a cloud 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 cloud API keys. You don't even need credit cards.

25:21 You don't even need to forge identities. All you need is these API keys people have made on Claude and forgotten about because once 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 scent because it's somebody else's billing, somebody else's account.

25:41 As such, there is a ton of demand for clawed 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 pawned, looking to make sure none of my accounts were getting hit because I just haven't had to check in a while.

26:01 This is because the Chinese labs and other parties that want to make smarter models but are banned from anthropic and open AI 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 Quad.

26:21 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 in 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, open code, and more are now targets in ways they've never been before.

26:46 Honing 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 time you've dumped enough data to even vaguely be useful, you've been locked out and how useful is that data? Good luck figuring out.

27:05 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 open AI API keys.

27:26 I would say Gemini, but I'll be real. I don't think anyone's trying to distill Gemini right now, even Google. You get the idea, though. Everything is 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 pawned in the middle, but that's effectively what's happening.

27:50 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 painful, strange, and arguably hellish side effect that we are now getting pawned in the ways we are because of the demand for those keys.

28:09 And on top of all of this, we can't use the models from Open Anthropic to figure out what's wrong and fix it because they'll start refusing because they think we might be the hackers. So once again, Open 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.

28:26 I said 6 months ago in a podcast that we had 3 to nine months. Weird how spot on I was. Okay, actual last thing because 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.

28:56 It is so very obvious these things have nothing to do with each other and I have nothing else to say about it. It does feel like the start of the end, so I guess there's no better time to 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.

29:17 I think that's all I have to say. So until next time, he's nerds.