Three Coordinated Supply-Chain Campaigns Target npm, PyPI, and Docker Hub in 48-Hour Credential Harvesting Spree
Attackers launched three separate supply-chain campaigns against npm, PyPI, and Docker Hub within 48 hours, shifting focus from code tampering to harvesting API keys, cloud credentials, and tokens from developer environments and CI/CD pipelines.
Supply chain attackers are no longer content with slipping malicious code into trusted software. In a stark escalation, three separate campaigns hit npm, PyPI, and Docker Hub within a 48-hour window, all targeting secrets from developer environments and CI/CD pipelines. The attackers exfiltrated API keys, cloud credentials, SSH keys, and tokens, marking a strategic pivot from software tampering to credential harvesting at the points where developers and automation already hold trust.
The campaigns, which echo patterns seen in the earlier TeamPCP and Shai-Hulud operations, demonstrate that developer workstations and CI/CD systems have become direct attack surfaces in the software supply chain. Rather than injecting backdoors into packages, the attackers focused on stealing the access that makes trusted software possible. A single compromised workstation can yield local repositories, .env files, shell history, SSH keys, package manager credentials, build scripts, and browser sessions — a concentration of context that becomes far more dangerous when viewed together.
In the TeamPCP campaign, attackers used compromised packages and developer tooling to harvest tokens, cloud credentials, SSH keys, npm configuration files, and environment variables. The Shai-Hulud campaign pushed the same pattern further, turning infected developer environments into credential collection points that exposed thousands of secrets across GitHub, cloud services, package registries, and internal systems. The new wave of attacks appears to be a continuation of this trend, with adversaries exploiting the same operational truth: the objective is access.
The developer workstation is valuable because it concentrates software delivery authority. A standard employee laptop may expose corporate data, but a developer workstation may expose the ability to change software. Developers often need broad access to clone private repositories, authenticate to cloud services, publish packages, access staging environments, and interact with multiple internal tools. Their machines become a working intersection of source code, credentials, automation, and delivery authority. A single access token may look limited in isolation, but a token found next to a Git remote, deployment script, README, cloud profile, and CI configuration tells an attacker where the token fits and what it might unlock.
The impact of these campaigns is amplified by automation. Dependency update bots can open and merge changes quickly. CI/CD systems can execute trusted workflows automatically. Package managers can run installation scripts. AI agents and coding assistants can read files, call tools, generate commands, inspect output, and move context across systems. Automation has compressed the time between compromise and impact, making the exposure surface thinner and faster. Packages altered and published in a modern supply chain attack remain live for hours, while automation tools merge malicious updates in minutes.
Security teams are now being forced to rethink their approach to supply chain security. Traditionally, focus was placed on shared systems like source code repositories, CI/CD platforms, artifact registries, package managers, and cloud environments. But modern software delivery begins before code reaches Git — it begins on the developer workstation, where code is written, dependencies are installed, credentials are tested, AI assistants are prompted, containers are built, and trusted actions begin. Treating developer workstations as 'just' ordinary endpoints leaves gaps among endpoint security, identity security, application security, and supply chain governance.
The incidents underscore the need for organizations to identify which credentials are usable from developer workstations, limit the value and lifetime of those credentials, detect sensitive material before it enters Git history or CI logs, and revoke and rotate access quickly when a compromise is suspected. As the line between development and production continues to blur, the board and auditors are increasingly concerned not with whether a developer stored a secret locally, but with whether a local exposure gives attackers a path into systems that build, modify, release, or operate software.