Hacker News Reader

Comment by yuvalkarmi | Hacker News Reader

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.

View on HN

The commit was still not only in git history, but also on the release page on github for 4.6.6: https://github.com/colinhacks/zod/releases/tag/v4.6.6

So I think it's not a great leap to think this commit actually made it to 4.6.6 on npm.

Good that it didn't though!

> it made it to Zod's main, but not to npm

Thank god. Zod reached like 350M weekly downloads recently.

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.

No it was never published. Only `nubjs/nub` was. You can read more on the write-up -> https://github.com/orgs/community/discussions/208477

nowhere in gp's comment do they claim it was published

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.

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.

This is not the case. Zod's release CI was not triggerable via commits/tags by design. It used environment-scoped trusted publishing, which requires a GitHub token with elevated permissions. No releases of Zod or Standard Schema were sent to npm. Their security advisory is very misleading in this regard, which is why I tried to clarify the situation in my comment. [0]

[0] https://github.com/orgs/community/discussions/208477#discuss...

Reply on news.ycombinator.com