Open source malware activity during 2025 concentrated on a single objective: executing code inside developer environments, according to Sonatype.
The focus reflected a broader shift in supply chain attacks away from end users and toward the tools, machines, and pipelines used to build software in the first place.
Key takeaways (Source: Sonatype)
Malware campaigns scaled through registries
Researchers identified more than 450,000 new malicious open source components during the year. Attackers published large batches of packages that shared naming patterns and internal code, then rapidly replaced them after removal.
Most malicious releases appeared in npm, where its central role in front-end development and CI pipelines enabled distribution at scale. Publishing followed short, automated cycles, with packages reappearing shortly after takedowns.
Some campaigns spread without manual republishing. One operation observed in September propagated laterally through developer machines and linked projects, compromising hundreds of downstream components within days. Another campaign generated tens of thousands of packages in a short window, creating sustained load on registries.
The volume and speed of these incidents underscored how malware publishing has become an automated process. As attackers encounter friction in more mature ecosystems, they are increasingly redirecting efforts toward environments with weaker safeguards.
Tomislav Peričin, CTO at ReversingLabs, told Help Net Security that smaller or newer ecosystems should treat this pattern as a warning. Rather than waiting for abuse to scale, he argued they need to adopt the same defensive controls that established platforms were forced to implement after repeated incidents.
“They should learn from the mistakes and corrections taken by established platforms like npm, PyPI, and so on,” Pericin said. “That includes strengthening access controls, such as 2FA for developer and maintainer accounts, deprecating legacy authentication methods, limiting token lifetimes, and establishing protocols to reduce the blast radius of package compromises, including quarantining.”
He added that registries themselves need dedicated security investment. “They should also invest in their own internal security teams and monitoring for indicators of pending or early-stage supply chain compromises,” he said.
Execution shifted to install time
Rather than categorizing malware by artifact labels, the study classified malicious components based on behavior. Registry abuse accounted for more than half of all malicious entries, with automated publication used to maximize reach.
Other behaviors focused on access. Some packages harvested credentials or system data from developer workstations and CI environments. Others retrieved secondary payloads after installation. A smaller subset included backdoor functionality designed to maintain long-term access.
Across these categories, a common tactic emerged: install-time execution. Malicious code ran as dependencies were installed, before builds completed or applications were ever executed. A single download was enough to trigger activity inside environments holding API keys, tokens, and deployment credentials.
Attackers also paid close attention to social engineering details. Package names mimicked familiar plugins, helpers, and troubleshooting tools. Documentation followed standard project formats, reflecting how easily dependencies are added during routine development work without deep inspection.
State-linked campaigns refined delivery methods
Sonatype attributed hundreds of malicious releases published during 2025 to North Korea’s Lazarus Group, almost all within npm.
These packages combined multiple threat behaviors into a single component. Droppers, credential theft, and persistence mechanisms appeared together, forming staged intrusion chains where the open source package itself served as the delivery vehicle.
Targeting focused on widely used frameworks and build tools, with names referencing common development keywords to increase the likelihood of installation during debugging or feature development.
Researchers also observed consistent reuse across campaigns. Variants shared code templates and infrastructure, and replacement packages appeared quickly after removals, indicating an organized and well-resourced operation rather than opportunistic abuse.
AI systems introduced new exposure
AI assisted development further complicated dependency risk during 2025. Sonatype observed language models selecting packages, resolving build errors, and suggesting upgrades based on public data that often lagged real-world conditions.
Testing showed a dependency upgrade hallucination rate of 27.76%, with AI systems recommending nonexistent versions or unsafe dependencies when resolving issues. These errors became more impactful when agents operated autonomously inside CI pipelines.
Attackers exploited naming similarity and namespace resolution behavior. When AI agents acted independently, they installed dependencies based on resolution success rather than validating origin, reputation, or abuse indicators.
Researchers also identified AI model artifacts that executed code during loading, enabling data exfiltration or remote access. These models frequently ran in shared environments containing credentials and sensitive data.
The growing volume of AI-generated output has also changed how vulnerability reports reach maintainers and development teams. Pericin said teams need to rethink how they triage reports at scale.
“For open source maintainers and development teams, AI-generated vulnerability reports should first be verified to determine whether the flaw is reproducible,” he said. “Given the high volume of AI-generated reports, this may require greater scale and automation than has been common with human-generated vulnerability reports.”
Once validated, Pericin said triage should focus on severity, exploitability, and potential impact. “Confirmed reports should then be prioritized based on severity, likelihood of exploitation, and the consequences of an attack, whether that’s service disruption, data exposure, or cyber-physical impact,” he said.
That process, he added, depends on visibility. “It requires a clear understanding of the software and dependencies in question, as provided by SBOMs, SaaSBOMs, MLBOMs, and similar artifacts. Teams should also weigh the feasibility of attacks and the availability of mitigations that can reduce risk even when a software fix isn’t immediately available.”