On March 31, 2026, someone got Jason Saayman on a Microsoft Teams call. The caller claimed to be a founder. They had already been in his Slack workspace. By the time the call ended, Saayman’s npm credentials were gone, and two malicious Axios packages (axios@1.14.1 and axios@0.30.4) were pushing a cross-platform RAT to the roughly 400 million monthly downloads the library receives. The code itself was never the target. The person shipping it was. Three hours of exposure, confirmed execution in 3% of affected environments, and an MIT License that gives the maintainer no mechanism to say “stop using my code for this.” Hive Security’s incident analysis and Frame Security’s breakdown walk through the technical chain. The legal chain is shorter and less forgiving.
The attack didn’t touch the code
The Axios compromise was the final stage of a 13-day campaign the security community calls “TeamPCP.” According to Hive Security, the same North Korea-linked group hit five open-source projects in succession: Trivy on March 19, KICS on March 23, LiteLLM on March 24, Telnyx on March 27, and Axios on March 31. The pattern was consistent: social-engineer the maintainer, steal publish credentials, ship a malicious version. Every target was developer infrastructure where credentials, tokens, and secrets are concentrated.
Standard supply-chain defenses did not apply here. Vulnerability scanners look for known CVEs in published code. SBOMs enumerate dependencies. Version pinning locks you to a specific release. None of these catch a legitimate maintainer’s account publishing a poisoned version, because the package identity, signature chain, and distribution channel are all authentic. Frame Security notes that Axios is present in roughly 80% of cloud and code environments, which is what made it worth the operational investment of a multi-channel phishing operation spanning Slack and Teams.
The attack worked because it targeted the human, not the artifact. That distinction matters for what comes next.
What the MIT License actually covers
Axios is released under the MIT License. It grants permission to “use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software” with one condition: include the copyright notice and the license text itself. That is the entire enforcement surface. Legal analysis of MIT License enforcement confirms what the text makes obvious: there is no revocation clause, no use-case restriction, no clause that terminates on misuse. The grant is irrevocable and abuse-blind by design.
This is not a bug in the license. It is the license. The MIT License was written to minimize friction for downstream use. The tradeoff, which most maintainers accept without thinking about the edge case, is that “downstream use” includes use by people building phishing operations, credential harvesters, or RAT distribution infrastructure. The license does not distinguish between “integrate into a SaaS product” and “repackage into a supply-chain weapon,” because it was never written to make that distinction.
MIT’s own Technology Licensing Office acknowledges that certain open-source license terms carry specific restrictions and that some licenses are “untenable for MIT to use,” depending on the risk profile. The subtext: the license you choose for your weekend project and the license a university chooses for its patent portfolio are solving different problems. A solo maintainer publishing to npm is usually not thinking about either.
The three levers that actually exist
If your permissively-licensed code ends up inside a phishing tool or a compromised package, the license itself gives you nothing. But that does not mean you have zero options. Three mechanisms sit outside the copyright grant, and each works differently.
Trademark policy. The MIT License covers copyright. It does not cover trademark. You cannot use the MIT License to stop someone from distributing your code, but you can, in many jurisdictions, stop them from calling it by your project’s name if you have a registered trademark or established common-law rights. The legal analysis identifies this as the most practical lever: the license lets them ship the code, but trademark law can prevent them from using your name, logo, or brand identity to lend credibility to the misuse. For a supply-chain attack like Axios, where trust in the package name is the entire vector, this is not nothing.
Acceptable-use addenda. Some projects layer a separate acceptable-use policy on top of the open-source license. The license governs copyright. The use policy governs behavior. The Hacker Ethic 2.0 license and the Hippocratic License are examples of this approach. They do not revoke the copyright grant, but they attach contractual conditions to specific use cases (surveillance, weapons, harassment infrastructure). The enforcement model is untested in court, and the OSI does not consider such licenses “open source” by its definition, which is the point of tension.
Distribution controls. npm, PyPI, Docker Hub, and similar registries are private platforms with terms of service. A maintainer cannot revoke a downstream user’s copy of MIT-licensed code, but they can report a package that violates registry rules, and registries have taken down malicious packages within hours. This is reactive, not preventive, and it depends on the registry operator’s willingness to act. In the Axios case, npm removed the malicious versions quickly. But the code had already been downloaded, and the MIT grant means the downloader has the legal right to keep using it.
Why each lever costs something
Trademark enforcement requires you to have registered the mark, actively defended it, and budgeted for legal proceedings. Most solo maintainers have not registered anything. Common-law trademark rights exist in some jurisdictions, but enforcing them against an anonymous actor in a hostile nation-state is not realistic. The lever works best against corporate misuse (a company using your project’s name to market a competing product) and worst against the threat model that actually keeps maintainers up at night (state-sponsored groups who do not care about your cease-and-desist letter).
Acceptable-use addenda trade one problem for another. The moment you attach behavioral conditions to your license, you leave the OSI’s definition of open source. Whether that matters to you depends on your priorities. For maintainers who chose MIT specifically because they wanted maximum downstream freedom, adding use restrictions is a philosophical reversal. For maintainers who are tired of seeing their work weaponized, it may be worth the cost. The ecosystem does not have consensus on where the line is, and every new acceptable-use license reopens the argument.
Distribution controls are the most pragmatic but the least structural. You are relying on a platform operator’s judgment, not a legal right. If npm decides not to act, or if the malicious package is distributed outside a major registry (a private fork, a self-hosted artifact server), the lever vanishes. It is also purely reactive: you report after the damage is done, not before.
The source-available tension nobody wants to name
The logical endpoint of “permissive licenses are abuse-blind, so we need restrictions” is a license that is not permissive. Several projects have arrived there independently. Elastic’s SSPL, MongoDB’s SSPL, Confluent’s Community License, and the BSL variants all restrict specific use cases (usually competitive managed services, but the mechanism generalizes). They are source-available, not open source, by OSI’s definition.
Most maintainers spent years resisting exactly this shift. The argument against source-available licenses has been consistent: they fracture the ecosystem, create compatibility headaches, and undermine the legal infrastructure (GPL compatibility, Debian’s free-software guidelines) that makes open source work as a shared commons. The argument for them, when the threat model is not a cloud provider but a state-sponsored phishing operation, is weaker still. The Axios attackers did not redistribute a fork under a different license. They stole the maintainer’s credentials and published under the original name. A source-available license would not have changed the attack’s mechanics at all.
The uncomfortable truth is that the mechanisms available to stop your code from being used in a phishing operation are the same mechanisms that, used broadly, would make the open-source ecosystem harder to participate in. Trademark litigation is expensive. Acceptable-use clauses create license proliferation. Distribution controls depend on platform operators. None of them stop a motivated attacker, and all of them add friction for legitimate users. The license is the wrong layer to solve this problem, but it is the layer most maintainers have.
What maintainers can do without abandoning permissive licensing
The research brief does not prescribe a specific legal strategy, but the incident details and the governance landscape suggest practical steps that sit outside the license itself.
Register your project’s name as a trademark. This is the single most effective legal lever if you need to stop someone from trading on your project’s reputation. It costs money and takes time, but it converts a vague brand identity into an enforceable right.
Adopt a governance layer, not a license change. Google, Microsoft, Red Hat, and the Linux Foundation all maintain formal open-source policies that address legal and business risk beyond the copyright grant. A project does not need to be a Fortune 500 company to adopt a lightweight governance document covering trademarks, security disclosure, and acceptable contribution behavior. The license stays MIT. The governance sits alongside it.
Secure the publish pipeline, not the license. The Axios attack succeeded because one person held publish credentials protected by nothing stronger than an account password. Multi-party publishing approval, hardware security keys for registry accounts, and automated provenance signing (Sigstore, npm provenance attestations) address the actual attack vector. The license is irrelevant if the attacker never gets to publish.
Accept that permissive licensing means accepting abuse you cannot stop. This is the part most governance documents skip. MIT and Apache were designed to enable maximum downstream use, and “maximum” includes malicious use. If that tradeoff is no longer acceptable, the honest answer is to change the license, not to pretend the existing license does something it does not. If the tradeoff is still acceptable, then the right response to the Axios attack is not a new license clause but a stronger publish pipeline and a registered trademark.
The Axios maintainer was phished. The code was fine. The license was irrelevant to the attack’s success and irrelevant to its cleanup. That is the thing worth sitting with: the legal instrument you chose to share your code is not the instrument that will protect it, and no amount of license engineering will fix a credential problem.
Frequently Asked Questions
Would switching to a copyleft license like GPL change anything?
GPL’s copyleft clause forces downstream modifications to remain open source, but it places no restriction on who can use the software or for what purpose. A state-linked group could still publish a poisoned GPL-licensed package through a compromised maintainer account. The only added obligation would be publishing the malicious payload’s source, which is moot when the attacker controls the distribution channel. Copyleft protects code openness, not code integrity.
Can a DMCA takedown force removal of a malicious MIT-licensed package?
Only if the attacker omitted the copyright notice, since that is the sole condition the MIT License attaches to redistribution. If the malicious package includes the notice and license text, the grant is satisfied and a DMCA claim has no standing. This is why trademark claims are the stronger legal lever in practice: they attack the misuse of the project’s name and reputation rather than the distribution of the code itself.
What does npm provenance attestation actually verify?
npm provenance, built on Sigstore, cryptographically ties a published package to a specific source commit, build environment, and builder identity. If Axios had provenance enabled, consumers could have detected that the malicious versions came from an unexpected build environment, even though the npm credentials were legitimate. The gap: most CI pipelines do not verify provenance by default, so the signal exists but few consumers check it.
Have acceptable-use licenses like the Hippocratic License been tested in court?
No acceptable-use open-source license has faced a legal challenge as of mid-2026. The uncertainty centers on whether a court would treat use-case restrictions as enforceable contractual conditions or as attempts to regulate copyright that federal copyright law preempts. Until a test case establishes precedent, these licenses function as a deterrent and a values statement rather than a reliable enforcement mechanism.