The latest cybersecurity news cycle flagged npm packages as malware — and, as usual, the advisory never said what the code actually did. This page fixes that gap: paste a package.json or install script below and a 100% in-browser analyzer translates install hooks and suspicious strings into plain English — what would run, what it could take, and what to rotate first. Nothing you paste leaves your browser.
Short answer: a yanked package is a package version pulled from a registry after publication, usually because it was flagged as malicious or compromised. Pulling it stops fresh downloads — it does not uninstall copies already in your node_modules, your cache or your lockfile, and it tells you nothing about what its install scripts already ran. The analyzer below reads those scripts for you.
On October 19, 2026, npm packages listed as items-validator and item-validator were flagged as malware in cybersecurity news reports, and the advisories followed the usual boilerplate pattern: a severity label, an affected range, and almost nothing about what the install payload actually did on a developer machine or in CI.
That missing middle is where the damage lives. A malicious npm package rarely needs an exotic exploit: it needs an install. The moment a developer or a CI runner executes npm install, the package's own lifecycle scripts run with that user's permissions, that machine's files and that environment's tokens. An advisory that says only “malicious package, remove it” leaves the three questions that matter unanswered — what ran, what it could reach, and what you must rotate. This page is built to answer them for any package you paste in, using the October 19 flagging as the trigger, not as a claim about a payload nobody has published.
A yanked package is a package version pulled from a registry after publication, usually because it was flagged as malicious or compromised. Pulling it stops new downloads from the registry, but it does not remove copies already cached, vendored or pinned in your lockfile — those still install and still run.
Registries yank, flag or unpublish for different reasons — malware, a hijacked maintainer account, a protest, or a broken release — and the response differs for each. When the reason is malware, the safe assumption is that the package's install-time code executed everywhere it was installed, on laptops and in CI alike. That assumption, not the advisory label, should drive your response.
Paste a package.json, a lockfile fragment, or the text of an install script (setup.js, a postinstall target, a shell snippet). Or load a built-in sample first: the flagged-style sample combines the classic shapes — an install hook, a download piped to a shell, a token read and an SSH key read — while the clean sample shows an ordinary package with no install-time behaviour. This is a quick static peek, NOT a full analysis — see the honest scope note under the results.
Honest scope note: this is a quick static peek at the text you paste — pattern matching in your browser, not a full analysis. It cannot unpack a tarball, follow code across files, decode every obfuscation, or watch what a script does at runtime, and a clean result is not a safety guarantee. The full tool is the open-source yanked-package-autopsy repo by Ingenious AI (part of the Ingenious AI toolkit; queued for publication while the GitHub account is restored), which inspects actual package contents and install behaviour in a controlled environment.
| Pattern | Severity | What it means |
|---|---|---|
Install hook (preinstall / install / postinstall) | HIGH | Code that runs automatically on npm install — before you open, import or execute anything yourself. The hook is the delivery mechanism for almost every malicious package. |
Flagged package name (items-validator / item-validator) | CRITICAL | The exact names flagged on October 19, 2026 appear in the pasted text — as a dependency, a lockfile entry or a script reference. |
curl / wget download, or download piped to sh / bash | HIGH–CRITICAL | The install reaches out to a host and fetches more code at install time. Piped to a shell, whatever that host serves is executed sight unseen. |
Token-like process.env reads (NPM_TOKEN, GITHUB_TOKEN, AWS_*, secrets) | HIGH | The script reads credentials from the environment — exactly the values CI runners and developer shells hold. Reading them is step one of stealing them. |
.ssh / .aws / key-file reads | CRITICAL | The script touches SSH keys or cloud credential files in your home directory. There is no legitimate reason for a validator package to read your private keys. |
child_process / exec / spawn | HIGH | The script runs arbitrary system commands, escaping the JavaScript sandbox into your shell, your tools and your credentials. |
Base64 blobs and decoding (Buffer.from(..., 'base64'), atob) | HIGH | Encoded content hides the real payload — a URL, a command or a second script — from anyone skimming the source. |
If a package in your tree was yanked or flagged, work this list in order. Speed matters more than completeness in the first hour; you can deepen the investigation once the exposure window is closed.
npm install on the affected lockfile, and tell the team not to install or update until you say so. Every fresh install is a fresh execution of the flagged code.grep -rn "item-validator" package-lock.json yarn.lock pnpm-lock.yaml — and note when it entered, from your version-control history.node_modules alone does not do this — see the FAQ below.--ignore-scripts for untrusted installs, review new dependencies' install hooks before adopting them, and audit the tree when advisories land — the analyzer above takes under a minute.Stop installing it, pin or remove the flagged version, and check when it entered your lockfile and which machines installed it. Treat any machine that ran its install scripts as exposed: rotate the credentials listed below, review CI logs for that window, and reinstall from a clean lockfile only after the replacement is verified.
Rotate in exposure order: first the npm token and any token the install environment held, then cloud keys such as AWS credentials, then GitHub tokens and SSH keys if the script could read your home directory. Revoke the old values rather than just creating new ones, and check each account for activity you do not recognize.
npm runs lifecycle scripts declared in package.json automatically during install: preinstall runs before the package is installed, install during it, and postinstall after it. Those scripts execute with your user permissions and your environment, so a malicious hook does not need a vulnerability — installing the package is the execution.
No. Deleting node_modules removes the package files, but an install script has already run with your permissions: it may have copied credentials out, changed configuration, or left files elsewhere. Remove the package and its lockfile entry, rotate exposed credentials, review shell and CI configuration for additions, and reinstall cleanly — treat deletion as step one, not the fix.
This page is a quick static peek at text you paste — it cannot unpack tarballs, follow code across files, or observe what a script does at runtime. The full Yanked Package Autopsy tool inspects the actual package contents and install behaviour in a controlled environment, so use it before you conclude a flagged package was harmless.