A newly created npm maintainer account named vpmdhaj uploaded 14 typosquatted packages in a span of just four hours on May 28, 2026, Microsoft revealed in a security advisory. The rapid-fire campaign specifically targeted developers working with OpenSearch, ElasticSearch, DevOps tools, and environment configuration libraries, with the ultimate goal of harvesting CI/CD secrets and cloud credentials.

This incident marks another aggressive attempt to exploit the trust developers place in open-source registries, leveraging automation to flood npm with look-alike packages at a pace that outruns manual review. The brevity of the attack window – roughly four hours from first publication to last – underscores the growing sophistication of supply chain attackers who prioritize speed to maximize downloads before takedowns occur.

The Attack Unveiled

Microsoft's security research team detected the malicious packages after noticing a spike in suspicious npm publications from a single maintainer account. The account, vpmdhaj, was created shortly before the packages went live and showed no prior activity on the platform, a hallmark of throwaway identities used in automated attacks.

The 14 packages employed classic typosquatting techniques, mimicking popular package names with subtle variations designed to catch developers who make accidental typing mistakes or misconfigure dependencies. While the exact names were not immediately disclosed to prevent further abuse, the packages imitated libraries related to:

  • OpenSearch – an open-source search and analytics suite
  • ElasticSearch – the widely used search engine (now known as Elastic)
  • DevOps – generic-sounding names that appealed to CI/CD and infrastructure as code tools
  • env – utilities for managing environment variables

Each package contained a pre-install or post-install script that executed upon installation, a common vector in npm supply chain attacks. These scripts collected sensitive information from the victim's environment, including API keys, database connection strings, CI/CD service tokens, and cloud provider credentials stored in environment variables or configuration files.

How the Typosquatting Worked

Typosquatting attacks rely on human error. A developer intending to install @opensearch-project/opensearch might mistype the name as openseach or openserch, inadvertently pulling in a malicious package. Attackers register these slight variations in bulk, betting that even a tiny fraction of the millions of daily npm installs will hit their decoys.

The vpmdhaj campaign automated this process to an extreme degree. All 14 packages were published within 240 minutes, meaning an average of one package every 17 minutes. This rapid sequence suggests the attacker used scripts to generate variations, create the package structures, and push them to the registry in a short burst – likely timed for a period when human moderators might be less active.

Automated publishing speeds up the infection window. Once a package is live, it becomes available for installation immediately. If a CI/CD pipeline accidentally picks up the typosquatted package, the malicious script runs within the pipeline context, granting access to secrets mounted as environment variables. In cloud-based build environments, this can cascade into lateral movement across services.

The Malicious Payload

Analysis of the malware payload showed it was straightforward yet dangerous. The pre/post-install scripts first exfiltrated environment variables by encoding them and sending them to an attacker-controlled server. The scripts specifically hunted for:

  • NPM_TOKEN, GITHUB_TOKEN, CI_JOB_TOKEN – authentication tokens for package registries and CI/CD platforms
  • DOCKER_PASSWORD, KUBECONFIG – container registry and Kubernetes access
  • AWS_ACCESS_KEY_ID, AZURE_SUBSCRIPTION_ID, GCP_PROJECT – cloud provider credentials
  • Database connection strings and private keys

After extracting these secrets, the script established persistence by writing a backdoor into the project's node_modules or adding a pre-commit hook that would re-execute the payload in future builds. This ensured that even if the initial malicious package was removed, a remnant remained to continue harvesting updated secrets.

In some cases, the malware also modified package.json to add the malicious package as a dependency, making it harder to spot and remove. The combination of immediate data theft and long-term persistence made this attack particularly dangerous for organizations that rely heavily on automated CI/CD workflows.

Impact on Developers and CI/CD Pipelines

The primary victims of this campaign are developers and DevOps teams who integrate third-party npm packages into their build pipelines. A single mistyped npm install in a Dockerfile, a Makefile, or a CI step can expose every secret available in that execution environment. Because many CI/CD systems inject credentials as environment variables to allow deployments, the blast radius can be extensive.

Once an attacker obtains, say, a GitHub Actions secret with write access to a repository, they can modify source code, push malicious updates, or pivot to other repositories within the organization. Similarly, cloud credentials can be used to spin up resources for cryptomining, exfiltrate data from storage buckets, or escalate privileges within the cloud account.

The stealthy nature of the malware means many victims may not realize they were compromised until logs show unusual activity days or weeks later. Microsoft's advisory emphasized that affected users should immediately rotate all exposed secrets and audit their pipeline logs for unexpected network requests to unfamiliar endpoints.

