CVE-2026-48995

What it actually does

pnpm versions prior to 10.33.4 and 11.0.7 do not record or enforce cryptographic integrity hashes for dependencies fetched from https://codeload.github.com. If the codeload.github.com delivery path is malicious, compromised, intercepted through a trusted local/network configuration, or otherwise made to return a different tarball than the one originally resolved, pnpm may install the attacker-supplied archive even when a lockfile is present. This weakens the lockfile's expected reproducibility and integrity guarantees and can allow arbitrary dependency content to enter a build, developer workstation, or CI/CD environment.

Why it matters to the business

The main risk is software supply-chain compromise: malicious code could be introduced during dependency installation and then run in developer environments, build pipelines, tests, package scripts, or production artifacts. Because pnpm is commonly used in JavaScript and Node.js development workflows, successful exploitation can lead to credential theft, source-code tampering, poisoned releases, or downstream compromise of applications built from affected dependencies. The CVSS impact is high but exploitation requires a specific dependency source and a compromised or malicious delivery path; EPSS is currently low and there is no known KEV listing or ransomware association, so remediation should be prioritized for build systems and projects that install GitHub-hosted tarball dependencies.

How an attack unfolds

An attacker first needs influence over the tarball returned for a dependency hosted through codeload.github.com, such as by compromising that service path, abusing a victim's local machine or proxy/DNS/TLS trust configuration, or otherwise causing pnpm to receive attacker-controlled archive content from a GitHub codeload URL. A target project must then run an affected pnpm version and install dependencies that include a codeload.github.com-hosted package. Because vulnerable pnpm lockfiles do not bind those codeload downloads to a stored hash, pnpm accepts and installs the returned tarball instead of rejecting it for integrity mismatch. If the malicious package contains install scripts or runtime code, it can execute during installation or later when the application imports or runs the dependency, enabling theft of secrets, alteration of source or build outputs, persistence in the development workflow, or propagation into released software.

How to fix it

Upgrade pnpm to a fixed version: 10.33.4 or later for the 10.x line, or 11.0.7 or later for the 11.x line. Rebuild CI/CD images, developer toolchains, package-manager bootstrap scripts, and pinned tool versions so that all dependency installation paths use a fixed pnpm release. Regenerate or refresh lockfiles after upgrading where appropriate, especially for projects that depend on GitHub tarball, Git URL, or codeload.github.com-sourced dependencies. Reduce exposure by preferring registry packages with integrity metadata over direct GitHub tarball dependencies, pinning immutable commit references rather than branches/tags where GitHub sources are unavoidable, and using an internal artifact proxy or dependency mirror that enforces content integrity. As compensating controls, restrict outbound dependency downloads from build systems to approved hosts, isolate dependency installation from sensitive credentials, disable package lifecycle scripts where feasible, and require clean rebuilds of artifacts produced while vulnerable pnpm versions were in use.

How to confirm the fix worked

Confirm the installed pnpm version reports 10.33.4 or later, or 11.0.7 or later, with `pnpm --version` in developer environments, CI runners, build containers, and release pipelines. Search repository lockfiles and package manifests for codeload.github.com, github.com tarball dependencies, GitHub shorthand dependencies, and Git URL dependencies, then verify those projects are rebuilt with a fixed pnpm version. Validate CI/CD base images and package-manager setup steps do not install older pnpm releases through Corepack, npm global installs, Docker image layers, or cached tool directories. Perform a clean dependency installation from an empty store/cache and confirm expected dependencies resolve consistently. For high-assurance projects, compare installed package contents against known-good source commits or internally mirrored artifacts and review any release artifacts built while affected pnpm versions were active.

Typical attack path

1. Identify a target project or build process using pnpm versions earlier than 10.33.4 or 11.0.7.
2. Confirm the dependency graph includes packages fetched from https://codeload.github.com rather than integrity-pinned registry artifacts.
3. Gain the ability to serve or redirect a malicious tarball for the expected codeload.github.com dependency request, such as through compromised local configuration, proxying, DNS manipulation, or a compromised delivery path.
4. Wait for a developer workstation or CI/CD job to run pnpm install or an equivalent dependency installation command.
5. Have the vulnerable pnpm client download and install the attacker-controlled tarball without lockfile hash verification.
6. Use malicious package code, lifecycle scripts, or modified dependency contents to steal credentials, alter builds, implant backdoors, or compromise downstream artifacts.

How to detect it

To determine whether exploitation may already have occurred, review package installation activity rather than only application runtime logs. Key sources include CI/CD job logs, build container logs, developer endpoint telemetry, shell history, package-manager logs, proxy/DNS/firewall logs, EDR process telemetry, and repository change history. Look for pnpm install activity using vulnerable versions, especially where dependency downloads contacted codeload.github.com. Correlate those installs with unexpected package lifecycle scripts, new or modified files under node_modules, unexplained changes to lockfiles or package manifests, outbound network connections from install scripts, secret reads during build jobs, and modifications to release artifacts. Compare downloaded or cached tarballs from pnpm stores against expected GitHub commit contents where possible. Because there are no public reports of active exploitation or known threat actors for this issue, detection should focus on behavioral anomalies: unexpected codeload tarball content, package install scripts spawning shells or network tools, dependency cache entries that do not match source commits, and build jobs accessing credentials or external endpoints not normally used during dependency installation.

• https://codeload.github.com/
• codeload.github.com
• pnpm install
• pnpm add
• pnpm --version
• pnpm-lock.yaml
• node_modules/.pnpm/
• package.json
• preinstall
• install
• postinstall
• prepare
• dependenciesMeta
• git+https://github.com/
• github:
• tarball: https://codeload.github.com/
• curl https://codeload.github.com/
• wget https://codeload.github.com/

What your security team should do

• Inventory pnpm usage across repositories, CI/CD images, developer bootstrap scripts, and build containers; prioritize systems that build or release production software.
• Upgrade all pnpm installations to 10.33.4 or later, or 11.0.7 or later, and remove cached older toolchain images.
• Search codebases for dependencies resolved from codeload.github.com, direct GitHub tarballs, and GitHub Git URLs; prioritize those projects for lockfile refresh and clean rebuilds.
• Review recent CI/CD and developer install logs for codeload.github.com downloads, dependency lifecycle script execution, unexpected package changes, and secret-access events during install jobs.
• Rotate credentials exposed to dependency installation jobs if suspicious packages, unexpected tarball contents, or anomalous outbound connections are found.
• Adopt build hardening controls: isolated dependency installation, least-privilege CI tokens, restricted egress, artifact provenance, dependency mirrors, and reproducible build verification.
• Where release artifacts were built using vulnerable pnpm versions and codeload.github.com dependencies, consider rebuilding and re-signing from a clean environment with the fixed package manager.