CVE-2026-9496

What it actually does

The pacote package’s addGitSha path applies regex replacement and unbounded string manipulation to attacker-controlled spec.rawSpec values. A crafted package specifier can drive pathological CPU use in the Node.js process, stalling event-loop work or crashing the process. Confidentiality and integrity of data are not affected; availability of any consumer that resolves git/npm specs through pacote is.

Why it matters to the business

CI/CD jobs, npm installs, and any service that fetches packages via pacote can hang or fail, delaying releases and consuming compute. Pacote sits under the npm ecosystem, so blast radius can include developer workstations and build fleets even though no customer-specific products were listed. The issue is about 126 days old, is not in CISA KEV, has no public exploit maturity, and is not tied to ransomware; EPSS remains low (~0.0063) but rose about 82% over 30 days, so treat as a medium-urgency availability risk rather than an active mass-exploitation emergency.

How an attack unfolds

An unauthenticated attacker who can influence a package specifier consumed by a vulnerable pacote version (for example via a dependency field, install argument, lockfile, or an API that accepts git/npm specs) supplies a malformed spec.rawSpec. That value reaches addGitSha, where regex replacement and string handling run for a long time on a single thread. The Node process becomes unresponsive or exits, denying package resolution and any co-located workload. No named threat actors or KEV campaigns are associated with this CVE; public exploit maturity is none, so opportunistic abuse of untrusted spec intake is the realistic scenario rather than a known in-the-wild playbook.

How to fix it

Upgrade pacote off the vulnerable range (11.2.7 and later as described) as soon as a patched release is published by the maintainer; no exact fixed versions were supplied with this record, so pin to a verified patched version from the npm advisory and re-resolve lockfiles. Until a patch is available, do not pass untrusted specifiers into pacote, npm install, or git-based package URLs; restrict who can change package.json/lockfiles; and isolate package-resolution workers with CPU/time limits so one hung process cannot take down the host. Rebuild images and CI caches after the upgrade so old nested copies of pacote are not left in node_modules.

How to confirm the fix worked

Inventory all lockfiles and images for pacote >= 11.2.7 (direct or transitive, including copies bundled with npm). After upgrading, confirm the resolved pacote version is the patched release and that nested copies were replaced. In a non-production check, exercise normal git and registry spec resolution and confirm processes stay healthy under CPU and timeout budgets. Review services that accept package names or git URLs from users and verify those inputs are rejected or sandboxed before they reach pacote.

Typical attack path

1. Identify a target that resolves npm or git package specifiers with pacote 11.2.7 or later (install CLI, registry proxy, CI resolver, or app that shells out to npm).
2. Place or submit an untrusted package specifier so it is parsed into spec.rawSpec (manifest, install request, or API input).
3. Trigger resolution so addGitSha runs the expensive regex/string path.
4. Hold the Node event loop with CPU spin until installs, builds, or the hosting service stall or crash.
5. Repeat against shared runners or services to amplify downtime; no privilege or user interaction is required if spec intake is network-exposed.

How to detect it

There is no public exploit, KEV listing, or named actor activity to hunt for, so look for availability symptoms rather than a known payload. On hosts that run npm/pacote (CI runners, install proxies, Node services), alert on Node processes stuck at high CPU during package resolution, install jobs that exceed normal duration then die, and repeated failures resolving git-based packages. Capture stack traces of hung node/npm processes and look for pacote’s addGitSha on the stack. Review access logs for bursts of unusual package specifiers (very long strings, repetitive punctuation, or git SHA-like fragments) immediately before a stall. Correlate with process crash dumps, OOM or timeout kills, and CI job aborted-on-timeout events around package install steps. Absence of these artifacts does not prove the bug was unused; it only means a noisy DoS may not have been logged.

• addGitSha
• pacote
• spec.rawSpec
• node.*high cpu.*npm
• npm install.*timeout
• git+ssh://
• git+https://
• process: npm
• process: node

What your security team should do

• Treat as a network-reachable availability issue (CVSS 7.5) for any internet-facing resolver; patch or constrain spec intake first on CI and install gateways.
• Enumerate transitive pacote usage across npm lockfiles and container images; do not assume only direct dependents are exposed.
• Apply CPU/time limits and process isolation to package-install workers until a patched pacote version is pinned.
• Block or sanitize untrusted git/npm specifiers at API and CI boundaries; require review for lockfile changes.
• Watch EPSS and advisory channels—the 30-day rise is a signal to accelerate patching even though KEV and exploit maturity are currently negative.
• After upgrade, rotate any long-lived build agents that may still have the old module in cache.