It just keeps getting worse
Chapters7
Describes the mini shy halud worm that hijacks OIDC tokens to publish malicious package versions across CI/CD pipelines and major packages.
Security incidents like Shy Halud show how dependency chains and CI/CD trust can be hijacked; the fix may lie in self-contained tools and careful package management choices.
Summary
The PrimeTime's latest talk dives into the Shy Halud worm surge and the broader tension between convenience and security in modern ecosystems. The host emphasizes how a compromised npm package can hijack CI/CD workflows, signing off malicious releases that propagate across TanStack, Minstrel AI, OpenSearch, and more. He references the worm’s method—OIDC token hijacking and GitHub Actions cache poisoning—highlighting how attackers ride the trust built into automation. Throughout, he reflects on the personal evolution from relying on sprawling dependencies to craving self-contained tooling, drawing on Odin as a beacon of a battery-included language experience. While railing against the fragility of dependency-heavy stacks, he also entertains pragmatic PSAs like using PNPM, enforcing minimum release ages, and blocking install scripts by default. The monologue pivots from a security rant to a philosophical meditation on programming ecosystems, touching on Rust, Go, and the idea of vendoring or self-hosting where possible. He teases Odin’s lack of a package manager as a feature, not a bug, and envisions a future with fewer dependencies if tooling could be more holistic. The piece closes with a candid invitation to the audience to engage, question, and consider whether a language with everything included could be the antidote to dependency chaos.
Key Takeaways
- Shy Halud and related worms hijack CI/CD by compromising package versions and signing off malicious releases, enabling rapid, widespread infection across ecosystems.
- High-profile packages like TanStack broke due to dependency-chain compromises, illustrating how one weak link can cascade through thousands of projects.
- Blocking install scripts by default, vendoring dependencies, and hosting self-contained toolchains are practical mitigations discussed as countermeasures.
- Some ecosystems (e.g., Odin) advocate battery-included design to reduce dependency bloat, while others stress that dependency proliferation is a fundamental risk of modern packaging.
- There's a recurring theme that the ease of pulling in dependencies comes at the cost of security liabilities and maintenance burden—ry to review code remains surprisingly low among developers.
- Beyond JavaScript, parallel vulnerabilities hit other ecosystems (Ruby gems, etc.), underscoring a cross-language supply-chain risk.
- The host muses on a future where fewer external dependencies and more integrated tooling could simplify and harden software development.
Who Is This For?
This video is essential for frontend and backend developers worried about supply-chain security, DevOps professionals managing CI/CD pipelines, and language enthusiasts exploring battery-included design versus modular ecosystems.
Notable Quotes
"This is effectively what happened yet again. Now, I want to make like a rant here."
—Sets up the speaker’s combative mood and frames the security incident as a recurring problem.
"Block installation scripts by default. Super duper duper important."
—States a concrete mitigation discussed in the talk.
"I want to finish off this game which will end up probably being something like 100,000 plus lines of code with zero dependencies."
—Illustrates the allure of a battery-included approach and the speaker’s personal experimentation with Odin.
"Package managers are evil."
—References Ginger Bill’s view used to frame dependency risk (cited in the discussion).
"If I really had to bring in something, I could vendor it in myself and be like, 'Okay, I need this one thing.'"
—Describes the practical workaround of vendoring to reduce external risk.
Questions This Video Answers
- How does Shy Halud spread through npm packages and CI/CD workflows?
- What are practical steps to harden a Node.js project against supply-chain attacks?
- Is a battery-included language like Odin a viable alternative to modern package managers?
- Can vendoring dependencies effectively mitigate dependency-hell and security risks?
- What are cross-language supply-chain risks seen in npm, Ruby gems, and other ecosystems?
Shy Haludnpm securityCI/CD compromiseOIDC token theftGitHub Actions cache poisoningTanStack packagesRust BuildRSPNPMself-hosted registriesvendoring dependencies,
Full Transcript
All right, everybody. I feel more vindicated than ever. I feel like I actually have the right answers here. I feel like I can see around corners. I was right. My hate of the JavaScript ecosystem was not unfounded. Yet again, we are having more and more security issues. Now, this one just happens to come with a new flavor. Today, it is yet another worm. If you're not familiar with how the worm works, effectively someone gets compromised somehow and then packages get overrided and released in which when you install it, it executes a build script in which then goes and installs on your system a bunch of bad stuff, attempts to steal stuff, or maybe it doesn't do anything and waits until it's back on CI/CD.
And then when you go and publish it goes and takes your stuff and then keeps on doing this like forward progressing always publishing new versions of all the packages constantly spreading throughout the universe. Now this particular one is called mini shy halude because it didn't affect as many packages as the full shy halid but it's the exact same type of worm. It ended up affecting a very highprofile npm package the tanstack 42 packages from tanstack. That's a lot. It also affected minstrel AI, UIP path, open search, guardrails AI, Draft Lab, and others. Effectively, how it worked is that it hijacked an OIDC token from the action runners and poisoned the GitHub actions cache.
This allowed them to publish malicious versions through real CI/CD pipelines, which means that anybody looking at the versions, it would be signed off and being like, "Hey, yo, this release, it's good. Don't worry, this is from an authoritative source, so you don't have to worry." So, this is effectively what happened yet again. Now, I want to make like a rant here. Okay, I'm feeling a bit filled with some hot energy and I just feel like it's it's time it's time for me to talk about things. And yes, part of this is going to be the classic, right?
You know, the classic, hey everybody, an old man's talking. Grandpa's the name, which is me telling you stories about the past, telling you how it used to be, and you guys going, "A cute grandpa. Why don't you go back to the nursing home, which by the way hurts a little bit when you do that, but you know, that's just that because, you know, just to give you a little bit of JavaScript lifetime for you. I've been working on JavaScript since before there was a npm and or there was a way to even build your JavaScript.
Typically what you did is that either you wrote it in one big file. You had a bunch of source includes or you would do the classic which is build your own build tool, make it all into one gigantic mega file and then put it forward in lots of global state. Absolutely fantastic. Along with your file, you'd always of course rely on jQuery cuz jQuery it's the best query. Okay buddy. Even my very first professional job I actually had to build my own bundler. I built it in Java. I know people. I was at a C house.
I built it in Java in a bundled Microsoft Master Pages JavaScript. Okay, do you realize the Do you realize the I seen? You've heard me mention G2I before for hiring great engineers quickly. But did you know that they have roles for full stack, front end, backend, iOS, Android, data science, AI engineers, platform engineering, site reliability engineers, product design, product management, and even security with security engineers, and security analysts. But what I did not realize is that they can help you build your entire team. We're talking about product management, project manager, designers, and engineers. The whole shebang.
So use my name when you reach out to them and get $1,500 off your first invoice. Out of breath for that one. I wanted to say all of that because again the whole grandpa thing. We're going to get through that. But more so uh I wanted to kind of paint this picture because I feel like we just got to have a good yapping. So I'm not going to really break down the technical details of how Shy Hollud mini version 3.0 actually happened. This isn't about this. This is more of a philosophical talk. Okay? Maybe a little bit more of a come to Jesus talk, a spiritual talk.
All right? Because this is what I see when I use npm. I see some pretty intense security. Okay, the npm is making sure nothing gets through. Okay, doing the utmost hardest work possible to ensure your safety and definitely not that. There's probably corporations right now that are being blackmailed and having their information stolen. But hey, whatever. Now, there's things you can obviously do. So, just kind of like some PSAs, you can always use PNPM. You can have minimum release age, meaning you don't get the newest libraries. But of course, what's the problem with the newest libraries?
If you don't get the newest libraries, you could be releasing stuff that has a major vulnerability. Let's just say Nex.js also had a huge problem this week. Or it's the inverse. You get the new libraries, you get the new security vulnerabilities. It's a real damned if you do, damned if you don't. Also, this is very, very important. Block installation scripts by default. Super duper duper important. By the way, if you're on Rust and you're probably like, I use Rust. Well, buddy, hey buddy, guess what? I hate to break it to you, but Rust has Build RS.
And if you download a package or you install a dependency, you're right. You're not had. But the second you build your project with a dependency, if it has a build RS file that's malicious, bam, you're had. So, it's inert to install, absolutely dangerous to build. So, pretty much the exact same worm theoretically could exist anywhere. I do like what Gurgley has to say about this entire like, hey, here's all the pros and cons. Here's the things that are good. Here's the things that are bad. Self-hosting your package registry is pretty interesting because you can choose what you want and don't want inside of your registry and how old or new they have to be.
Okay, you could pin versions, but of course, pinning versions often leads to a bit of problems. You still have to rely on the fact that the thing you're pinning doesn't rely on a version range that could be malicious for you. There's a lot of problems with it and unironically not even a part of this entire shy halude thing. Just yesterday, Ruby also pulled 120 malicious packages from Ruby gem. So this is not like some JavaScript problem. This is a larger problem. And by the way, the mini shy hello also went off and poisoned the pi package registry.
So it also is jumping ecosystems. But nonetheless, none of that really matters. The problem is a bit more broad. If you've only ever used like say the JavaScript language, you kind of have a certain view of the world. And this can even extend that if you've only ever used JavaScript and say Rust, you kind of have the same view of the world, which is all right, I have my base programming language. And inside of it, there's some conveniences around say strings and arrays and all that. But anytime I actually want to do something, I have to go and get a package.
Oh, you want a URL? Well, guess what, Buster? If you're in Rust, you got to get the URL crate. Oh, you want a JSON, stringify, and parse? Oh my gosh, you need Saturday and Saturday JSON, right? You're going to need multiple packages for that. You want async, you're going to have to have something special for Rust. If you want HTTP, you probably are going to both need something for Rust and you're going to want something for the JavaScript ecosystem, such as Express, Hono, Happy, whatever you're going to do, right? Allesium. Allesium nuts on your chin.
Damn, that's crazy. Okay, anyways, back to the story. Either way, anytime you want to do a thing, you effectively need to go and get a bunch of third-party dependencies. Now, these thirdparty dependencies, they often have the exact same thing. Hey, I'm going to build HTTP, whatever. Well, I'm going to go and rely on a URL package. I'm going to go rely on this certain async request thing. I'm going to go rely on this certain other thing internally. And so, even when you download a package, that package has many subp packages it depends on. That's why whenever you just start any modern JavaScript repo or start any Rust project that even touches the internet, you end up building like a 100 plus dependencies just to get off the ground.
Now, this is where the philosophical kind of debate starts because I just wanted to put that in your head because I think a lot of people, they don't really realize the world they work in. This is just always been the world that exists. And I'm not even saying that you're a bad person, a bad engineer, or any of that crap, right? This is just the natural state of working on the web is that you probably went from JavaScript, maybe you dabbled in a little bit of Rust, maybe you got a couple thigh high socks, maybe you had some very interesting questions and and conversations with your parents.
It's like that's just totally the standard ecosystem experience that everybody has, but there's other things in the world. I've been in the process of rewriting the Mordoria game in a different language because I really wanted to give something a little bit more run for the money. I wanted to use both JI J AI blow lang as some people call it on the Twitters and Odin. Now Odin is a C like programming language for the joy of programming. That's what it's called. And a very kind of cool part about Odin is that hey I want to draw textures and do 2D graphics.
Well guess what Rayib is just included. Now Raylib is obviously a C library blah blah blah blah has to do with graphics but it's a part of the language itself. When I run Odin, they have a vendored set of libraries which mean that I can also just type in vendor and I can do stuff with say libc, Lua, x11, curl, wom, web, GPU and that's kind of like an interesting experience because that's not the experience you would have in other ecosystems. This language in some sense is a complete language. It is a batteries included all the way.
So if you need something, it's probably already been implemented in the standard library or it's been vendored in in the case of Ray Lib or Lua integration, whatever you need for your game. This is a language not only built as a generalpurpose programming language, but designed to be extremely helpful to people doing graphics. And that's like kind of a unique selling perspective of this is that you actually have something that is meant for a job and it does it well. It's kind of like JavaScript. JavaScript was really meant for a job. It was meant to work on the web and that's why a lot of the, you know, initial API also has document which has, you know, get, you know, query selector, query selector all and has a bunch of ways to interact with the DOM.
But then it also became a general purpose language. And then that's where things just kind of got confusing. It never really kept on iterating and becoming more useful for the web because it never really knew what it was. And that's just the thing with Go as well. Just use Go. Yes, this is another one of those highly vulgar uh articles in which goes over the reasons why you should just use Go. And one of the big reasons down towards the bottom is that dependencies don't ruin your weekend. You can a you could add them fairly easy.
They're pretty one-dimensional or you can actually just vendor them in, meaning that they're actually copied into your project. And now this is where I'm going to say some things that are uh maybe a little bit more unique. I'm going to go off the person who actually created Odin the programming language, Ginger Bill. and he has an article called package managers are evil. Now you've probably seen me reference this I believe in the last two videos that I did on shy hallode and just the ecosystem of npm over the last 6 months ago or whenever it was.
I actually referenced this right here which is package managers are evil and one of the reasons why is that it really makes simple something you should take so much more seriously. Have you ever thought about that? like how much code you bring onto your system. This is the exact same problem we're seeing right now with skills as well. People are just dumping all these skills for their AI to use and some of them have a bunch of like hidden messages and ways to exfiltrate data from your computer just like how you know Shy Halude is out there exfiltrating all of your information.
It's the exact same thing is that we're just kind of inundating ourselves with so much information just to get started on something. We're not really thinking through the problems. We're not using an environment that's been tuned for the task at hand. Instead, we're using an environment that's not really tuned for it. And that's that's, you know, RIP JavaScript for all of its decisions. It never really figured out what it should have been. And even though the language is pretty fun to use, pretty easy to use. You can get quite a bit done. It is a major flaw that it never actually understood its purpose.
And so, one of the big problems we end up running into is this idea of automation of dependency hell. See, the thing about dependencies is every time you add a dependency, you're adding liability to your program, whether you like it or not. Interfaces change what makes it hard to upgrade. If there's uh security vulnerabilities, then you have to upgrade. You may have to upgrade to new major versions. There's all sorts of problems that are associated with it. It's just not the same thing. And when something's in a package that you download and use via npm, you don't really feel like you can touch it.
And often people never even review the code itself. In fact, I did a poll not too long ago that showed it was like 80 plus percent of people. Don't even look at the code that they're downloading all the time. And I would I would suspect it's actually probably significantly higher than 80%. The only reason why I have 80% on this channel is because we probably cover more gaming and system stuff at a higher rate than say a webdev channel. But I just kind of wanted to think about this which is what happened. Why did we change off of this?
Because when I was, you know, when I was a young man, when I got started programming, okay buddy, I used to go in and I used to choose very carefully what libraries I wanted included inside of my JavaScript. I remember one it was called like something along the lines of uh Touch tools. It wasn't better touch tools, which was a Mac thing. I forget exactly what it was. This is back in 2012. And I would go to GitHub. I would clone down the stuff and I would vendor in the exact versions. And then I would hand make edits to the things we needed for my company because this was still MIT licensed back in the day or whatever the very uh permissive license was.
But nonetheless, I actually had to kind of keep up with it. And was this bad? Was this a bad thing? When Bower came out and npm came out and Grunt came out, did we switch over and start pulling it in? Sure. But was it bad that we had to take a lot of thought before bringing in any dependency? Well, I'd say one big difference back then is anytime you had a dependency, it almost was itself dependency free because the mechanism of getting dependencies was well not very well understood and npm really hadn't taken a foothold.
So, anything you got was extremely one-dimensional which I think just ultimately created very different software 15 years ago than it does today. And should we move back to that day? Well, I do think that we are entering into a world where we're just going to see more and more of these shy haluds. And part of that is because I I mean, personally, I think that this group behind it, they have so much tokens and access to systems, we can't even fathom it. And so, every 6 months, they're like, "Well, should we hack them again, George?" And then George is, of course, very happy about this.
All right, George, let us send off the token the token scams again. and then off they go and grab everything. And I think this is just going to happen for the next I don't even know how many years. We're just going to be perpetually had for like every few months because of just how fast everything updates when a single package is updated. Potentially tens of thousands of downloads happen within just a few minutes going to all these different CI/CDs which then infect more packages and it just keeps on happening. Like I would not be surprised if right now the group behind Shyood does not have access to a lot of the major software companies right now.
Honestly, I refuse to believe that they don't because it's ridiculous with how much tokens they've been able to take. Any who, I know this was kind of a bit of a rambly video and I know it's like a little bit more high energy and there really wasn't that many jokes in this video, but I mean I just wanted to say all those things because you know there's part of me that realizes especially as I use Odin like wow this is really nice. I'm probably going to be able to finish off this game which will end up probably being something like 100,000 plus lines of code with zero dependencies.
I have a language, a build tool, and I have every last like thing I need to be successful completely in one item. And I'm just like, why isn't this the way for everything else? Like, this is good. This is what more experiences should be. I shouldn't have to like get an amalgamation of software just to be able to do the basic things. Like, this is what I want. This is what I want to see more because I I've been on both sides now. I like this side. I like this side a lot. And if I really had to bring in something, I could vendor it in myself and be like, "Okay, I need this one thing.
It does this one thing. My program wants it to do this one thing. Here we go." Like, and I'm just going to make that choice so rarely because of kind of the expensive nature because guess what? Uh, guess what? Odin Odin doesn't really have a package manager. I don't know if you know that. I can't imagine why Odin doesn't have a package manager. I can't imagine why does Ginger Bill not want a package manager inside of Odin. I don't know where I was going with all this. I just felt like yapping, you know? Like, have you ever had that urge?
I had the urge. I feel like I understand why a dog wants to bark because I I just feel the same thing just deep inside of my bones. Did you like this? You want to like set send me a signal that you liked it? press like the like button or make like a comment and tell me I'm completely wrong and just being an old man yelling at clouds or maybe I'm correct. Maybe having a language in which actually does just have everything included is the better way to go. The name is the primogen.
More from The PrimeTime
Get daily recaps from
The PrimeTime
AI-powered summaries delivered to your inbox. Save hours every week while staying fully informed.









