When the Axios story broke, a lot of us did the same thing. We checked lockfiles, read the advisory, maybe cursed once. That is how you protect your own builds. The sequence that mattered started earlier. Someone got onto Jason Saayman’s machine first, and malicious Axios releases on npm followed from his account. I am not here to rehash every technical detail. I want to talk about how ordinary that setup looked. I think I could be tricked by something like it too.

What happened first

Attackers pretended to be a company founder and had put enough work into the look of the person and the company that the first message did not obviously look fake. Threat actors brought Jason into a Slack that looked like a real company workspace. Channels looked active. Fake teammates dropped LinkedIn style posts that could have pointed at a legit account somewhere else. There were profiles that looked like a team, and Jason said there were even profiles that looked like other open source people. The workspace was set up to look like a real company.

Then came a Teams call with several people on it. Something on Jason’s machine was “out of date.” He installed an updated that was sold as a fix for Teams. That was the malware. Hackers took their time. The operation was coordinated and looked professional. It was not a sloppy link in a rush email.

Google’s threat intel folks tie this kind of campaign to UNC1069 and similar reporting on fake execs and AI assisted faces. Crypto teams have been seeing the same method for a while. Axios was the same approach with a different outcome. Attackers wanted a computer that could reach npm accounts, not one wallet.

Why this worries me

The stories from people who study these attacks all sound the same after a while. The relationship stretches over weeks. Meetings move around so you never feel hustled. The call can look fine in the browser. Then audio breaks, or something feels off, and the person you trust tells you how to fix it. Maybe a tiny script. Maybe paste this in Terminal. Maybe double click something that runs AppleScript. After that your machine checks in on a timer and someone on the other end can push more junk. I have sat on calls where I would have wanted to be polite and move things along. That patience is what attackers count on.

If you are thinking “I am nobody,” I get it. I still think package maintainers are squarely on attacker lists now. One publish session can reach a staggering number of machines. You do not have to be famous. You just have to own a name a lot of people trust.

Jason and others are blunt about MFA. Once someone runs code on your laptop, a Yubikey does not undo the fact that an attacker is already on your system. Folks who do incident response talk about threat actors who learn your hours, reuse your logged in sessions, and keep going long enough to establish persistence on the machine. What I remember most from those threads is short. Do not let strangers talk you into running things on the machine where your keys live.

What you can do to protect yourself

None of this is a corporate checklist. It is what actually matches how these attacks work in practice.

• Use a separate machine for sensitive work. If you can swing a second laptop or a locked down VM only for signing, publishing, and other scary access, do it. No random repos on that box. No “quick” Zoom with a new contact. No personal mail sync if you can help it. For many people that sounds like a luxury. It is cheaper than explaining to the internet that your package was compromised.
• If a call asks you to install or paste while attackers watch, stop. Perfect video and broken audio is a pattern people warn about for a reason. Hang up. Verify the company through someone you already knew before this thread, not through the Slack invite you just got.
• Prove who you are talking to. Mutuals, a corporate address you looked up yourself, a phone tree you found on the real site. A pretty Slack proves nothing.
• If you ship popular packages, assume you are a target. Report fakes. Tell your own near miss stories. The shame belongs with attackers, not you.
• Ask your employer or your sponsors to pay for this stuff. Maintainers are infrastructure. Hardware and tooling should be line items in a budget, not something you pay for yourself after hours.
• Still do the dependency hygiene. Lockfiles, pins, scanners, better release pipelines. That helps everyone downstream. For technical details and indicators, see the Axios issue on GitHub and Socket’s writeup. That layer limits how far a bad publish spreads. Jason’s thread explains how the machine was compromised before npm ever entered the story.

The attack Jason described was aimed at someone generous enough to take a meeting and competent enough to fix a “small” IT problem. The defense that fits can feel rude in the moment. Hang up. Verify. Say no to the paste.

Let me know what you think on Blusky