Incident Report: CVE-2024-YIKES
nesbitt.io
nesbitt.io
`from <key> import <value>`
And a custom import hook eating the error. To get value(s) for a given key, naturally we'd scan the module loader cache. Elegant.
Heh. I didn't even blink at that. I know a couple of open-source folks who actually packed up to buy off-grid farms in Portugal
obviously it's referencing the left-pad incident[0], and to 'justify' text is another kind of text manipulation[1]; but with the more common definition, i guess it's a joke about justifying something? The Left? idk
[0] https://en.wikipedia.org/wiki/Npm_left-pad_incident
[1] https://en.wikipedia.org/wiki/Typographic_alignment#Flush_le...
> Status: Resolved (accidentally)
> Severity: Critical → Catastrophic → Somehow Fine
for a real CVE report?
If a glance at the CVE number that isn't a number doesn't do it, a minute or less of skimming this article likewise reveals it to be satire on a blog that's actually pretty thoughtful when it comes to supply chain attacks.
Idk how else to characterize this except as a literacy problem. Learn to skim. It should be unacceptable to characterize a few minutes of reading as unbearable toil. If your time is really so precious that (although you can surf Hacker News) you can't spare 1-3 minutes to read, surely you have someone else to whom to delegate the responsibility of watching for supply chain attacks.
Why am I seeing this crop up over and over?
The implication that I don't know what I'm looking at, or that I don't know what security is (despite having a clean track record for about 15 years now) was a bit aggravating.
In fact, even months later, the lasting effects have been panicking over anything that is remotely suspicious. The most recent example was just a few days ago. Had just gotten on the plane to go on vacation when someone Liked the original "I've been pwned" post on Bluesky. I misread the notification as being a new message to me saying "You've been pwned" and started to panick. I'd have had no way to address it and it would have ruined the small chance per year I get to have a break.
The attack last year wasn't me misunderstanding security. It was the sum of many, many small things (my history with and perception of npm especially w.r.t. their security posture and poor outreach over the years, being stressed out overall, and being in a rush at that particular moment, and a few other personal things) coming together in a perfect storm that resulted in the attack.
I'm a security geek, a clean track record means much less to me than anyone would expect. The comment from the article mentioning that there was no evidence of exploitation explains why. I would never have noticed that implication, because I don't think it exists. (And it's completely unreasonable if it does), so that's your own deal... it's not a good conclusion to take from the article.
The only thing that matters is how much any given owner cares. Are they willing to go the extra mile to make sure things get done correctly. That's the best signal about if you can trust a project. Seems like you give a shit, so I wouldn't be too hard on yourself. The people that matter can tell, (everyone who can't tell is already willing to lie so they can be safely ignored!)
> In fact, even months later, the lasting effects have been panicking over anything that is remotely suspicious. The most recent example was just a few days ago. Had just gotten on the plane to go on vacation when someone Liked the original "I've been pwned" post on Bluesky. I misread the notification as being a new message to me saying "You've been pwned" and started to panick.
You haven't dealt with it yet, if you want to get your attention back so you can spend it on more important things than worrying about something from the past, you gotta talk to somebody. A therapist would help the fastest, but friends and family are often just as good.
> I'd have had no way to address it and it would have ruined the small chance per year I get to have a break.
Seriously, having been there myself it's not worth it... you're just allowing them to DoS your brain by allowing them to live rent free in your head. The only thing that matters is how seriously you take the remediation. Attention to detail, and the willingness to go the extra mile for security defects to tie up all loose ends is what matters. It's not your job to fix everybody's issue yourself, even if they don't or can't. You still have to enjoy life, or you burn out, and some idiot that doesn't care will take your place. Then they really win.
You're not responsible for the security or stability of anybody using nightly packages. (Only maintainer signed and tagged releases)
> The attack last year wasn't me misunderstanding security. It was the sum of many, many small things
so, a misunderstanding of how the little things actually impact security?
> (my history with and perception of npm especially w.r.t. their security posture and poor outreach over the years, being stressed out overall, and being in a rush at that particular moment, and a few other personal things) coming together in a perfect storm that resulted in the attack.
Those other personal things are the kinda thin that being able to enjoy a vacation make much easier. You can't help anybody if you don't put on your own mask first... Well... You definitely can, you're obviously trying to do now, but it's needless harder.
Npm, and the JavaScript ecosystem is a fucking joke. It's a mistake to blame yourself (or any maintainer) for how difficult it is to meet the bar for both security and accessibility. Worrying about the difficulty in consistentenly demonstrating the perfection required for security is a fool's errand, and your allowing the bad guys to get what they want by letting it live rent free in your head, it won't go away for as long as you worry about it more than you talk about it.
And I say all of that as the person who has multiple times, made the argument that it's perfectly fine to name an engineer and their decisions or incompetence as the root cause analysis in an official incident report. (Pilot Error is a thing): If I thought you were responsible, or had done anything wrong, I'd gladly blame you. Smart people don't care about mistakes, because they are always noise in the signal. I care about effort. People who give a shit are much more important and valuable.
Background here:
edit: actually more and more thing I'm recognizing as being entirely serious (ie benelovent worms :D); satire indistinguishable from reality
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.rs so it doesn't stand out to much:
flate2 tar curl-sys libgit2-sys openssl-sys libsqlite3-sys blake3 libz-sys zstd-sys cc
As a nice bonus - if you get rights for xz2 you can compromise rustup.
Fwiw at least they do track Cargo.lock
would not be difficult
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...
>>> 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.
>> Surely that's why we see evidence of all these build script attacks, since it's so easy?
> 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.
Given that you were responding to a critique of what seems to be fully conjecture with the argument that we don't know for sure that it's not feasible, it's not clear to me why that wouldn't be a sufficient defense of any claim of a potential vulnerability without regard for merit. You don't propose any alternative than ignoring the only hard evidence we have, so although you might not have intended it this way, it's not clear to me what discussion you could expect to happen with that standard of evidence other than throwing up our hands and saying everything is screwed.
But wait, that isn't what's on the table. Inserting malware into a build script itself is absolutely feasible; you can demonstrate that part locally. Gaining sufficient access to a developer or CI machine that has credentials to publish such malware to package repositories is also, well, feasible. If you are using GitHub Actions, all it would take is literally any action you run in any CI script in a job leading up to publishing getting pwned, a task that is easy if you can compromise any one of them due to the lack of a real way to pin actions, and because of vectors like the ever-enduring pwn request.
The unknown quantity is how easy it is. That part is hard to say, and also inherently relative. For me pulling off such an attack would probably be hard. For the folks behind the XZ backdoor? Well, I do not wield a crystal ball, but it sure seems like what they accomplished for that was significantly more than what would've been needed to pwn the Rust ecosystem. They didn't even need temporary access to publish a crate, they flat-out took over an upstream the old fashioned way; found a weak link and worked their way up the chain with social engineering and good old hard work.
What exactly makes you think the feasibility of pwning a crate is somehow up for debate?
> it's not clear to me why that wouldn't be a sufficient defense of any claim of a potential vulnerability without regard for merit.
You have inverted my logic. What I said was that the absence of an attack is not evidence of difficulty (or infeasibility).
> You don't propose any alternative than ignoring the only hard evidence we have,
What you have isn't "hard evidence" at all. It's not evidence in the first place. It is the literal lack of evidence.
This shouldn't be comforting. I suggest it shouldn't be comforting, because there is a period of time from whence a package repository goes online to its first major supply chain attack attempt, and you never really know when it will be. Crates.io is currently vastly smaller and lower traffic than NPM for example, so if you are looking for a vast number of potentially easy targets it is the wrong place to look. That may not always be true and to some attacker it may not matter as much. It isn't just inherently safe.
> so although you might not have intended it this way, it's not clear to me what discussion you could expect to happen with that standard of evidence other than throwing up our hands and saying everything is screwed.
The main takeaway is that hope is not a strategy. Will crates.io get pwned like NPM does periodically now? Probably. Can we do anything about this? Sure, lots of things, although I'm not sure people will love them.
- You could abandon a unified namespace/central repository and mimic Go's approach. Doesn't prevent compromise, but it helps avoid issues like typosquatting.
- You could require secure attestation of the build process. Don't mistake this suggestion as me vouching for it, but Bazel has implemented this for BCR.
- You could... Have moderated, curated repositories, possibly with graduated release channels like Linux distros do. Again... Could, not should, but it absolutely helps enable more scrutiny and time for things to bake. It's feasible.
- You could enforce reproducible builds with provenance information. This would stop someone from publishing releases that don't match the actual source repo, a technique often used in these supply chain compromises.
As for what Crates.io should do, I don't know. All I know is it would be a huge mistake to just do nothing and assume it won't get pwned due to the absence of attacks. Security will never be perfect. Best we can do is acknowledge this and continue to iterate.
Lots of npm supply chain attacks propagate at build time via post-install hooks, too.
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
It's great that there's so much momentum in fixing the glaring problems with supply chain systems like npm, but I'm concerned that we're entering a new era of security-related problems caused in large part by agentic development.
I'm not just talking about Mythos/Glasswing surfacing vulnerabilities in pretty much everything it touches; I think the way we're developing software, pulling in dependencies, and potentially losing human thought modeling of complex systems is going to lead to a lot of hacked together software and infrastructure that humans won't fully understand.
I hope in a few years we don't look back at today and wonder how we could have been so naive -- how we failed to actually plan for the long-tail of AI development in a way that doesn't solve problems by attempting to just use AI to rebuild complex systems.
But the article was funny.
Was it? I thought Zuckerberg coined this horrible phrase.
Even without the specific words, look to product teams debating tradeoffs of going to market vs. waiting for better security controls. They're pushing for faster product release every time, at pretty much every org.
https://www.snopes.com/fact-check/move-fast-break-things-fac...
Got me seriously laughing... Such a troll.
I know we're not in the era when a windows pc will happily run any autorun.inf and .EXE file found on an inserted flash drive or DVD anymore. But even so. What if it didn't even have any malicious data payload but somebody was shipping USB-A interface capacitor based usb killers?
https://www.slashgear.com/1819672/usb-killer-explained-kill-...
What if it did have data on it and came with a slick color brochure walking people through how to run the binary, or in a linux or developer specific audience, how to 'sudo' the ELF binary that lives on its filesystem?
[0] https://shop.hak5.org/products/omg-cable [1] https://darknetdiaries.com/episode/161/
That's almost 12 years now. A novice can now get ATmega32 USB devices Prime delivered. Not a cutting edge theoretical attack anymore but a basic tool in a every pen tester's toolbox now.
>"Root Cause: A dog named Kubernets ate a Yubikey
Ah, yes, irresponsible to get taken in by one of the well-known classic exploits. The 'ol "distract someone with a lottery windfall & make a dongle irresistibly tasty to another person's pet". When will people learn.
> CI passed because the malware installed volkswagen
We need this to ocassionally make us stop and think about what we are doing.
> who asked us to clarify that the fish shell is not malware, it just feels that way sometimes.
And unrelated to shells...
> The author would like to remind stakeholders that the security team’s headcount request has been in the backlog since Q1 2023.
I also feel seen by this.
As an alternative, it could apt-get or dnf install 'figlet' and then overwrite the contents of /etc/motd with 'all your base are belong to us' in extremely large ASCII art font.
Supply Chain problem(SCP)
Honest question. Commons, Guava, Spring, and more seem to take this approach successfully (as in, the drawbacks are outweighed by the benefits in convenience, quality, and security) in Java. Are benefits in binary size really worth that complexity?
And before someone says “just have a better standard library”, think about why that is considered a solution here. Languages with a large and capable standard library remain more secure than the supply-chain fiascos on NPM because they have a) very large communities reviewing and participating in changes and b) have extremely regulated and careful release processes. Those things aren’t likely to be possible in most small community libraries.
That dead code might have "dead dependencies" - transitive dependencies of its own, that it pulls in even though they are not actually used in the parts of the crate you care about.
In the worst case, you can also have "undead code" - event handlers, hooks, background workers etc that the framework automatically registers and runs and that will do something at runtime, with all the credentials and data access of your application, but that have nothing to do with what you wanted to do. (Looking at you, Spring...)
All those things greatly increase the attack surface, I think even more than pulling in single-purpose library.
Smaller implementations are also easier to review against malware, because there are fewer places to hide. You don't have to guess how a component may interact with all the other parts of a large framework, because there aren't any.
There are also practical Rust-specific concerns. Fine-grained code reuse helps with compile times (a smaller component can be reused in more projects, and more crates increase build parallelism).
It makes testing easier. Rust doesn't have enough dynamic monkey-patching for mocking of objects, so testing of code buried deep in a monolith is tricky. Splitting code into small libraries surfaces interfaces that are easily testable in isolation.
It helps with semver. A semver-major upgrade of one large library that everyone uses requires everyone to upgrade the whole thing at the same time, which can stall like the Python 2-to-3 transition. Splitting a monolith into smaller components allows versioning them separately, so the stable parts stay stable, and the churning parts affect smaller subsets of users.
Commons and Spring have spent significant effort to break themselves up in the past, and would probably come as aggregations of much smaller pieces if they could be started today with the benefit of hindsight.
> Are benefits in binary size really worth that complexity?
What complexity?
I guess saying "every project" has 5 dependencies might be somewhat hyperbolic (or at least domain specific) but it would be interesting to know the kinds of things they're talking about that haven't yet been uplifted.
“Personally for rust I’m a proponent of the foundation supporting a few core crates that go under the same audit procedure as the main rust language and give funding to the project to limit supply chain vulns. I don’t think the right answer is to remove systems like crates or npm. Crate and npm are a boon for many developers.”
This is my solution. We get the quality of a std lib without forcing it in the std Lib and without extra maintaining cost for the team
My argument would be that if a more featureful standard library could get Rust closer to the superior dependency culture of Go, it'd be worth it. As-is, Rust dependency trees are just wild.
Also, I think that your example of Go's breaking crypto changes misses the forest for the trees--the stdlib has been incredibly stable through its history, and the vast majority of packages just never have to worry about it. I'm honestly not aware of a language out there with similar adoption, featureset, and robustness. More to the point, I'm not aware of a language out there with a more reliable stdlib that permits the ecosystem to have small dependency graphs.
One of my other crates (getaddrinfo) requires windows-sys and libc which would be challenging to get rid of.
I like the idea of low deps but zero is tough
However, don't make the mistake of thinking that Rust has a small standard library. Read any Rust release and you'll see dozens of new APIs added with every single one. I'm tempted to paste the entire list of stabilized APIs from the most recent release for emphasis, but rather than making this comment three dozen lines longer, just look for yourself: https://blog.rust-lang.org/2026/04/16/Rust-1.95.0/#stabilize...
In particular, most recently the aforementioned release stabilized the cfg_select! macro for convenient conditional compilation, which obviates the popular cfg_if crate: https://doc.rust-lang.org/stable/std/macro.cfg_select.html
and you know what? I'm grateful to them all for leveling up my opsec, among other things :)
Kindly advice
The dreaded Marcus Chen strikes again.
https://www.reddit.com/r/ClaudeAI/comments/1o3b4q2/just_rece...
curl ... | bashAmateur.
curl | sudo dd of=/dev/sda
From a real repo, with 186K stars... https://github.com/obra/superpowers
Hacker uses AI to research countries without extradition to US.
Cops use AI to analyze ransom note. Unfortunately, because the note confidently states that Vietnam has no extradition to the US, the AI recommends paying ransom.
Vietnam's currency, the Dong, confused the AI..
Technically... that's not even a joke... that really is what kicked off this entire chain of events lol.
This post reads like an actual movie lol. Someone seriously needs to make one based on this.
It has everything:
the missing key that starts the chaos, the scam nobody sees coming, one tiny mistake turning into a full-on domino disaster, sleep-deprived people making very confident bad decisions, the guy who disappeared to a farm living his best life while holding a critical piece of the puzzle... and somehow, in the final act, a completely unrelated villain accidentally saves everyone.
Imma 100% watch it..
"... old laptop, and 'something Kubernetes threw up that looked important' were stolen from his apartment ..."
was related to:
"... enters his nmp credentials on the phishing site ..."
Then I suppose it is really interesting.
If I am somehow wrong I would salivate at a chance to see the input.
And actually I see it clearly now, it has a bunch of signs I have called out multiple times myself. (It is entirely made out of lists of various types, and never states an opinion.)
Just my ego getting hold of me because I didn't realize it on my own.
Whether (or to what extent) he uses AI to generate the content he posts is a valid question.
I agree with your earlier reasoning that this is far more clever than anything I’ve seen AI produce yet. Lots of AI humor is dad-joke level at best. If it is AI then he’s trained it on a hand-curated collection of top-shelf satire.
Pangram indeed claims the OP is 76% AI-generated. It has "high confidence" (EDIT: some parts are "medium confidence") that the early portions of the text were created by AI, and "medium confidence" that some of the later potions were written by a human. EDIT: I was especially dismayed to see that the dog might have been an AI creation :(
When I use the "supporting evidence" option, the main piece of evidence Pangram provides is the frequent use of em-dashes. Each timestamp is followed by an em-dash. Personally I think the em-dashes could be a copy-pasted em-dash or inserted by a markdown to HTML converter. nesbitt.io is apparently using Jekyll [0] - any Jekyll users know anything about this??
Pangram's "supporting evidence" feature also considers → and € to be "unusual Unicode".
Personally, to me it looks like the "supporting evidence" feature still needs some work because Pangram's AI detection is probably a lot more sophisticated than a grep for Unicode symbols. In fact the feature even has a notice claiming that "These patterns aren't used to determine our AI score; they help you see why AI text often reads differently."
As for the rest of the OP's content, it would be interesting to compare the Pangram results to a timeline of a real vulnerability. I tried doing so, but exhausted my free "Pangram credits" - apparently the first 1000 words of this article [1] about the log4j vulnerability is considered 100% human.
[0] https://github.com/andrew/nesbitt.io
[1] https://www.csoonline.com/article/571797/the-apache-log4j-vu...
the kubernetes reveal had me literally in tears
ahahaha like that fiverr cloudinary bucket leak that turned out to just be a UX issue, this has me rolling
and then become aware of each other
and then try to eliminate each other for decades
each escalating resource capture and writing new generations of better "AI"