BLOG

The Social Engineering Playbook Attackers Use to Target OSS Maintainers

Account takeovers are some of the most harmful malware campaigns. Many start by compromising a maintainer account through social engineering.

By cb482791-4ef1-4762-96ad-b0ca4bdd538e ยท

The Social Engineering Playbook Attackers Use to Target OSS Maintainers

Axios, Chalk, Debug, XZ Utils. What do all these open source projects have in common? Threat actors use social engineering to gain access to the legitimate project and pushed a new version containing malware.

Probably for many of us, "social engineering" evokes memories of Nigerian prince schemes and typo-riddled text messages. But threat actors have become experts at targeting developers with typo-free, sophisticated tactics. They've gotten harder to spot, and OSS maintainers make for easy targets: They're overworked, probably unpaid, and trying to do their best.

In this article, I'm going to cover five common techniques we're seeing, and what you can do to prevent yourself from becoming a victim...and the next headline.

Tactics covered:

  • Credential phishing

  • Exploitation of platform administrative flows

  • Long-term trust building and community infiltration

  • Fake job interviews and collaboration lures

Did we miss an important one? Hit us up on our socials to tell us about it.

Credential phishing

What it is: Attackers send emails impersonating an official support team, often with typosquatted domains and urgent subject lines, to trick maintainers into clicking a link that harvests their credentials or tokens.

Why attackers use it: Maintainers hold the publishing keys. A stolen npm token bypasses just about every other security control on the package itself. Phishing is also cheap and scalable. The same email template can be sent to dozens of maintainers simultaneously, and it only needs to work once.

How it works: The simplest version uses a typosquatted domain. The eslint-config-prettier attack (July 2025) sent the maintainer to npnjs.com instead of npmjs.com, where clicking the link surrendered their npm token. The attacker never touched the GitHub repository; the stolen token was enough to publish four malicious versions directly.

esling-config-prettier

More sophisticated versions use Adversary-in-the-Middle techniques. The chalk/debug attack (September 2025) sent a fake support email from support@npmjs.help, a domain registered three days before the attack, threatening a temporary account lock if the maintainer didn't update his 2FA. The fraudulent login page captured his username, password, and live TOTP code simultaneously, defeating MFA in real time. Josh Junon later acknowledged he should have caught it, but was multitasking during a stressful week. That's not a personal failing; it's the attack working as designed.

Josh Junon 1Josh Junon 2Exploitation of platform administrative flows

What it is: Attackers manipulate the platform's own account recovery and ownership management processes, rather than stealing credentials directly, to gain or restore access through legitimate-looking requests.

Why attackers use it: Platform administrative flows route around technical controls entirely. If an attacker can convince a maintainer to grant access through an official-looking process, there's no credential to steal and no anomalous login to detect.

How it works: The is package attack (July 2025) is the clearest example. The attacker had already compromised a former maintainer's account, then contacted primary maintainer Jordan Harband claiming that npm had incorrectly removed that account. The request was framed as an administrative correction. Harband later described being irritated that npm would remove an owner without notifying others, and that irritation made the social engineering easier, not harder. He re-added the account, and the attacker had a clean entry point.

Jordan Harband

It's also worth noting that npm's current security model makes this category of attack harder to contain once it succeeds. As of early 2026, npm does not require password or 2FA re-confirmation to change an account's email address, generate new tokens, or remove 2FA entirely. A valid session cookie is sufficient. That means any attacker who obtains a session, through phishing, a RAT, or any other means, has broad administrative control with no additional friction.

Long-term trust building and community infiltration

What it is: Attackers create a convincing contributor persona, make genuine technical contributions over an extended period to earn commit or publishing access, and sometimes use sockpuppet accounts to manufacture community pressure that accelerates the handover.

Why attackers use it: Open source projects run on earned trust, and earned trust is the one thing that can't be technically enforced. A maintainer who grants a co-maintainer access after two years of legitimate contributions has done nothing wrong by the norms of the community. The attack exploits those norms directly.

How it works: XZ Utils is the canonical example. Out of all contributions made during this period, only eight commits were malicious. The rest were legitimate improvements, representing 2.6 years of sustained, patient engagement to earn the trust required to distribute a backdoor. Running alongside Jia Tan's contributions, sockpuppet accounts manufactured pressure on maintainer Lasse Collin. The identities even interacted with one another on mail threads, complaining about the need to replace Collin as the XZ Utils maintainer. Collin had openly disclosed mental health struggles and burnout, and the pressure campaign explicitly exploited that vulnerability.

The event-stream incident (2018) used a compressed version of the same approach. User right9ctrl researched the project's issue history going back to 2015, identified a feature the maintainer had expressed openness to, made an offer to help implement it, and earned publishing rights. The attack was surgically targeted, with the malicious code only activating within the specific environment of the Copay cryptocurrency wallet. Maintainer Dominic Tarr later wrote: "if it's not fun anymore, you get literally nothing from maintaining a popular package." His burnout was the structural condition the attacker exploited, not the attack itself.

The OpenSSF and OpenJS Foundations confirmed in 2024 that similar infiltration attempts had been made against multiple JavaScript projects simultaneously, with overlapping GitHub accounts and coordinated pressure campaigns, some of which were caught before access was granted.

Fake job interviews and collaboration lures

What it is: Attackers pose as recruiters or potential collaborators to convince developers to clone and execute a malicious repository or install a fake software update, compromising their machine and harvesting the credentials and tokens stored on it.

