OpenSearch npm compromise: who’s affected and what to do

OpenSearch disclosed a short-window OpenSearch npm package compromise affecting unreleased development versions of its JavaScript client. If your build pipeline pulled the malicious versions, treat the environment as compromised, rotate secrets, and validate downstream artifacts.

What happened in the OpenSearch npm package compromise?

OpenSearch reported that a threat actor published malware-tainted development versions of the @opensearch-project/opensearch npm package (versions 3.5.3, 3.6.2, 3.7.0, 3.8.0) for a roughly 2.5-hour window on May 11 (EDT), after which the malicious packages were removed (OpenSearch forum advisory).

If your CI/CD or developer workstations installed the package during that window, OpenSearch recommends you treat the host as compromised, rotate any credentials accessible from that system, and remove and reinstall from a verified source (OpenSearch forum advisory).

Why this matters, even if you don’t use OpenSearch

Software supply chain incidents increasingly exploit a familiar reality: build systems have broad network access, long-lived tokens, and quiet trust relationships.

OpenSearch identified a supply chain attack targeting the npm ecosystem, where an attacker gained unauthorized access to publish artifacts that contained malware (OpenSearch forum advisory).

OpenSearch’s disclosure is notable for two reasons:

Clear scoping: the project stated the impacted artifacts were unreleased development versions, and that previously released stable packages and downstream releases were not affected.
Operational response signals: the project reported it locked its GitHub organization and paused CI/CD and GitHub Actions as part of secret rotation and containment.

Even if you don’t run OpenSearch, the pattern is applicable to any organization that:

Builds software in GitHub Actions or similar hosted runners
Uses npm packages directly in production builds
Pulls dependencies dynamically during CI
Distributes internal packages from a private registry that relies on upstream integrity

Who is affected (practical scoping)

You are likely not affected if:

You only installed the stable, released versions of the OpenSearch JavaScript client.
You did not install the listed versions during the short May 11 (EDT) window described by OpenSearch.

You may be affected if:

A developer workstation or CI runner pulled @opensearch-project/opensearch@3.5.3, 3.6.2, 3.7.0, or 3.8.0 during the timeframe of the incident.
Your pipeline uses semver ranges (for example ^3.7.0) that can resolve to newly published versions without a lockfile guard.
You cache dependencies (npm, yarn, pnpm) and then rehydrate them across builds without verifying integrity.

A quick note on “unreleased development versions”

Supply chain incidents frequently involve versions that were never intended for general availability. That does not guarantee low risk: pipelines can still pull them if tags or version ranges resolve unexpectedly, or if a developer uses a direct version install for testing.

What to do now: incident response playbook

OpenSearch’s guidance is direct: treat the host as compromised and rotate secrets if you installed the package during the window. Below is a structured playbook for security and engineering teams.

1) Confirm whether you pulled the impacted versions

Focus on evidence, not assumptions.

Review CI logs for npm install, yarn add, or pnpm add outputs.
Inspect lockfiles (package-lock.json, yarn.lock, pnpm-lock.yaml) in commits around May 11.
Check artifact build provenance: which runner, which workflow, which dependency cache.

If your organization uses centralized logging, create a scoped search for:

The package name @opensearch-project/opensearch
The four versions listed by OpenSearch
Timestamps aligned to May 11 (EDT)

2) Contain: isolate any potentially exposed build hosts

If you have credible evidence of installation:

Quarantine the CI runner or workstation image.
Preserve relevant logs for investigation.
Halt promotion of artifacts built in the window until validated.

3) Rotate secrets accessible from the environment

This is typically the highest-leverage step. Rotate, at minimum:

CI provider tokens (GitHub Actions tokens, runner registration tokens)
Cloud access keys (AWS, GCP, Azure)
Container registry credentials
Signing keys, if accessible from the environment
Deploy keys and package publishing tokens

OpenSearch explicitly recommends rotating all credentials and secrets accessible from the system that installed the package.

4) Validate build outputs and downstream deployments

