A lone attacker executed an npm supply chain attack on May 28, 2026, publishing 14 malicious packages designed to impersonate popular OpenSearch and Elasticsearch client libraries and silently harvest cloud credentials from developer machines and CI/CD pipelines. Microsoft's security team discovered the campaign and reported it to npm, which removed all 14 packages within hours of detection.
// 01 npm Supply Chain Attack: Technical Details
The npm supply chain attack relied on typosquatting — registering package names close enough to legitimate, widely-used libraries to trap developers who search for or manually specify dependency names. The attacker operated under the alias vpmdhaj (contact email: a39155771@gmail.com) and published all 14 packages within a four-hour window on May 28, 2026, targeting developers building on the OpenSearch and Elasticsearch search platforms.
Version inflation added credibility: rather than publishing v0.0.1, packages launched at versions like 1.0.9108 and 2.1.9201, implying an established release history. The package.json metadata spoofed the legitimate opensearch-project/opensearch-js repository as the homepage, repository, and bugs fields — making the packages appear to be official or affiliated releases at a glance.
The 14 malicious packages were:
Scoped packages (under the attacker-controlled @vpmdhaj namespace):
@vpmdhaj/elastic-helper(v1.0.7269)@vpmdhaj/devops-tools(v1.0.7267)@vpmdhaj/opensearch-setup(v1.0.7267)@vpmdhaj/search-setup(v1.0.7268)
Unscoped packages:
opensearch-security-scanner(v1.0.10)opensearch-setup(v1.0.9103)opensearch-setup-tool(v1.0.9108)opensearch-config-utility(v1.0.9106)search-engine-setup(v1.0.9108)search-cluster-setup(v1.0.9104)elastic-opensearch-helper(v1.0.9108)vpmdhaj-opensearch-setup(v1.0.9102)env-config-manager(v2.1.9201)app-config-utility(v1.0.9300)
Payload delivery via npm preinstall hooks
The malware activated through npm's preinstall lifecycle hook — a script that executes automatically when npm install runs, before any project code is invoked. This means a developer does not need to require() or import the package for the payload to fire. Installing the package is sufficient.
The two-stage payload architecture:
Stage 1 — HTTP C2 beacon: The preinstall script contacted an attacker-controlled command-and-control server, identifying itself with a distinctive X-Supply: 1 HTTP header and downloading a compiled binary payload.
Stage 2 — Bun-compiled credential harvester: The ~195 KB binary, compiled with the Bun JavaScript runtime, systematically swept the victim environment for cloud and CI/CD secrets:
- AWS credentials via EC2 instance metadata, ECS task roles, and Secrets Manager across 16+ regions
- HashiCorp Vault tokens
- GitHub Actions workflow credentials
- npm publish tokens (enabling further downstream supply chain pivoting)

