CISA names two poisoned axios releases, and the bill lands on whoever owns the CI secrets

A single patch level separates poisoned from clean in both branches: 1.14.1 sits above 1.14.0, and 0.30.4 above 0.30.3 ^[15]. That is the awkward part of the hunt. An inventory reporting "axios 1.14.x" answers nothing useful; you need resolved versions out of lockfiles and the timestamp of the install, which is why CISA's first instruction points at repositories, CI/CD pipelines and developer machines that ran `npm install` or `npm update`, rather than at production hosts ^[5].

The advisory also leaves the window open at one end. It gives March 31, 2026 as the publication date of the malicious versions and says nothing about when they came off the registry ^[18], so the query every team now has to write has a start and no finish. The axios post mortem opened the same day and Microsoft Threat Intelligence published its own writeup on April 1 ^[13]. CISA's alert carries an April 20 date ^[14], twenty days after the packages went up ^[16]. That lag tells you what the document is for: not first notice, but a checklist to be judged against afterwards.

The hunt inputs are lean. Sfrclak[.]com is the only network indicator supplied, and no file hashes accompany the endpoint sweeps CISA asks for ^[19][8]. Detection therefore rests on behaviour, meaning unexpected child processes during installs and dependencies that start building containers or opening shells ^[12]. Teams that already baselined what their build tooling does at install time can run that. Teams that did not are reading logs and hoping.

The most durable item is the `.npmrc` pair. Set `min-release-age=7`, and a package published on March 31 becomes installable no earlier than April 7, six days after Microsoft had already described the compromise ^[17]. For anyone who had it set, this alert is paperwork rather than an incident. The cost is that the same seven days apply to every release, including the ones you want in a hurry. `ignore-scripts=true` addresses the execution path directly, by keeping install-time scripts from running at all ^[10].

Note also what CISA is not doing. These are recommendations it urges organisations to adopt ^[1], and the account-side items, phishing-resistant MFA on developer accounts in particular ^[11], do nothing for the builds that already ran. They are for the next maintainer account that gets taken.