If compromised code executed in CI, the risk isn’t limited to that one dependency tree. Consider:

Rebuilding artifacts from a known-good commit and clean environment.
Comparing artifact hashes and SBOMs between “suspect” and “clean rebuild” versions.
Reviewing any deployments initiated by the suspect pipeline execution.

5) Remove and reinstall from verified sources

OpenSearch recommends removing the package and reinstalling from a verified source. In practice, “verified source” means:

Use lockfiles and deterministic installs (npm ci) where possible.
Prefer internal mirrors or proxies with strict integrity policies.
Validate package integrity hashes when supported.

Defensive lessons to apply beyond this incident

Lock dependency resolution in CI

A surprising number of supply chain incidents become incidents because a pipeline resolves “latest compatible” dependencies at build time.

Minimum standard:

Require lockfiles for production builds.
Use deterministic installers (npm ci) rather than best-effort installs.
Fail builds when lockfiles change unexpectedly.

Use least-privilege credentials and short-lived tokens for CI

If a build runner can reach every environment and holds long-lived keys, a compromised dependency becomes a credential-harvesting opportunity. Adopt:

OIDC-based short-lived cloud credentials where available
Separate build and deploy identities
Explicit egress controls for build infrastructure

Treat logs as sensitive data

Connection strings, tokens, and credential-bearing URLs routinely end up in build logs. If your tools log connection strings, assume logs can become a secret store.

Practical controls:

Block secrets in URLs; require secret backends.
Apply log redaction for common patterns.
Restrict log access — it often becomes “wide by default.”

Executive takeaway

This OpenSearch npm incident is a reminder that your build pipeline is part of your attack surface. If you pulled the impacted versions during the reported window, your priorities should be:

Confirm installation and scope of exposure.
Contain and preserve evidence.
Rotate secrets accessible to the affected environment.
Rebuild and validate artifacts before shipping.

Frequently asked questions

Was the OpenSearch stable release affected?

No. OpenSearch stated the impacted artifacts were unreleased development versions of the @opensearch-project/opensearch npm package. Previously released stable packages and downstream OpenSearch releases were not affected (OpenSearch advisory).

Which npm versions were compromised?

Four versions of @opensearch-project/opensearch are listed by OpenSearch as compromised: 3.5.3, 3.6.2, 3.7.0, and 3.8.0. They were available for roughly 2.5 hours on May 11 (EDT) before being removed.

What should teams do if they installed the package?

OpenSearch’s guidance is to treat the affected workstation or CI runner as compromised: quarantine the host, preserve logs, rotate all credentials accessible from the environment, and remove and reinstall the package from a verified source. Rebuild and revalidate any artifacts produced during the window before promoting them.

Should CI/CD secrets be rotated?

Yes, if any system in your build pipeline installed one of the impacted versions during the window. Rotate CI provider tokens, cloud access keys, container registry credentials, signing keys, deploy keys, and package publishing tokens. When in doubt, rotate — the cost of rotation is far lower than the cost of an undetected token leak.

How can teams prevent npm supply chain attacks?

The most effective controls are deterministic installs (npm ci with committed lockfiles), short-lived OIDC-based credentials for CI, separated build and deploy identities, explicit egress allow-listing for build infrastructure, time-based holds before promoting newly published versions of critical dependencies, and centralized monitoring of dependency changes in pull requests.

Separately from this npm compromise, NIST recently published CVE-2026-43826, which describes a logging issue in the OpenSearch provider for Apache Airflow. This is not the same incident as the npm package compromise, but it reinforces the same lesson: treat application logs as potentially sensitive and apply redaction and access controls accordingly.

References

Cyberuptive runs a 24/7 follow-the-sun SOC staffed by U.S.-based analysts, headquartered in Honolulu and serving customers across Asia-Pacific and the U.S. mainland. We help mid-market organizations, MSPs, and Pacific defense subcontractors close the supply chain gaps adversaries are looking for.

Talk to us about a no-obligation supply chain risk review, or read our SOC-as-a-Service overview and Managed Detection and Response overview.