Microsoft's Response and Detection

Microsoft's security team, which includes the npm security group following the platform's acquisition, took down the packages and banned the vpmdhaj account within hours of detection. They also published a detailed advisory on the Microsoft Security Response Center blog, providing indicators of compromise (IoCs) such as the command-and-control server domains and IP addresses, and a list of the exact package names to help developers scrub their environments.

The company urged developers to use its npm audit tool and the newly enhanced supply chain security features built into GitHub and Azure DevOps. These include:

  • Dependency scanning that flags typosquatting risks based on name similarity scores
  • Secret scanning that alerts on any credentials found in public repositories
  • Audit log analysis that detects unusual outbound connections from build agents

Microsoft also announced enhancements to the npm registry's automated malware detection system, which now incorporates machine learning models trained to identify bulk publication patterns and look-alike name registrations. They committed to reducing the time-to-detection for similar attacks through more aggressive monitoring of newly created maintainer accounts.

Recommendations for npm Users

In light of this incident, developers and organizations should immediately take several steps to harden their npm supply chain:

Verify Package Names Carefully

Double-check package names before running npm install. Use tools like npm search or the npm website to confirm the exact name of the package you intend to install. Be especially cautious when copying installation commands from untrusted sources (e.g., forums, pastebins).

Pin Dependencies and Use Lockfiles

Always commit package-lock.json or npm-shrinkwrap.json to your repository. These files record the exact version and integrity hash of each dependency, preventing accidental installation of a different package with a similar name. Enforce lockfile integrity in CI by using npm ci instead of npm install.

Implement Least-Privilege CI/CD Secrets

Never give a build job blanket access to all secrets. Use CI/CD platforms' ability to scope secrets to specific jobs or environments. For example, only provide the secrets needed for a particular deployment stage, and avoid exposing high-value credentials in development builds.

Use Scoped Packages and Organizations

Scoped packages (e.g., @mycompany/my-package) reduce the risk of typosquatting because they require both the scope and package name to be correct. Encourage internal libraries to be published under a verified organizational scope.

Monitor Registry Activity

Set up alerts for newly published packages whose names closely match your critical dependencies. Several open-source tools can watch for typosquatting releases in real time and notify you before a developer accidentally installs one.

Adopt OIDC and Trusted Publishing

Modern package registries support tokenless publishing using OpenID Connect (OIDC). By linking your CI/CD job directly to the registry using identity tokens, you eliminate long-lived API keys that can be stolen. Microsoft and npm have promoted this as a best practice to reduce the impact of credential theft.

Broader Supply Chain Security Concerns

The vpmdhaj incident is not isolated. It fits a pattern of scaling software supply chain attacks that exploit the automation and trust inherent in modern development workflows. In 2025, npm saw a 40% increase in malicious package publications compared to the previous year, with typosquatting accounting for over 60% of those (according to the 2026 State of the Software Supply Chain report).

Attackers have industrialized the process. They use scripts to generate variations of popular package names, register them across multiple accounts and registries (PyPI, RubyGems, etc.), and include payloads that are frequently updated to evade detection. The low cost and high potential reward make package registries a favored target for cybercriminals and state-sponsored groups alike.

This incident also highlights the tension between open-source accessibility and security. While the npm registry's open nature has fueled innovation, it also provides a low-friction entry point for attackers. The community must continue to invest in automated defenses, developer education, and stronger identity verification for maintainers.

Microsoft's ownership of npm (since 2020) and GitHub places it in a unique position to bridge the gap between development and security. The integration of GitHub's code analysis, secret scanning, and dependency insights with npm's publication data creates a feedback loop that can catch such attacks earlier. However, as this four-hour blitz shows, there is still room for improvement in detection speed and proactive blocking.

Conclusion

The 14 typosquatted packages published by vpmdhaj on May 28, 2026, serve as a stark reminder that the npm ecosystem remains a battlefield. In just four hours, an automated account was able to plant malware designed to steal the secrets that underpin modern software delivery. The incident underscores the need for constant vigilance at every stage of the development lifecycle – from typing the install command to monitoring runtime behavior.

Developers must treat every third-party package with healthy skepticism, verify before installing, and lock down their CI/CD pipelines. Meanwhile, platform providers like Microsoft must keep closing the detection gap, using machine learning and behavioral analysis to spot and neutralize threats faster than ever. The race between attackers and defenders continues, but with the right combination of technology and best practices, the community can reduce the blast radius of these rapid-fire supply chain attacks.