Close call, nevertheless, it's silly to keep that commit on the release page.
steve_taylor 2 hours ago [-]
It's silly to not have rewritten it out of git history.
sigotirandolas 43 minutes ago [-]
Yeah. A git bisect can still hit it.
It definitely doesn't inspire confidence in the project taking security seriously.
(Also the "write-up" is almost surely a "Claude-up", though it appears generated by someone external to the project).
andy_ppp 24 minutes ago [-]
They still have the opportunity to remove it I guess?
yuvalkarmi 2 hours ago [-]
This is 3 weeks back, folks. It WAS real repository compromise - it made it to Zod's main, but not to npm.
On September 21, someone used Colin's git credentials to push this compromised code into the project, Colin caught it, and reverted it that same day (PR #6620). He subsequently did release 4.6.6 on October 11, but it did NOT contain the infected code.
Btw, Zod wasn't the only package targeted - same attack was attempted against standard-schema and nub. Nub DID make it to npm, but npm's malware scanning blocked it.
Looks like a legit (well, illegitimate) attempted supply-chain attack, but no actual Zod release was compromised.
Rapzid 2 hours ago [-]
Viewed through the lens of Zod's responsibilities and processes I'd say a release was absolutely compromised. They cut and submitted a compromised release to npm; npm just happened to block the publishing.
nowhere in gp's comment do they claim it was published
sdthjbvuiiijbb 2 hours ago [-]
The comment you replied to meant never submitted for publishing.
>They cut and submitted a compromised release to npm; npm just happened to block the publishing.
The point is that this is incorrect. A compromised release was not submitted to npm. It didn't make it beyond the git repo.
calyhre 1 hours ago [-]
It claims a release was sent to NPM, and this is not true. The maintainer of Zod made sure even this kind of attack could not proceed with a publication. The comment I answered to is dismissing these efforts put in place by Colin.
Might is pretty tame, it is infected - EDIT: title was changed, it said "might be infected".
The malware seems to inject some JS payload to execute when zod is installed, by fetching it from an ethereum smart contract (if I understand it correctly).
Interestingly, they added the `preinstall` key (that is supposed to run the malicious script when installed) under the package.json root, and not under `scripts`, so from what I can tell this wouldn't run on install.
Otherwise, yeah, this seems like a stage-1 loader for fetching and running a payload off the Ethereum mainnet.
nicce 3 hours ago [-]
Great reminder to always disable these scripts unless going through the hassle to verify if it does something absolutely useful.
2 hours ago [-]
hizlikovboy27 2 hours ago [-]
I have many projects using this library. do u think the situtation is urgent, a code red?
I will need to talk to clients accordingly.
ralusek 2 hours ago [-]
Never made it to npm you're fine
citbl 3 hours ago [-]
This is so bad it doesn't even try to hide itself.
throwawayy6767 3 hours ago [-]
What are we looking at exactly? Gia Tan situation? Prompt injection?
MisterMunchkin 3 hours ago [-]
That is 100% a compromised repo. It's a malware downloader.
I feel like they could have done a better job here. Having just a few changes, one of which is a huge blob of blatantly compromising code, is just too obvious.
The URLs are interesting, I don't do anything in this area but I didn't know that you could use the blockchains to hide your command and control URL, in a way that allows you to remotely update the URL whenever you want. It turns out there is a use for blockchain! Making control URLs immune to takedowns!
2 hours ago [-]
eviks 2 hours ago [-]
> colinHACKs
name checks out
blueblazin 3 hours ago [-]
How is this even possible? The change is small and literally has an ethereum URL in the code changes. How did it go through?
ozyschmozy 2 hours ago [-]
From the repo owner:
> Seems like a git push credential of some kind was compromised, not an npm or GitHub token. Still working with the GitHub team to get some better forensics on what/how. The attack consisted of malicious commits and tagged pushes to main.
So it didn't go through review, it was pushed straight to main. It also seems their publishing pipeline was already secured against this sort of thing:
> Zod's release flow was already secured against kind of attack via trusted publishing and a dedicated GitHub environment for secure deployments. Zod's release CI worked as designed and was already secure against this; NPM's malware scanning didn't prevent any malicious here.
rfgplk 3 hours ago [-]
LGTM
3 hours ago [-]
erzhan89 3 hours ago [-]
malicious remote-code loader
SquidJack 2 hours ago [-]
[flagged]
rfgplk 3 hours ago [-]
[flagged]
whstl 3 hours ago [-]
This problem definitely exists in C++ or Rust.
The solution in those languages is either to use something like serde validator, garde (for Rust), or go all the way to protobufs... or write your own data validation/parsing by hand.
Rust and C++ don't even have a Javascript deserializer.
oraro 3 hours ago [-]
Agree with you on it being the fault of the ecosystem. But, Zod is pretty good for parsing (rather than validating). It is IMO what makes TS (or should I say Zodscript) very successful
oraro 3 hours ago [-]
classic crypto people doing classic crypto things
rarisma 3 hours ago [-]
Yep, def looks bad.
Just pasted the code into claude to try and decipher the minified js and looks like it tries to find the server via the blockchain? and then download further stuff from there.
SlightlyLeftPad 3 hours ago [-]
Don’t even need to go that far, it refers to ethereum in plain text.
https://github.com/orgs/community/discussions/208477
It definitely doesn't inspire confidence in the project taking security seriously.
(Also the "write-up" is almost surely a "Claude-up", though it appears generated by someone external to the project).
On September 21, someone used Colin's git credentials to push this compromised code into the project, Colin caught it, and reverted it that same day (PR #6620). He subsequently did release 4.6.6 on October 11, but it did NOT contain the infected code.
Btw, Zod wasn't the only package targeted - same attack was attempted against standard-schema and nub. Nub DID make it to npm, but npm's malware scanning blocked it.
Looks like a legit (well, illegitimate) attempted supply-chain attack, but no actual Zod release was compromised.
>They cut and submitted a compromised release to npm; npm just happened to block the publishing.
The point is that this is incorrect. A compromised release was not submitted to npm. It didn't make it beyond the git repo.
I didn't study what packages/mini/meta.test.mjs is doing in particular but it's not looking great
The malware seems to inject some JS payload to execute when zod is installed, by fetching it from an ethereum smart contract (if I understand it correctly).
Don't forget to flag the version on npm.
EDIT: looks like the update never got on NPM: https://news.ycombinator.com/item?id=50053253
https://github.com/colinhacks/zod/commit/10dda3a3a4bc76ed0bf...
Otherwise, yeah, this seems like a stage-1 loader for fetching and running a payload off the Ethereum mainnet.
I feel like they could have done a better job here. Having just a few changes, one of which is a huge blob of blatantly compromising code, is just too obvious.
The URLs are interesting, I don't do anything in this area but I didn't know that you could use the blockchains to hide your command and control URL, in a way that allows you to remotely update the URL whenever you want. It turns out there is a use for blockchain! Making control URLs immune to takedowns!
name checks out
> Seems like a git push credential of some kind was compromised, not an npm or GitHub token. Still working with the GitHub team to get some better forensics on what/how. The attack consisted of malicious commits and tagged pushes to main.
So it didn't go through review, it was pushed straight to main. It also seems their publishing pipeline was already secured against this sort of thing:
> Zod's release flow was already secured against kind of attack via trusted publishing and a dedicated GitHub environment for secure deployments. Zod's release CI worked as designed and was already secure against this; NPM's malware scanning didn't prevent any malicious here.
The solution in those languages is either to use something like serde validator, garde (for Rust), or go all the way to protobufs... or write your own data validation/parsing by hand.
Rust and C++ don't even have a Javascript deserializer.
Just pasted the code into claude to try and decipher the minified js and looks like it tries to find the server via the blockchain? and then download further stuff from there.