colinmcd

Zod's releasing CI was never triggered and it was not vulnerable to this kind of attack. It uses environment-scoped trusted publishing, so a regular push credential is not enough to trigger releasing. There's a security writeup from the NPM team here[0], though it strongly implies that malicious versions of Zod and Standard Schema were caught by their malware scanner. That's not the case. The attacker was not able of triggering Zod's release CI in the first place. I clarified this in my followup comment[1] and asked them to pick more accurate wording to avoid unnecessary FUD like this.

It seems like a git push credential, probably an SSH key, was exfiltrated from my local computer. The attacker used this to try to push malicious versions of Zod, Standard Schema, and nub. The release workflows for Zod and Standard Schema were not vulnerable against this. (Nub was, however, a release run was triggered, and npm's malware detector did flag it and prevent publication.)

It seemed shady to scrub the commits from history, and it still isn't obvious that doing so is better from a security standpoint. But since there are concerns around git bisect, etc, I've done so anyway. v4.6.6 will lose provenance, v4.6.7 is being released.

Since I don't know exactly what else what compromised, I've also done a fresh OS re-install and rotated all creds present on the old machine at the time of the compromise. All my packages have been switched over to staged publishing, which requires 2FA for any release.

Ironically this likely happened due to some work on an OS-level sandbox for Nub's package manager, designed to limit the blast radius of malicious lifecycle scripts. The attack is consistent with an more primitive precursor to the modern Shai-Hulud-style worms. While working on the sandbox, an ersatz agent likely executed a compromised version of some package on npm in a test run. I had safeguards against this (filtering out any OSV-flagged packages, etc) but perhaps there's an undiscovered malicious package. Future work on this feature will happen on an isolated VM.

You can also move over to Nub from pnpm incrementally if you want the performance or security wins. It has complete pnpm compatibility: flag for flag identical CLI, reads and writes from your pnpm-lock.yaml, and respects your expecting configs completely. Nub and pnpm can be used simultaneously by different teammates without lockfile churn. This is a key design goal, and its what I mean by "incrementally adoptable". But yeah `nub install` will almost certainly work in your repo out of the box. (File an issue otherwise.)

We've already pulled changes since that PR landed.