GHSA-jmqm-f2gx-4fjv

What it actually does

npm-registry-fetch can write sensitive registry request data into application, debug, or HTTP client logs, including Authorization headers and npm/private-registry tokens. Anyone who can read those logs obtains reusable credentials with the same registry privileges as the original client. This is a local/log information-disclosure defect, not remote code execution. Listed affected components are npm-registry-fetch and github.com/CosmWasm/wasmd.

Why it matters to the business

Stolen registry credentials can let an attacker impersonate developers or CI, pull private packages, or publish malicious versions and poison downstream software. The issue was published in 2020, is not on CISA KEV, is not associated with ransomware, and has no recorded exploit maturity, so mass opportunistic attacks are unlikely; unrotated tokens from historical logs remain a supply-chain risk until patched and rotated.

How an attack unfolds

An attacker obtains logs from a workstation, CI job, container stdout, or log store that recorded npm-registry-fetch traffic while a vulnerable version was authenticating to a registry. They extract an Authorization header or _authToken, replay it against the public npm registry or a private registry, and then download private packages or publish/tamper with packages. There is no unauthenticated remote trigger; exploitation requires log access plus reuse of the recovered secret. No named threat actors are tied to this issue.

How to fix it

Upgrade npm-registry-fetch to 8.1.1 on the 8.x line or 4.0.5 on the 4.x line. If github.com/CosmWasm/wasmd is in use, upgrade to 0.53.0 or later. After upgrading, rotate every npm token, registry password, and CI secret that may have been logged, and treat historical logs as sensitive until reviewed. Disable debug/trace HTTP logging in CI and production, redact Authorization and Cookie headers at the logger, and restrict who can read build and application logs.

How to confirm the fix worked

Inventory npm-registry-fetch with npm ls npm-registry-fetch and confirm versions are >=8.1.1 or >=4.0.5 as applicable; for wasmd, confirm go.mod/go.sum shows 0.53.0 or later. Perform a registry fetch with prior debug logging enabled and verify Authorization headers and tokens are no longer written. Search retained CI and application logs for previously emitted secrets and rotate any that appear.

Typical attack path

1. Find a host, CI pipeline, or log archive that ran a vulnerable npm-registry-fetch (or listed wasmd) build while authenticating to a package registry.
2. Gain read access to those logs via overly permissive log storage, leaked CI artifacts, local file access, or a compromised log pipeline.
3. Search logs for Authorization headers, bearer tokens, or npm _authToken values tied to registry requests.
4. Replay the recovered credential against the npm or private registry API from an attacker-controlled client.
5. Abuse the stolen identity to exfiltrate private packages or publish malicious package versions consumed downstream.

How to detect it

Exploitation shows up as reuse of stolen registry credentials, not a distinctive payload. Review npm or private-registry audit logs and IdP/CI identity logs for token use from unexpected IPs, user-agents, or locations, and for unexpected publishes, token creation, or private-package downloads. Inspect application, CI, and container logs around install/publish for Authorization or _authToken material. No named APT campaigns or KEV ransomware use is documented for this issue.

• _authToken=
• //registry.npmjs.org/:_authToken
• Authorization: Bearer npm_
• npm-registry-fetch
• PUT https://registry.npmjs.org/

What your security team should do

• Patch npm-registry-fetch to 8.1.1 or 4.0.5 and wasmd to 0.53.0 wherever older versions remain.
• Rotate all npm and private-registry tokens used by developers and CI that ran vulnerable versions.
• Hunt historical application, CI, and container logs for leaked Authorization headers and _authToken values.
• Enforce auth-header redaction and disable verbose HTTP client logging in build pipelines.
• Restrict access to CI logs and artifact stores; prioritize token rotation over emergency KEV-style response given age and lack of known in-the-wild exploitation.