Found something?

What to do, in the order that matters

The instinct is to clean the repositories first. That is the wrong order, and on an infected machine it is wasted work — this family injects into commits on their way out, so it re-infects whatever you just cleaned.

The short way

One command walks you through all of it

Everything on this page, asked one question at a time, in the right order. Nothing is changed or pushed without you saying so, and it saves your place if you stop.

Start here
snare respond

What it will and will not do

It revokes what it safely can — npm tokens are one keypress, and they are the ones that matter most — opens your browser at the pages it cannot act on, and asks before every push. Anything that writes to a repository defaults to no. The destructive choice, whether to purge history, is asked once rather than per repository, so a rhythm of "yes" cannot carry you through it by accident.

It will not pretend to have rotated your credentials for you. It asks, and if you say no it carries on — but it tells you again before anything is pushed, and again at the end. A step that blocks you is a step you abandon.

snare respond --status shows where you got to. snare respond --reset starts again.

The rest of this page is the same sequence done by hand. Read it if you would rather drive, or if you want to know why the order is what it is.

The order

Four steps, and the sequence is the point

  1. Rotate your credentialsStealing them is the objective; the file in your repository is delivery, not payload. Removing it does not un-steal a token. npm write tokens first — a stolen one lets the worm publish trojanised versions of your other packages under your name, which is how one laptop becomes a supply-chain incident.
  2. Clean the machine you push fromBefore touching any repository. If several repositories are flagged, the common factor is almost always the machine that pushed to them, not several separate accidents.
  3. Then clean the repositoriessnare fix is a dry run by default and always backs up first. Only add --push once you have read what it would change.
  4. Then tell your collaboratorsThey may be infected from the same source, and if you rewrote history their clones will break with no explanation.
Step 1

Rotate

Do this first
snare rotate        # the ordered checklist, plus a GitHub audit

In order: npm tokens (npmjs.com/settings/~/tokens — write and "bypass 2FA" first), then GitHub PATs, OAuth apps and SSH keys, then cloud keys (AWS — including Secrets Manager in every region you use — GCP, Azure), then everything else the process could read: .env files in any project you had open, kubeconfig, Vault tokens, database URLs, VPN, AI-service keys, wallet keys and seed phrases. Finally your clipboard — this family has a documented clipboard stealer, so a password pasted out of a manager while infected should be treated as seen.

Step 2

Clean the machine

Before touching any repo
snare doctor          # machine, persistence spots, your GitHub account
snare guard scan      # one-shot process check
snare guard install   # kill the loader on sight, from login onwards

guard scan saying "clean" does not mean you were never infected. It reports what is running right now. The loader fires when a build runs or an editor opens the folder, does its work, and exits. A clean process check alongside infected repositories is the expected result, not a contradiction.

Step 3

Clean the repositories

Dry run first — always
snare fix owner/repo                        # dry run, changes nothing
snare fix --all                             # dry run over everything flagged

snare fix owner/repo --push                 # clean the branch tips
snare fix owner/repo --purge-history --push # erase it from all history

--purge-history rewrites every commit, so every SHA changes. Collaborators must delete their clone and re-clone; a git pull will conflict or silently reintroduce old objects. Forks and pull-request refs keep the old objects regardless — ask GitHub Support to garbage-collect them if that matters to you.

Afterwards, verify rather than assume. snare scan github only reads branch tips; run snare scan repo against a fresh clone to walk full history.

Step 4

Tell the others

Contacts and templates
snare notify owner/repo             # list collaborators, preview the notice
snare notify owner/repo --issue     # file a GitHub issue @-mentioning them
snare notify owner/repo --mail      # open a pre-filled mail draft per person

Both templates lead with credential rotation and say plainly that this is not an accusation: the malware injects from an already-infected machine, so a collaborator whose commit carried it was almost certainly a victim rather than a cause. Say that early, or you will not get the reply you need.

If the count is high

If a lot of repositories are flagged

Fifteen infected repositories is not fifteen accidents. It points at one machine that pushed to all of them. Work out which machine that is before cleaning anything, or you will clean the same repositories twice.

Worth knowing what you scaffold new projects with — a starter template, a create-* command, a downloaded theme, an editor extension. The delivery mechanism for this family is still unidentified, and that is the single most useful thing anyone can contribute. If you find yours, say so in the discussion.