This would have been completely avoided if you were using bun dependency vector locking in Nix.
That way instead of getting the vulnerabilities now, you get them later! The joys of computing!
Incident Report: CVE-2024-YIKES
111–120 of 187 posts
Re: Incident Report: CVE-2024-YIKES
#112Earlier quoted context omitted.
Not a chance. Far too funny, too well written, too terse while being densely packed with wit. I see zero signs of it being LLM-generated and lots of stuff LLMs have no way of doing. If I am somehow wrong I would salivate at a chance to see the input.
You don't even need to read past the first timeline entry. The name "Marcus Chen" is literally a meme within AI creative writing circles due to how often Claude defaults to that exact name when naming fictional characters.
Probably being used to enhance the humor, intentionally.
Re: Incident Report: CVE-2024-YIKES
#113> Day 1, 14:47 UTC — Among the exfiltrated credentials: the maintainer of vulpine-lz4, a Rust library for “blazingly fast Firefox-themed LZ4 decompression.” The library’s logo is a cartoon fox with sunglasses. It has 12 stars on GitHub but is a transitive dependency of cargo itself. I got a bit curious and here is an incomplete list of crates to compromise to be part of the cargo build and that already have a build.r…
-sys crates are just bindings and doing something else in them is highly suspect. The rest I recognize as being owned by a Rust maintainer like alexcrichton or rustlang itself.
> The rest I recognize as being owned by a Rust maintainer like alexcrichton
The issue here isn't Alex Crichton going rogue, but rather, some malware stealing his credentials to use them to publish more malware in crates.io
In this sense, the more well known and upstanding Rust developer, the higher the risk they will be targeted by such operations
Re: Incident Report: CVE-2024-YIKES
#114Earlier quoted context omitted.
Searching for CVE-2024-YIKES also provides a gallery of AI slop blogs that AI-rewrite the content of this post while being absolutely stone cold serious about it.
Currently a Google search for vulpine-lz4 gives a very serious AI overview.
Googling is no longer a reliable way to figure out if something is real or not (since, in this case, it just regurgitates the original article, including a couple slop blogs about it)
Re: Incident Report: CVE-2024-YIKES
#115left-justify !! LOL. History really does repeat its self. Remember left-pad supply chain security panic?
Re: Incident Report: CVE-2024-YIKES
#116Brilliant satire. So many gems.
> CI passed because the malware installed volkswagen
We need this to ocassionally make us stop and think about what we are doing.
Re: Incident Report: CVE-2024-YIKES
#117Earlier quoted context omitted.
-sys crates are just bindings and doing something else in them is highly suspect. The rest I recognize as being owned by a Rust maintainer like alexcrichton or rustlang itself.
sys crates are also mostly generated and lack a lot of eyeballs. Sneaking something into the build.rs of a sys crate would not be difficult and would land in the builds of everything downstream of it.
would not be difficult
Re: Incident Report: CVE-2024-YIKES
#118Earlier quoted context omitted.
-sys crates are just bindings and doing something else in them is highly suspect. The rest I recognize as being owned by a Rust maintainer like alexcrichton or rustlang itself.
> The rest I recognize as being owned by a Rust maintainer like alexcrichton The issue here isn't Alex Crichton going rogue, but rather, some malware stealing his credentials to use them to publish more malware in crates.io In this sense, the more well known and upstanding Rust developer, the higher the risk they will be targeted by such operations
With crates.io using GH as its IdP, I think there would be much farther reaching consequences to account pwning in that scenario. I agree, though, that the security model for crates.io is only as strong as the weakest link there, and would pray someone like Alex is using physical tokens or the like for his MFA and can't be conned by a well-crafted email.
Re: Incident Report: CVE-2024-YIKES
#119Earlier quoted context omitted.
sys crates are also mostly generated and lack a lot of eyeballs. Sneaking something into the build.rs of a sys crate would not be difficult and would land in the builds of everything downstream of it.
would not be difficult Surely that's why we see evidence of all these build script attacks, since it's so easy?
I had pondered the same thing about other package ecosystems in the past, in general. Now with the benefit of hindsight we can comfortably say that the absence of known (!) attacks doesn't really say anything about how relatively difficult an attack would be. Are -sys crates, or build script attacks, particularly potent? Who knows. When I did a cursory search, the only attempts I saw were at runtime rather than build time[1]. Which raises a good point; pwning a developer machine or CI box with a build script may be quite valuable, but if you might get that and prod with a runtime exploit, is the build time exploit that much more valuable? Guess it depends! (Of course, I personally think having at least optional build time sandboxing is even better than hoping it won't be valuable to attack.)
Of course, crates.io has surely had some malicious packages. (I'd assume it isn't all that unlikely there could be some undiscovered right now; it's definitely large enough for something like that to slip under the radar, even if it is relatively small compared to say, NPM.) But, I think it really hasn't had its XZ backdoor moment, its left-pad, where you really get to see how well it does or doesn't handle a serious challenge. Since I have actually not published on crates.io, I'm not really sure how the security posture is, but if it's more similar to other programming language repositories than it is to Linux repos, I dunno exactly why it would be hard to believe a high-level compromise is possible and could slip in (really, anywhere, be it a build script or otherwise.). Of course, "would not be difficult" is all relative. I'm sure many of these attacks are not really all that simple, but a lot of them aren't exactly groundbreaking either. It was well executed and took quite a lot of time, sure, but there wasn't all that much about the XZ backdoor that was novel. (Except maybe the slyness with which the payload was hidden in test files. That was pretty cool.)
[1]: https://blog.rust-lang.org/2025/09/24/crates.io-malicious-cr...
Re: Incident Report: CVE-2024-YIKES
#120Not a valid CVE number.