A related but separate OpenSearch incident: A distinct incident on May 11, 2026, saw threat actors compromise the legitimate @opensearch-project/opensearch npm account itself. Versions 3.5.3, 3.6.2, 3.7.0, and 3.8.0 were injected with malware for approximately 2.5 hours before removal. The OpenSearch project published a security advisory and rotated all CI/CD secrets. The vpmdhaj typosquatting campaign described here is a separate attack, illustrating the sustained targeting of the OpenSearch ecosystem from multiple directions.
// 02 Exploitation Status and Threat Landscape
No CVE has been assigned to the vpmdhaj campaign itself. The related GitHub Security Advisory GHSA-27f5-xjrr-q9ff covers the broader OpenSearch npm account compromise from May 11.
Download counts for the 14 malicious packages were not disclosed by npm or Microsoft, leaving the true scope of affected installations unclear. The four-hour publication-to-detection window limits the likely blast radius, but any organization whose CI/CD pipeline ran npm install against unverified package lists during that window should treat the incident as a confirmed compromise until credentials are rotated and logs are reviewed.
npm supply chain attacks using typosquatting have become a primary vector for cloud credential theft in DevOps environments. Attackers target package ecosystems because developers routinely install packages without auditing provenance, and CI/CD pipelines run with elevated service account privileges — making a single compromised install worth far more than a typical endpoint breach. Stolen npm publish tokens, specifically, can enable further downstream attacks: an attacker with a valid publish token can inject malware into the victim organization's own packages, reaching their downstream consumers.
// 03 Who Is Affected
Any developer, team, or automated CI/CD pipeline that ran npm install and pulled one of the 14 packages between May 28 and May 29, 2026, is potentially affected.
Highest-risk profiles:
- Teams building with OpenSearch or Elasticsearch client libraries who may have searched for setup or helper utilities
- Organizations with CI/CD pipelines that auto-resolve npm dependencies without lockfiles or integrity checks
- Developers experimenting with search stack configurations who install utilities without auditing package authors
- Any environment where
npm installruns with access to AWS IAM roles, GitHub tokens, or HashiCorp Vault
// 04 What You Should Do Right Now
- Audit your dependency trees immediately. Check
package-lock.json,npm-shrinkwrap.json, and CI/CD install logs for any of the 14 package names:
“bash npm list --all 2>/dev/null | grep -E "vpmdhaj|opensearch-setup|opensearch-config|search-cluster|elastic-opensearch|env-config-manager|app-config-utility|search-engine-setup|opensearch-security-scanner" “
- Rotate all cloud and CI/CD credentials immediately on any system that installed these packages — AWS access keys, GitHub Personal Access Tokens, npm auth tokens, and HashiCorp Vault tokens. Do not wait for confirmation of exfiltration. Treat any exposure as confirmed.
- Review AWS CloudTrail and GitHub audit logs from May 28 onward for unexpected API calls: new IAM user creation, cross-region S3 access, unusual Secrets Manager reads, new npm package publishes, or GitHub Actions workflow modifications.
- Search network logs for outbound HTTP requests bearing the
X-Supply: 1header or connections to unknown endpoints initiated during npm install runs on May 28–29.
- Disable automatic preinstall script execution to prevent future hook-based attacks:
“bash npm config set ignore-scripts true ` Note: this may break legitimate packages that rely on build scripts. Evaluate the tradeoff per-project and use –ignore-scripts` selectively.
- Commit and pin a
package-lock.json. Lockfiles that pin specific package versions and integrity hashes prevent silent resolution to attacker-controlled packages even when typosquatted names appear in apackage.json.
// 05 Background: Understanding the Risk
Supply chain attacks via package managers are one of the highest-leverage attack vectors for credential theft. Unlike phishing, which requires a user decision, a malicious npm package executes automatically the moment npm install runs — no click, no social engineering beyond getting a package name close to a legitimate one.
The npm ecosystem has structural properties that make typosquatting effective:
- No name reservation: Unless a package owner proactively registers all plausible typo variants, attackers can claim them. The
opensearch-projectnamespace is protected, but generic names likeopensearch-setup-toolorenv-config-managerare open. - Trust-by-default install behavior: npm does not verify that a package's stated
repositoryfield matches its actual publisher. Metadata spoofing is trivially easy. - High-value execution context: CI/CD systems run
npm installwith service account credentials that carry cloud provisioning rights — an attacker who can run code in a GitHub Actions runner has access to all secrets that runner can read.
The vpmdhaj campaign follows a well-documented pattern. The DPRK-linked PromptMink campaign, typosquatted PyPI attacks targeting cryptocurrency developers, and the ShadowRay compromise all used package manager delivery to harvest secrets from developer environments. The consistency of this technique reflects its effectiveness.
Microsoft's detection capability here is notable. The company has invested in monitoring public package registries for malicious uploads, and their response — identifying the shared stager, the X-Supply: 1 beacon header, and the Bun-compiled payload — suggests automated signature matching across newly published packages. The OpenSearch project's response to the May 11 account compromise was textbook: lock the GitHub organization, rotate all CI/CD secrets, pause GitHub Actions, and restore from known-good state.
// 06 Conclusion
Any team working with OpenSearch or Elasticsearch npm packages that ran installs on May 28–29, 2026 should rotate all cloud and CI/CD credentials immediately — the attack required no user interaction beyond a routine npm install, making it one of the more operationally silent credential theft vectors currently active in the wild. Commit a package-lock.json, enable integrity checking in CI, and audit your npm install logs before your next deployment.
For any query contact us at contact@cipherssecurity.com