Why attackers use it: This technique targets individual developers rather than specific packages. The goal is to compromise a machine that happens to belong to someone with publishing access, harvesting tokens, secrets, and credentials that can then be used to publish malicious versions of packages they maintain. It's an indirect path to the same destination as credential phishing, and it's harder to defend against because it doesn't require the target to make an obvious mistake like clicking a suspicious link. Once a RAT is on a developer's machine, 2FA becomes largely irrelevant: the attacker can grab post-authentication session tokens and act as the user without ever triggering an authentication challenge.

How it works: The axios compromise (March 2026) is the most detailed documented example of this technique targeting an OSS maintainer specifically. In his post mortem, jasonsaayman described a multi-stage UNC1069 campaign: attackers impersonated the founder of a real company, cloning both the founder's likeness and the company itself. They invited him to a convincingly branded Slack workspace complete with fake employee profiles, LinkedIn posts linking to the real company's account, and profiles of other OSS maintainers to build credibility. They scheduled a meeting via Microsoft Teams. During the call, a prompt appeared claiming his system was out of date. He installed what he thought was a Teams update. It was the RAT. From there, the attackers had full unilateral control of his machine and everything on it, including his npm credentials, bypassing 2FA entirely.

axios1

axios2

GitHub's 2023 security alert documented a related pattern from the Jade Sleet cluster: after establishing contact with a target, the threat actor invites the target to collaborate on a GitHub repository and convinces them to clone and execute its contents, which contains software with malicious npm dependencies that act as first-stage malware.

The Contagious Interview campaign, North Korea-linked and active since at least 2022, has operationalized this at industrial scale. Early waves used LinkedIn recruiter impersonation leading to trojanized demo projects. More recent iterations layer in ClickFix: a targeted job seeker is directed to a lure website where they encounter a fabricated error message, such as a camera access issue, and is instructed to copy and paste command lines, unknowingly deploying malware. The group has escalated further by creating front companies with AI-generated employee profile pictures to lend credibility to the fake employer persona. The FBI seized the domain of one such front company, BlockNovas LLC, in April 2025.

Contagious InterviewOwnership transfer targeting abandoned projects

What it is: Attackers identify packages that are no longer actively maintained, approach the original maintainer with an offer to take over, earn publishing rights through a seemingly legitimate transfer, and then inject malicious code into a future release.

Why attackers use it: This technique requires almost no technical sophistication and no deception in the traditional sense. The maintainer is often relieved to hand off the burden. The attacker's only job is to identify the right project and ask at the right time.

How it works: The structural enabler is well-documented. Maintainers receive no material compensation for their work, face increasing demands as a package grows in popularity, and naturally look for a way out. A request to transfer ownership doesn't read as a threat; it reads as a solution. In the event-stream case (2018), right9ctrl researched the project's history to identify a feature the maintainer had expressed openness to, framed the offer around implementing that feature, and earned full publishing rights. The malicious code that followed was downloaded nearly 8 million times before discovery. The polyfill.io attacker took an even more direct route, simply purchasing the CDN domain name and GitHub organization when it came up for sale, inheriting all downstream trust without any social engineering required at all.

Abandoned packages are not rare edge cases. They are a structural feature of an ecosystem built on volunteer labor, and attackers treat them as a renewable resource.

Defenses against social engineering attacks

There's no silver bullet for preventing yourself (or your package) from becoming a victim. And some attacks are easier to prevent than others. That said, there are several things maintainers can do to decrease the chance of an account takeover.

Understand what you're actually defending against. The axios compromise is a useful reminder that once a RAT is on your machine, most platform-level controls stop working. The attacker has your session tokens, your credentials, your keychain, and everything in your home directory. 2FA, hardware keys, and OIDC publishing all protect the authentication step. None of them protect a machine that is already compromised. The most important thing you can do is keep the machine you use for critical publishing actions clean and separate from the machine you use for everything else.

Use a hardware security key for npm, GitHub, and your email account. TOTP codes can be phished in real time, as the chalk/debug attack demonstrated. A hardware key can't be intercepted by an Adversary-in-the-Middle attack. jasonsaayman announced he would start using one after the axios compromise. It won't protect you if a RAT is already on your device, but it significantly raises the bar for purely phishing-based attacks.

Store recovery codes offline. If your recovery codes live in a cloud drive, a synced password manager, or a private repository, they are reachable by anyone who compromises any of those systems. Print them and put them somewhere physical, or store them in an air-gapped location.

Enable trusted publishing and revoke all long-lived npm tokens. Long-lived classic tokens bypass 2FA by design, whereas something like npm trusted publishing binds the publish action to a specific GitHub Actions workflow using short-lived OIDC tokens, meaning there is no persistent credential to steal. The axios compromise succeeded in part because a long-lived token was still in use on the 0.x branch even after the maintainer believed he had moved to trusted publishing.

Set a minimum release age (cooldown period) for your own update consumption. Many tools offer the ability to add a mandatory delay before a new package version is automatically pulled. The plain-crypto-js decoy package used in the axios attack was only 18 hours old when it was used as a malicious payload; a 24-hour minimum would have blocked it from being auto-pulled.

Be suspicious of urgency, flattery, and offers of help. Platform communications that threaten account lockouts, community members who push hard for maintainer access early in a relationship, and requests to run code as part of a "collaboration" or "interview" are all patterns that have preceded real attacks. The open source community runs on trust and generosity, and attackers count on those values working against you.

Know what you're handing over before you hand it over. If you're considering transferring a package or adding a co-maintainer, do it through a relationship you can verify. Meet them in a working group, confirm their identity through channels outside the platform, and scope their access to the minimum necessary. The XZ Utils and event-stream attacks both succeeded because a single handover of full access was all that was needed.

But let's talk about the elephant in the room: If we really wanted to solve this at the industry level, we would pay the maintainers.

References