Everything is pwn’d now

Copy fail 732 bytes to route on every major Linux distro. Copy fail 2 electric bugaloo unprivileged Linux LP via Xfirm. Dirty frag universal Linux LPE breaking 84 Tanstack npm packages were compromised in an ongoing supply chain attack. Damned OB a publicly disclosed yet to be patched attack that lets you break out of slab memory. Mythos finds a curl vulnerability. Whiz research discovers remote code execution on github.com with a single git push. The flaw on GitHub allowed unauthorized access to millions of repos belonging to other users and organizations. I told you guys the security Armageddon was coming. I did not expect it to be this brutal, though. The rate at which we started seeing these absurd, horrifying exploits across all of the software we rely on is hard to believe. And what's even harder to believe is that the problem is worse than it seems. Not only are we getting all of these exploits all over the place that are thankfully being fixed, but we have new attack vectors that we've never considered before as an industry. I know that I might sound alarming and I'm known for like exaggerating things and making my words big and whatever. I don't [ __ ] care. This is a really big deal and I don't know why people aren't talking about it more. This is this is the end of software as we know it if we don't jump in front of it. And the culture of security that we've relied on for the past decades no longer makes any sense in the current times. There's a lot we need to dive into here. How software is changing. How we need to keep changing in order to keep up. How AI is fueling all of these discoveries and all of these potential hacks. and how in the end, whoever has the most tokens wins. I feel like I'm going mad and I honestly feel bad doing a sponsor cut at all in this video, but if the future isn't one where I can use and rely on software, I need to pay my bills somehow. So, we have to do a quick break and then we'll dive in. If you're currently using T3 Code, specifically the nightly, you might have noticed this little button in the bottom left, the update available button. For better or worse, that's cuz of today's sponsor, Blacksmith. These guys made our CI so much faster that we decided to make our nightly builds just change whenever any actual code ships. The Mac OS builds were super long. Intel builds were almost 9 minutes and the Mac ARM builds were over six. And then Blacksmith added runners for Mac OS. Now our total build time is just 10 minutes. And the ARM and x64 builds are way faster. We cut the Mac build in near half down to 3 minutes and 32 seconds for the ARM build. And we cut it in more than half but getting down to 3 minutes and 34 seconds on the Intel build. And we're far from the only people who have seen this experience. Companies like Ashb doubled their deployment times and cut their costs for CI by three quarters. It's way faster and more reliable, but even when it does fail, you have a much better console to figure out what went wrong. Do you know how nice it is having actual logs that show you what's going on in your different jobs? I didn't know how good this was because I was using GitHub actions before and it was hellish. Your devs and your agents deserve better CI. Get it today at soy.v.link/blacksmith.h. This one's going to be kind of crazy. Flashbang warning. Copy fail is the start of the end. This exploit's really, really bad. It's a vulnerability that's in pretty much every Linux distro because it's on the latest version of Linux kernel 6 as well as kernel 7. They both have been updated, but it is very common for distributions to not update their kernel regularly. So, a lot of additional patches have had to be put on top at the DRO level. We'll talk a lot about Linux distributions and how they are unfairly affected by these things in just a moment. This exploit allows for trivial escalation to root, not just through native binary code, but through things as simple as a small Python script. Just to explain how risky this is, any distributor of popular Python libraries could easily have used this to pone a lot of people by just including 732 bytes of scary but easily obuscated Python code. That's really, really bad. The exploit's pretty simple. You start from a specific point in memory where you have a longer window that is available to you. you traverse it and then do things pretending you have more memory available than you actually did. The window slides as you move down the indexing, which allows you to just take memory you're not supposed to have access to. This allows anything from root escalations to rewriting system files. This is really, really bad. Thankfully, it's been patched and everything, but even that's a kind of we've already seen additional similar exploits built on top of the same core piece here, including things like copy fail 2 and dirty frag. So, that's the problem, right? We have these new exploits that are very easily exploited. No, the problem actually goes deeper. And when I say we are so [ __ ] I hope you understand. I am not trying to like just get clicks or something here. This video is not going to make me a lot of money. In fact, it's probably going to burn some trust and I'm just eating that fact because things are really [ __ ] right now. The sheer volume of security things going on in every software ecosystem is hard to put into words. But the problem isn't even just the volume. It's how the entire process has been upended. There's a couple key truths that we've relied on in software in order to have software that is secure and functions. Truth one is that only well- paid experts could find exploits. That's just not true anymore. If you run an agent in a loop for long enough in the right way, in the right place, and you have enough money to spend on tokens, you can find exploits in real software today. That is really, really scary. We've already talked about this a bunch, but there's two new problems that I had some concerns about before, but the rate at which those concerns are escalating is really bad. The second truth is that the 90-day disclosure process is enough. If you're not familiar, it's generally considered best practice to file a CVE where you notify the company or the maintainers of a given thing that you found an exploit in to give them the time to fix it, send out patches, get the world updated, and then eventually you'll be able to disclose this publicly. Maybe you'll even get paid for your work. That's barely even happening anymore. I can't tell you how many times I've seen random blog posts that are disclosing things that are either not patched or are patched but not merged into stable yet. Oh, that's interesting. This post had more data in it before, but the author actually redacted a bunch. It previously mentioned that this exploit has since been patched, but the patch isn't instable. And this is just a public exploit that he posted on his blog. Not great. But point 2 combined with an important point three. Going from patch to exploit is hard. What I mean by this is in reference to the 90-day window. Imagine there is a bug in how memory is allocated in some kernel and some OS and some program and you find this exploit and you disclose it to the maintainers of that project. They're not going to put out a commit that says fix massive security hole. They're going to put up a commit that has a very simple message along the lines of like patch unexpected behavior in X, Y, or Z. That patch would be silently merged into the project, distributed in the next version, and once a certain percentage of your users have that patch, you would then publicly disclose. And this relied on something that's kind of part with one and two here, where you had to have a certain level of knowledge and capability in order to figure this out. And also more importantly, you had to spend the time going through every single commit to every single important project that was open source in order to find commits that might be to cover some security issue in order to exploit that. This allowed a solid window from when a patch was merged to when it was actually published and people had access to it to when people would be able to exploit the thing. Obviously, if you really really really wanted to hack Linux and you spent a lot of time in the mailing list and reading over every single commit, you might be able to find things because most Linux distros ship relatively old versions of the kernel that can't really go any longer. This this is bad bad. This article from Jeff Kaufman highlights the severity of those last two vulnerability culture pieces breaking down the 90-day disclosure process as well as going from patch to exploit. A week ago, the copy fail vulnerability came out and Hun Wu Kim immediately realized that the fixes were insufficient, sharing a patch the same day. In doing this, he followed standard procedure for Linux, especially within networking. Share the security impact with a closed list of Linux security engineers while fixing the bug quietly and efficiently in the open. His goal was that with only the raw fix public, the knowledge that a serious vulnerability existed could be embargoed. The people in a position to address it know, but they've agreed to not say anything for a few days. But someone else noticed the change, however, and realized the security implications and then shared it publicly. That is copy fail 2, by the way. Since it's now out, the embargo was deemed over and we can now see the full details. It's interesting to see the tension here between two different approaches to vulnerabilities. And think about how this is likely to change with AI acceleration. On one side, you have the coordinated disclosure culture. This is probably the most common approach in computer security. When you discover a security bug, you tell the maintainers privately and give them some amount of time, often 90 days, to fix it. The goal is that a fix is out before anyone learns about the hole. On the other side, you have the bugs are bugs culture. This is especially common in Linux where the argument is that if the kernel is doing something it shouldn't, then someone somewhere may be able to turn it into an attack. Just fix things as quickly as possible without drawing attention to them. Often people won't notice with so many changes going past and there's still time to get machines patched. This approach never worked perfectly, but with AI getting good at finding vulnerabilities, it's a much bigger problem. There are so many security fixes coming out now that examining commits is much more attractive. The signal to noise ratio is higher. Additionally, having AI evaluate each commit as it passes is increasingly cheap and efficient. Long embargos, however, aren't doing well either. The historical pace of detection was slow. You found something and reported it to the vendor with a 90-day disclosure window. There was a very good chance no one else would notice during that time. But now, with so many AI assisted groups scanning software for vulnerabilities, that no longer halts. In this case, just 9 hours after Kim reported the ESP vulnerability, Quanting Chen also independently reported it. That's again 9 hours later. Do you know how unprecedented that is for two separate parties to find the same massive security exploit within 9 hours of each other? That's like a new novel thing. Embargos can increase risk. They create a false sense of non-urgency and limit which actors can work to fix a flaw. The author calls out that he has no idea how to fix this. Neither do I. But very short embargos seem like a good starting point at least. And they might have to get shorter over time. Luckily, AI can speed up defenders as well as attackers here, allowing embargos that would previously have been uselessly short. Mostly agree. There are lots of other issues here, especially around system maintenance. I don't know about you guys, but I have multiple Linux kernels in this apartment right now on multiple devices that are almost certainly still vulnerable to copy fail v1 because nobody updates all of their Linux boxes reliably enough. The scariest part of this post, though, is actually this footnote. The footnote is to the section discussing how AI is better at evaluating commits to find potential exploits they might be patching. The author of the article took the commit that fixed the copy fail to exploit. That was a relatively simple commit with a decent message and a couple very small changes, literally like four lines of code were changed. They handed this commit to Gemini 31 Pro, GPT Thinking 5.5, and Claude Opus 4.7. All three got it right away just from the commit. When I gave them just the diff, imagining a hypothetical future where diffs are still public right away but with less context. Gemini was sure it was a security fix. GBT thought it probably was and Claude thought it probably wasn't. Oh, Claude. Regardless, with the whole thing, they all figured it out. But even without the commit message, just the commit changes itself, two of three, even the dumb one, Gemini 31 Pro, were able to figure out this is likely a security thing. This is just a very quick test to illustrate what's possible. One run of each with a prompt without searching. Does this look like a security patch? There's no control group. And don't put much stock in the cross model comparison. Yep. Yep. Yeah. Do you understand how bad this is? You can now trivially spin up a bot that just monitors patches going into Linux and checks if they might be a security thing. And now you have early access to potential vulnerabilities and the ability to exploit them as well. Do you think these AIs aren't smart enough to write an exploit that takes advantage of the thing patched? Let's be realistic. Obviously, they can. And that's the problem. Going from patch to exploit used to be difficult because you would have to first identify that the change is a patch for a security thing. You then have to figure out what layers that patch is trying to fix and what potential exploit might be able to take advantage of that. Then you have to build set exploit and then distribute set exploit. We're talking about exploits that can be triggered as simply as running an npx something command or in the Python world a uvx something. Like these exploits aren't that complex. The amount of times I run random npx commands in a given day is probably far too high. This is the problem. And if these patches exist in the kernel code but haven't been shipped out to your specific distribution yet, you're [ __ ] Because again the people being disclosed in this case are Linux security engineers. People who work on security on the kernel not people who make our distributions. The people who maintain Ubuntu the people who maintain Arch Linux the people who maintain Cashios or Mint or Red Hat or any of those things they aren't disclosed on these security issues. They might privately be sometimes if some Linux security engineer thinks it's important enough to do it and they skirt the normal process to do it. But the distribution maintainers are not made aware of these things. They are just asked politely, please keep updating the kernel because they have no idea. They're not part of the process cuz they don't maintain the kernel. So that means everybody building on top of that is also kind of screwed. And this is just in Linux, by the way, which is far from the only thing being hit with this stuff, by the way. It's pretty absurd how much can be hit with these things. Couldn't the distribution builders and maintainers do the same thing that the attackers are like monitoring git commits and articles and trying to figure out how bad stuff is? Yeah, but I don't think that the maintainers of random Linux distributions should have to think like hackers about how to get early info on what patches are important to ship fast. That would create a lot of probably disdain between the maintainers of the distributions and the Linux kernel authors and maintainers as well. This is kind of the problem though. The whole timeline's collapsed from a thing that used to take months if not years to a thing that takes hours and the number of people who can partake in it went from very small to n infinite. And again, they are far from the only ones who have to deal with this. We are seeing this in the JavaScript world as well. Just before I went live, Socket discovered that 84 Tanstack packages had been compromised. It's my belief that the Tanstack team also noticed. Public details are coming out soon. I they might even be out by now. This attack was a very niche CI caching exploit that allowed for the attacker not to infiltrate the tokens to push to npm, but to file a PR that would do it on their behalf. Socket has since found another 121 compromised packages across 84 names. So, this is hitting a lot of people. Jesus Christ. I It's over. We're not even talking about the Versel hack or the Canvas hack or all the other major ones. I know of a couple that haven't been disclosed publicly yet that I'm lucky enough to have been early on that I could get screwed if I share. But thankfully the ones I know of aren't affecting users directly otherwise I would absolutely have like broken embargo and shared. But there are the number of companies that we believe to be better than this that are being hit shows just how severe these problems are. This is really really bad. I see a lot of people being skeptical about how supply chain attacks are related to AI. Do you think these things are trivially automatable without AI? Do you think the number of people who are able to do these types of things that would do it maliciously instead of like working for a security company is that high? The potential to do these things has escalated massively because of AI. The timelines have collapsed because of AI. The level of skill necessary to do it is way lower because of AI. And the ability to discover things like the patches that are being filed has become much easier because of AI. Anything that required a lot of attention from talented people over time can now be done in a for loop. That is scary. And I've been thinking a lot about what does this mean for everything from open-source to hosting servers to local systems to local networks to what happens to my local like elementary school when they get pawned in the C canvas hack occurs to what happens when more hospitals get ransomwareed. Like what happens in a world where we have to assume every single piece of software we use has already been compromised. I want to go down two paths with this one. And reminder, I am teetering on psychosis with this stuff. It's really really bad like keeping me up at night bad. I'm going to talk about what I'm doing and I'm also going to talk about what can be done like industry level. We'll start with this. We'll do the what I'm doing in a little bit. So what can we actually do here? Well, let's look at the problems we have. Only well-paid experts could find exploits before. The 90-day disclosure process used to be enough. And going from patch to exploit is hard. We need to fundamentally change how we operate in software in order to restore some sanctity of these three key things in order to build new ones. The first one's dead. That's just kind of over. There are efforts to reduce this reality. things like Mythos being private and not able to be used publicly, like you can't just hit the API and do things on it, as well as Opus 4.7 getting lobbomized super hard, so it can't really do anything security-wise. Those are kind of helpful, but we're also nearing the point where open weight models can figure these things out, too. Like, I would be really surprised if I pointed something like Kimmy K26 at this commit for copy fail 2 if it wouldn't be able to figure out how to exploit it. Omen weight models can do enough of the work for parts two and three here that this is going to change and the level of exploits being discovered is incredibly high. So knowing that one is effectively dead, which it is, how do we deal with two and three? How do we restore some semblance of these ideas? Well, first we should talk about this 90-day disclosure process. There's a couple problems with the disclosure process. The first is that not everybody who should be is disclosed. This is like the Linux distro maintainers I was talking about before as well as people who are like the IT teams at various companies. There isn't a good process for them to be informed beyond the information going public. There's just two tiers. There is disclosed which is the maintainers and not the maintainers of the distros just the maintainers of the specific thing that's been exploited. Nobody above or below them gets to know. And then there is everyone else. We need a new tier between these. We need trusted actors as an in between. People who have been verified, who are only using devices that we have somehow validated are as secure as they can be to our knowledge that these people have gone through some security process, have been audited, have like shared their socials, ids, something like that. We need an ability for companies and for maintainers of important things to be included by the disclosed parties in order to know the severity of a thing ahead of time without it being publicly disclosed. We need an in between window here because previously we just relied on how long it would take for bad actors to exploit the things and that time has been reduced to nothing. So we need a new tier of people who are affected by things that can be disclosed about stuff. This could also potentially be a way for open-source to make more money. It would make a lot of sense for a company like Microsoft to have to pay to get certified by the Linux maintainers in order to get this information. We have to do something like this though because we can't live with a pipeline where the people who make Ubuntu get disclosed at the same time as North Korean hackers do. That doesn't work. We cannot possibly survive long in a world where the people who are making the update we all need to install discover this information the same moment that the hackers do. While the hackers might not move as fast as the maintainers of those essential pieces of software, they certainly move faster than you and I do actually updating our systems. So, we need more lead time. Everything we do here is attempts to get higher lead times. This is just the start, though. And here's where I'm going to start saying things that are going to piss off a lot of people. Open source needs to change fundamentally. This hurts. I hate this. There's a lot of reasons for this. And I'm going to give a really weird example. Just hear me out, guys. We're going to talk a bit about Claude Code and how its source code has now leaked twice and how absurd it is that they have yet to open source it. There's a handful of reasons why the Cloud Code team has chosen to not release their code as open source. This obviously includes things like the security issues that could be discovered if the source code is leaked. We now have the source code. There wasn't much there. It runs on your machine. It's running in bun. It's relatively fine. The main thing they're actually concerned about is people seeing incomplete and experimental stuff that they're working on in cloud code. There's many times that they ship a new feature that is only accessible to employees or disclosed parties that they're testing out and then if it doesn't work, they deprecate it. But people are going to see these things and get really excited or maybe if it's open source, they're going to try and add them in themselves. I'm hypothesizing based on my knowledge of the team and the people I've talked to on it. But I would imagine that in a world where it's trivial for them to split their source, where there is the open-source version, which is their blessed source, that has all of the things that we use in our public version, but they would sometimes release updated versions that were not open yet. And this not open yet version would be what they are publishing maybe as an alpha or a nightly. And then when it hits a certain threshold of confidence or they clean it up or they are ready to distribute it, they then push it out into the open source version. There are companies that already do things like this, having a private fork of their repo and just upstreaming changes once they have a certain cadence, release cycle or level that they are comfortable with doing that with. I think we need to go further. I think we need a better GitHub, as I've said in multiple videos now, but a GitHub that has a better idea of granularity in openness where the project can be open and everything you need to build a version of it is open, but we can stage new features. We can stage certain files. We can stage and hide certain PRs. We can do releases that are public without all of the code being public yet on a cadence where we can share that code later. Maybe you share some of it early to people who are in this trusted actors group. What I'm imagining is a flow something like this. Step one, security exploit is found in a project like Linux. Step two, they patch it and decide what the rollout will look like and how much they should or shouldn't publicly disclose at this time. Step three, they ship this change on their private semi- temporarily closed staging branch. Ship a new build of the kernel. And then step four, notify the trusted actors, the people who are maintaining these different distributions, saying, "Hey, we have this change that we just shipped. We haven't shared the code yet. Take our word for it. This is a security issue. Get it out ASAP." And if some of those maintainers can't for some reason, guide them through the process of guarding from it on a different level. Once it's determined that a sufficient level of distribution has been reached for this secured version of the software, they can then put out the public notice and change these patches from being private to public. And even then, this is only a temporary fix. Something like this would be massively complex from how open source code is licensed to how the platforms distribute it to how you validate and verify people that are these trusted actors that are between the two groups. There is a lot of complexity here. And I know that I'm proposing something that seems insane, but I think doing nothing is more insane. Git doesn't work this way. Apache licensing doesn't work this way. MIT kind of does arguably because it doesn't really care too much about what is and isn't public. It just you do what you want. But still, like none of the systems we rely on today are built to allow something like this. But none of the systems we rely on today were built to handle the problem that we are currently experiencing. And we have to choose. Are we willing to change how we think about open source in order to address the impending doom that we are already experiencing? Or do we say this is too hard, pretend the problem's not that big, and watch as the entire world loses all trust in open source software? Because I do think it's one or the other. I don't think we have an in between here. So, I'm going to talk about what I'm doing and how I'm thinking about this in my own day-to-day. The first major thing, and this hurts, sucks. Treat all systems like they are compromised. At this point, I'm just assuming all of my private information is public. I'm a little early to this because I'm a semi-popular person on the internet with a very technical audience that loves to [ __ ] with me. So, I'm used to having to treat all data as semi-public data. I'm going further with it, though. I think a lot of people are still in the state of how do I protect the things I care about from being leaked or stolen? I'm past that point. I'm assuming that everything I have has been leaked and stolen. What I want to prevent now is ransomware style attacks. I expect lots of people have my data now. It sucks, but that's reality. I'm worried about the opposite. What happens if the only copy of my data is owned by someone else? What happens if my pipeline, the things that are important to me and my team, like my YouTube channel or all of the assets that we rely on or all the databases that track all of my deals with all of the brands that we work with and how far along we are in those? Like what happens if my data isn't compromised and ripped, but is destroyed and like taken from me? This framing from NC is great. If you assume the killer's already in the house, you'll have a better time. It means you have to go kind of crazy with how you do things, but this isn't even zero trust anymore. We're at like negative one trust. You just have to assume everything's already been compromised. So, what do you do once you've assumed such backups? A lot of them. I'm nearing the point where I'm going to buy another Synology just to have a local offline backup that is directly or just an external device to my main Synology that I pull offline and only plug in once every two weeks or something along those lines. Like I I don't know what else I can do. I'm doing offline backups in other places. I'm sending drives to family members that have important data. I am backing up things in all the places I can. Air gapping is just getting started at this point as crazy as that is. But we are actually at this point now where we have to treat everything like it's already been compromised. It's risky to run npx on the same box that you have one password installed on. Now it's bad. But the biggest thing, and this one I've already had to do because of being popular on the internet, but we all need to do talk to your [ __ ] family. Nobody understands the severity of what's about to happen, much less you're in my parents. I have had to spend a lot of time explaining these things and my parents have been having a great time saying they were right and I was wrong for thinking that software was the future of everything and it is and I still believe it. This is everything from setting up safe words to your family to verify your identity, making sure they're aware of the fact that like a phone call that is your voice talking about things that they know you would talk about doesn't necessarily mean it's you, even if they have your phone number. This is things like explaining how SIM swaps work and helping them protect their lines from it. This is things like making sure they have paper backups of important documents and data like things that they're getting from their landlords or things that they have about their property, sales that they have for their cars and their other expensive things. You should just ask them outright, if all of your computers stopped working today and all of the data on them vanished, what would you wish you had a backup of? And help them back up all of those things. I have one last thing I want to talk about to try and ease stress a little bit. What if I'm wrong? What if my analysis of this is overreaching? Like what would that look like? What pieces of information would it take for me to rethink this and realize I am just overreacting? This is the thing I always try to do when I have a strong take or stance on a thing. What pieces of info would convince me I am not correct on this. The first thing, and I really hope this happens, the CVE whirlwind winds down. We're currently seeing a massive uptick in the number of these types of security issues. All of the ones I covered at the start of the video are just the last week or so. And it's going to get worse, I believe, at least. But it might not. It feels like every project has dozens of these security issues, but it's possible they only have like 10. It's possible some of them have none. For every project that's been exploited 10 times, like the Linux kernel, there are some really essential ones that haven't been exploited at all yet. It's quite possible all of these were just lowhanging fruit issues that could have been discovered at any point. And all that changed is we took five years of discovery and did it in three weeks instead. That is entirely possible. And what we will see if that is the case is the number of these public incidents is going to go down rapidly after we hit all of these specific issues. If it turns out there's only 10 problems that can be discovered by AI in the Linux kernel and we've already found eight of them, then we're two away from not hearing about this again and that would be great. That said, when you look at the number of CVEs being created per month, not looking great for this belief. If you think that drop looks good, it's because we're only a third of the way through the month. Don't worry, it's going to go up. It's probably already there. But hypothetically speaking, it's entirely possible that this winds down and we can stop talking about this and worrying about it. Next potential path that could save us and keep me from feeling like I was correct about this is if maintainers start to get there first. If they find more of these things during their own development cycles and prevent these types of bugs from merging initially or patch them before anyone even knows about them, those things could well happen. In order to do that, they're going to need a lot of money for a lot of tokens and they probably need unlabemized versions of those models. OpenAI just put out this announcement for Daybreak, which is safer software resilient by design. You can request vulnerability scans from OpenAI to go over your projects and find potential issues using their models in specifically 5.5 cyber which is not publicly accessible. Daybreak is the first glimpse of sunlight in the morning. For cyber defense, it means seeing risks earlier, acting sooner, and helping make software more resilient by design. Starts from the premise that the next era of cyber defense should be built into software from the beginning by not only finding and patching vulnerabilities, but being resilient to them by design. So this is the whole like we need to design software to have fewer of these types of things. That means more software being written in Rust and not in languages like C++ so that we have memory safety to prevent a lot of these categories of exploits. That means things like building systems in a way where we're not accessing our entire database from the client which is how all of these superbase exploits and firebased exploits happen. This means at our core designing better primitives and then building better architectures on top of them to prevent these classes of issues from occurring as aggressively as they have been happening. Hopefully I made the point here. If we change the culture quickly and aggressively enough and the labs that are making these AI tools that make such a big risk really put their money where their mouth is and assist the maintainers who build everything in rethinking their platform to make more secure software from the start. that will help a lot. But the cat-and- mouse game that software security always has been just got a lot faster moving in a way that is dangerous. On the topic of keeping your things up to date, I just got notified by NMG that uh Tahoe has a bunch of security patches in the latest update 26.5 fixes 79 separate CVEes across Mac OS. 79 in one release. I'm guessing that they got Mythos access, but also a lot of these disclosures aren't from internal people. So maybe this is just what others are finding. Oh, this one is with in collaboration with Claude. How many of these are in Cloud with Claude? Okay, only two of them directly site Claude and Anthropic. Regardless, patch your OS. This is bad. Oh, on the note of talking to your family and what you can do, keep everything up to date except packages. Wait a day for this. kind of insane to have that disclosure, but it's important that you keep things like your operating systems as up to date as possible, that you keep an eye on the dependencies you rely on, things like Nex.js, things like Node.js, things like all the stuff that we build on top of, but also that you're not installing every single dot update because sometimes those are supply chain attacks. So figuring out how you balance this out, how do you make sure you're updating the right things at the right time? Yeah, this is a conversation we all need to have. And somebody in chat just said wait a day. No, wait a month or two. Uh, you're about to get pawned really [ __ ] hard because a lot of security patches get released and then exploited a day after the release goes public. Good luck. Considering how many security issues just happened in Nex.js and React, if you're not keeping those up to date, you're kind of screwed. You have to figure out how you balance this yourself. And I'm not saying that we should all move to closed source software. I'm certainly not even insinuating that. I think open source is more important now than ever. We need to rethink the way that we trust the code that we install and run on our machines at a fundamental level because we don't know who's actually sending that code there anymore. And the things that code can do are things that we are just discovering in those same moments. I hope I have done my due diligence here to instill some fear in you guys because that is the goal. I first off just don't want to be alone in fearing all of these things anymore. But I also do want to use my platform responsibly to make sure you guys all understand the severity of where things are going and how fast trust is about to erode across the entire software ecosystem. We are no longer in the everything's about to change era. We're past it. It has changed. I don't think enough people understand the severity of where we're at, which is why I'm making this very controversial, spicy video that I'm sure is going to be loved deeply by everybody in the comment section. But yeah, things are bad. I wanted to talk about it because I don't think anyone's talking enough about just how bad they've gotten and I don't want to be insane alone. So yeah, I got nothing else. Stay safe. Keep your [ __ ] up to date unless you're keeping it too up to date and then be careful and you see how insane this all is. Hopefully. I'm going to go crazy. I'm going to go relax. Have fun nerds. Bye.