ejstags has 1 version on the npm registry flagged in 1 incident we track. Only the exact versions listed below were named by the source advisories. ejstags was recorded in a daily advisory sweep. The write-up groups it into a cluster with the evidence available at the time; check the cluster note before treating it as a confirmed compromise.
If one is in your tree, treat the machine as compromised, not just out of date.
Version data comes from the public advisories cited on each incident page.
Check what you actually have installed with npm ls ejstags.
Yesterday's (Sept 6) sweep captured 13 npm items; the queue then flushed ~200 more, mostly published as of 2026-09-06 and continuing into 2026-09-07. Three coherent clusters (tea.xyz eka-<indonesian-food><N>-<suffix> autopublish, tea.xyz eigenstate-<astronomy>-<tech>-<lib> autopublish, and effective_/efficient_<animal>_z3n research spam) plus a long tail of misc E-prefix drops.
Treat the machine as compromisedUpgrading is not enough. Packages in these incidents typically execute at install time, so the payload has already run with whatever credentials were in the environment.
If ejstags is in your tree, these are worth checking too. They were published by the same campaign.
Version data comes from the public advisories cited on each incident page. We list only versions those advisories name and do not infer additional ones. Think this is wrong or incomplete? Tell us.
It is usually pulled in as a transitive dependency rather than one you installed directly. Paste your package-lock.json to check every dependency at once. It runs in your browser and nothing is uploaded.