- Top reward
- $1,500
- Top severity paid
- Critical
- Assets in scope
- 12
- Public CVEs
- 28
- Last change
- No changes yet
At a glance
What to know before you start testing.
- Pays from $1,500
- for critical bugs.
- Report on Sorona
- Submit through the program page.
- Partial safe harbor
- Some legal protection; read the terms.
- Publish after a fix
- Coordinate the timing with the company.
Rewards
What Sorona lists as the payout for each severity.
| Severity | Relative size | Reward |
|---|---|---|
| Critical | $1,500+ | |
| High | $700+ | |
| Medium | $300+ | |
| Low |
|
$100 $100 / 1 month Claude Max |
- Safe harbor
-
Partial
Sorona will not pursue legal action against you for good-faith research submitted to us in line with this policy. We cannot speak for the upstream project, its vendor, or any third party, and we do not grant authorization on their behalf.
Summarised with AI from the program policy on Sorona, read 12 Nov 2026, and checked word for word against it. Read the original
Scope
12 assets you may test, 6 excluded.
Web 1
- https://pnpm.io
Products and areas 11
- Configuration and credential handling: .npmrc at every level, per-registry auth tokens and any path that could send one to the wrong host
- Integrity checking on downloaded packages, including the hashes recorded in the lockfile and what happens when one fails to match
- Lifecycle script execution and the controls that decide which dependencies are permitted to run build scripts
- Lockfile handling in full, covering pnpm-lock.yaml parsing, resolution replay and what a lock entry is taken to guarantee
- Package extraction and file placement, including path handling for entries inside a tarball
- pnpm dlx and pnpm exec, plus the patching mechanism behind pnpm patch
- The CLI's own installation and self-update path, which fetches and then executes the binary that runs every later install
- The content-addressable store, its indexing, and the hard links and symlinks it projects into a project's node_modules
- The policy accepts vulnerabilities in supported pnpm releases, currently the 10.x and 11.x lines, through the GitHub advisory form. Its threat model is the real boundary: anything presupposing an attacker who can already write to the store, the lockfile, node_modules or the configuration is excluded
- The registry client: resolution requests, tarball fetching, redirect handling and what a registry response is allowed to change
- Workspace resolution across a monorepo, the workspace: protocol, catalogs and overrides
Out of scope (6)
- Anything that starts from attacker write access to the store, the lockfile, node_modules or pnpm's configuration. The threat model rules this out by name
- Malicious packages published to the npm registry, which is registry abuse rather than a pnpm defect
- Node.js itself, a separate upstream with its own reporting path
- pacquet and pnpr, which the policy places outside the advisory process
- Releases outside the supported 10.x and 11.x lines
- The npm registry service and npm's own CLI, both of which are GitHub's and one of which pays
Rules
What the policy asks of you, and the bug types it won't reward, quoted from Sorona's policy. "We" in these lines means Sorona, not this site.
While testing
-
Submit through sorona.xyz. This project runs no bounty of its own; we validate, coordinate disclosure with the maintainers, and pay you directly.
-
Report through the GitHub advisory form at github.com/pnpm/pnpm/security/advisories , the channel SECURITY.md names, with private vulnerability reporting confirmed enabled
-
Read the threat model before you spend time.
-
Include the pnpm-lock.yaml , the registry configuration and the exact command, since resolution behaviour is the subject of most of the real surface here
Not accepted
-
Anything that starts from attacker write access to the store, the lockfile, node_modules or pnpm's configuration
-
pacquet and pnpr , which the policy places outside the advisory process
-
Releases outside the supported 10.x and 11.x lines
-
Malicious packages published to the npm registry, which is registry abuse rather than a pnpm defect
-
The npm registry service and npm's own CLI, both of which are GitHub's and one of which pays
-
Node.js itself, a separate upstream with its own reporting path
Summarised with AI from the program policy on Sorona, read 12 Nov 2026, and checked word for word against it. Read the original
Changes
Tracked since 11 Nov 2026. Last checked 1 hour ago.
No changes yet. When the rewards or scope move, you will see it here and in the RSS feed.
Public CVEs
Published vulnerabilities in this vendor's products, from the NVD.
| CVE | Summary | Severity | Published |
|---|---|---|---|
| CVE-2026-59194 | pnpm is a package manager. Prior to 10.34.4 and 11.7.0, a crafted patch entry could resolve outside the configured patches directory and cause pnpm patch-remove to delete an arbitrary reachable file. This vulnerability is fixed in 10.34.4 and 11.7.0. | High 7.1 | 6 Jul 2026 |
| CVE-2026-59195 | pnpm is a package manager. Prior to 10.34.4 and 11.8.0, pnpm accepts package names from the env lockfile configDependencies section and uses those names directly when creating config dependency symlinks under node_modules/.pnpm-config. A malicious repository can commit a crafted pnpm-lock.yaml whose env-lockfile document contains a traversal-shaped config dependency name. During pnpm install, pnpm | High 8.2 | 6 Jul 2026 |
| CVE-2026-59196 | pnpm is a package manager. Prior to 10.34.4 and 11.7.0, a crafted lockfile alias could be joined directly under a hoisted node_modules directory. Traversal aliases could escape that directory, while reserved aliases such as .bin or .pnpm could overwrite pnpm-owned layout. This vulnerability is fixed in 10.34.4 and 11.7.0. | High 7.1 | 6 Jul 2026 |
| CVE-2026-55697 | pnpm is a package manager. Prior to 10.34.2 and 11.5.3, pnpm can install configDependencies declared in pnpm-workspace.yaml before command dispatch. Before the patch, a repository could declare pacquet or @pnpm/pacquet as a config dependency and pnpm treated that repository-controlled dependency as an install-engine opt-in. During install, pnpm resolved a platform-specific @pacquet/<platform>-<arc | High 7.5 | 25 Jun 2026 |
| CVE-2026-55698 | pnpm is a package manager. Prior to 10.34.2 and 11.5.3, pnpm can persist package-manager bootstrap metadata in the first YAML document of pnpm-lock.yaml. Before the patch, direct pnpm execution trusted an already resolved packageManagerDependencies entry when the committed env lockfile contained matching pnpm and @pnpm/exe versions. A malicious repository could therefore commit package-manager loc | High 8.8 | 25 Jun 2026 |
| CVE-2026-55699 | pnpm is a package manager. Prior to 10.34.2 and 11.5.3, Manifest bin object keys such as "", ".", and ".." passed pnpm's bin-name guard. When a malicious package was installed globally, later global remove, update, or add-replacement flows could re-derive those names from the installed manifest and pass path.join(globalBinDir, binName) to removeBin. For "." this targets the global bin directory; f | Medium 6.5 | 25 Jun 2026 |
| CVE-2026-55700 | pnpm is a package manager. From 11.3.0 until 11.5.3, `pnpm stage download` derived a local filename from registry-controlled package name and version fields. A crafted manifest could escape the selected download directory and overwrite another reachable file. The merged fix validates both fields, derives one safe filename, and verifies the final destination before writing. This vulnerability is fi | High 7.1 | 25 Jun 2026 |
| CVE-2026-50021 | pnpm is a package manager. Prior to 10.34.0 and 11.4.0, pnpm's tarball extraction worker skips integrity verification when the integrity field is absent from the lockfile resolution. If an attacker can both modify pnpm-lock.yaml to remove the integrity: field and cause the referenced registry URL to serve altered package content, pnpm install --frozen-lockfile can install the altered package witho | Medium 6.8 | 25 Jun 2026 |
| CVE-2026-50573 | pnpm is a package manager. Prior to 10.34.0 and 11.4.0, `pnpm install` in non-frozen mode can accept new remote package content after detecting that the downloaded tarball does not match the integrity recorded in pnpm-lock.yaml. When a package is already locked with an integrity value, and the registry later serves different metadata and tarball content for the same package name and version, pnpm | Medium 6.8 | 25 Jun 2026 |
| CVE-2026-55180 | pnpm is a package manager. Prior to 10.34.2 and 11.5.3, pnpm and pacquet expanded ${ENV_VAR} placeholders from repository-controlled .npmrc and pnpm-workspace.yaml into registry request destinations and registry credentials. A malicious repository could cause dependency resolution to send victim environment secrets to an attacker-selected registry before lifecycle scripts run. This vulnerability i | Medium 6.5 | 25 Jun 2026 |
| CVE-2026-55487 | pnpm is a package manager. Prior to 10.34.2 and 11.5.3, the generic peer-suffix normalizer also stripped parenthesized text from git, URL, tarball, file, and other opaque locators. Approval for one source string could therefore authorize a different attacker-controlled source whose locator normalized to the same value. This vulnerability is fixed in 10.34.2 and 11.5.3. | High 7.5 | 25 Jun 2026 |
| CVE-2026-48995 | pnpm is a package manager. Prior to 10.33.4 and 11.0.7, a malicious codeload.github.com server can serve whatever tarball it wants and pnpm will install it regardless of the lockfile. The lockfile does not store the hash of the dependencies from https://codeload.github.com. This means that if this server was compromised or a person's machine configuration was compromised, pnpm would download and i | Medium 4.8 | 25 Jun 2026 |
| CVE-2026-50014 | pnpm is a package manager. Prior to 10.34.0 and 11.4.0, pnpm passes the lockfile-controlled git resolution.commit value to git fetch without a -- separator or commit-format validation. For git dependencies fetched through the shallow-fetch path, a malicious lockfile can replace the expected 40-character commit hash with a Git option such as --upload-pack=<command>. For SSH and local transports, -- | Medium 6.4 | 25 Jun 2026 |
| CVE-2026-50015 | pnpm is a package manager. Prior to 10.34.0 and 11.4.0, pnpm's patch application pipeline (@pnpm/patch-package) performs no path validation on file paths extracted from .patch files. An attacker who contributes a malicious patch file via a pull request can write attacker-controlled content to or delete arbitrary files on the filesystem during pnpm install, as the user running the install. The diff | High 7.3 | 25 Jun 2026 |
| CVE-2026-50016 | pnpm is a package manager. Prior to 10.34.0 and 11.4.0, pnpm allows a transitive dependency alias from registry package metadata to contain path traversal segments. During install, pnpm later uses that alias as a filesystem path when linking dependency nodes. As a result, a registry package can cause `pnpm install --ignore-scripts` to replace paths in the current project with symlinks to attacker- | High 8.8 | 25 Jun 2026 |
| CVE-2026-50017 | pnpm is a package manager. Prior to 10.34.0 and 11.4.0, pnpm can send user-level unscoped npm authentication credentials to a registry chosen by a repository-local .npmrc file. In the reproduced case, the user's npm config contains a default registry and an unscoped _authToken. The repository does not provide a token-bearing auth line. It only sets registry= to a different registry URL. During nor | Medium 6.9 | 25 Jun 2026 |
| CVE-2026-24056 | pnpm is a package manager. Prior to version 10.28.2, when pnpm installs a `file:` (directory) or `git:` dependency, it follows symlinks and reads their target contents without constraining them to the package root. A malicious package containing a symlink to an absolute path (e.g., `/etc/passwd`, `~/.ssh/id_rsa`) causes pnpm to copy that file's contents into `node_modules`, leaking local data. The | Medium 6.7 | 26 Jan 2026 |
| CVE-2026-24131 | pnpm is a package manager. Prior to version 10.28.2, when pnpm processes a package's `directories.bin` field, it uses `path.join()` without validating the result stays within the package root. A malicious npm package can specify `"directories": {"bin": "../../../../tmp"}` to escape the package directory, causing pnpm to chmod 755 files at arbitrary locations. This issue only affects Unix/Linux/mac | Medium 6.7 | 26 Jan 2026 |
| CVE-2026-23888 | pnpm is a package manager. Prior to version 10.28.1, a path traversal vulnerability in pnpm's binary fetcher allows malicious packages to write files outside the intended extraction directory. The vulnerability has two attack vectors: (1) Malicious ZIP entries containing `../` or absolute paths that escape the extraction root via AdmZip's `extractAllTo`, and (2) The `BinaryResolution.prefix` field | Medium 6.5 | 26 Jan 2026 |
| CVE-2026-23889 | pnpm is a package manager. Prior to version 10.28.1, a path traversal vulnerability in pnpm's tarball extraction allows malicious packages to write files outside the package directory on Windows. The path normalization only checks for `./` but not `.\`. On Windows, backslashes are directory separators, enabling path traversal. This vulnerability is Windows-only. This issue impacts Windows pnpm use | Medium 6.5 | 26 Jan 2026 |
| CVE-2026-23890 | pnpm is a package manager. Prior to version 10.28.1, a path traversal vulnerability in pnpm's bin linking allows malicious npm packages to create executable shims or symlinks outside of `node_modules/.bin`. Bin names starting with `@` bypass validation, and after scope normalization, path traversal sequences like `../../` remain intact. This issue affects all pnpm users who install npm packages an | Medium 6.5 | 26 Jan 2026 |
| CVE-2025-69262 | pnpm is a package manager. Versions 6.25.0 through 10.26.2 have a Command Injection vulnerability when using environment variable substitution in .npmrc configuration files with tokenHelper settings. An attacker who can control environment variables during pnpm operations could achieve Remote Code Execution (RCE) in build environments. This issue is fixed in version 10.27.0. | High 7.5 | 7 Jan 2026 |
| CVE-2025-69263 | pnpm is a package manager. Versions 10.26.2 and below store HTTP tarball dependencies (and git-hosted tarballs) in the lockfile without integrity hashes. This allows the remote server to serve different content on each install, even when a lockfile is committed. An attacker who publishes a package with an HTTP tarball dependency can serve different code to different users or CI/CD environments. Th | High 7.5 | 7 Jan 2026 |
| CVE-2025-69264 | pnpm is a package manager. Versions 10.0.0 through 10.25 allow git-hosted dependencies to execute arbitrary code during pnpm install, circumventing the v10 security feature "Dependency lifecycle scripts execution disabled by default". While pnpm v10 blocks postinstall scripts via the onlyBuiltDependencies mechanism, git dependencies can still execute prepare, prepublish, and prepack scripts during | High 8.8 | 7 Jan 2026 |
| CVE-2024-47829 | pnpm is a package manager. Prior to version 10.0.0, the path shortening function uses the md5 function as a path shortening compression function, and if a collision occurs, it will result in the same storage path for two different libraries. Although the real names are under the package name /node_modoules/, there are no version numbers for the libraries they refer to. This issue has been patched | Medium 6.5 | 23 Apr 2025 |
| CVE-2024-53866 | The package manager pnpm prior to version 9.15.0 seems to mishandle overrides and global cache: Overrides from one workspace leak into npm metadata saved in global cache; npm metadata from global cache affects other workspaces; and installs by default don't revalidate the data (including on first lockfile generation). This can make workspace A (even running with `ignore-scripts=true`) posion globa | Medium 5.8 | 10 Dec 2024 |
| CVE-2023-37478 | pnpm is a package manager. It is possible to construct a tarball that, when installed via npm or parsed by the registry is safe, but when installed via pnpm is malicious, due to how pnpm parses tar archives. This can result in a package that appears safe on the npm registry or when installed via npm being replaced with a compromised or malicious version when installed via pnpm. This issue has been | High 7.5 | 1 Aug 2023 |
| CVE-2022-26183 | PNPM v6.15.1 and below was discovered to contain an untrusted search path which causes the application to behave in unexpected ways when users execute PNPM commands in a directory containing malicious content. This vulnerability occurs when the application is ran on Windows OS. | High 8.8 | 21 Mar 2022 |
Original policy
Copied from sorona.xyz on 12 Nov 2026. The summaries on this page are made from it; the live page may have changed since.
Skip to content What this pays This project runs no bounty of its own. sorona.xyz pays you directly on qualified, reproduced findings. Severity │ sorona.xyz pays Critical │ $1,500+ High │ $700+ Medium │ $300+ Low │ $100 / 1 month Claude Max Submit a vulnerability CVE history 24 Last 12 months 27 Lifetime Integrity bypass 35 % Code execution 30 % Path handling 20 % Info disclosure 15 % Latest advisories Loading the feed Overview pnpm installs Node dependencies for a large share of modern JavaScript monorepos and the pipelines that build them, using a content-addressable store and a linked node_modules in place of copied trees. An install is the first thing that runs on any checkout, with the build's privileges, before a line of the project's own code has been reviewed. A resolution or integrity defect therefore places attacker code on every machine that installs the same lockfile. pnpm's security policy states that it operates no bounty program, and being outside GitHub's ownership it is outside GitHub's bounty too, so sorona.xyz pays you directly on qualified, reproduced findings. In scope The policy accepts vulnerabilities in supported pnpm releases, currently the 10.x and 11.x lines, through the GitHub advisory form. Its threat model is the real boundary: anything presupposing an attacker who can already write to the store, the lockfile, node_modules or the configuration is excluded The registry client: resolution requests, tarball fetching, redirect handling and what a registry response is allowed to change Lockfile handling in full, covering pnpm-lock.yaml parsing, resolution replay and what a lock entry is taken to guarantee Integrity checking on downloaded packages, including the hashes recorded in the lockfile and what happens when one fails to match The content-addressable store, its indexing, and the hard links and symlinks it projects into a project's node_modules Package extraction and file placement, including path handling for entries inside a tarball Lifecycle script execution and the controls that decide which dependencies are permitted to run build scripts Workspace resolution across a monorepo, the workspace: protocol, catalogs and overrides Configuration and credential handling: .npmrc at every level, per-registry auth tokens and any path that could send one to the wrong host pnpm dlx and pnpm exec , plus the patching mechanism behind pnpm patch The CLI's own installation and self-update path, which fetches and then executes the binary that runs every later install Out of scope Anything that starts from attacker write access to the store, the lockfile, node_modules or pnpm's configuration. The threat model rules this out by name pacquet and pnpr , which the policy places outside the advisory process Releases outside the supported 10.x and 11.x lines Malicious packages published to the npm registry, which is registry abuse rather than a pnpm defect The npm registry service and npm's own CLI, both of which are GitHub's and one of which pays Node.js itself, a separate upstream with its own reporting path Most-valued findings Integrity bypass: any path where the tarball installed differs from the content the lockfile hash pinned, or where a mismatch is tolerated. The entire model rests on that check Lifecycle script execution that happens without the dependency having been permitted to run one, or that fires earlier in the install than the controls expect Extraction and link handling that writes outside the intended package directory, since a symlink or traversal escaping node_modules reaches the project source and the runner's own filesystem Registry and redirect handling where one host's response satisfies a package another host was meant to serve, and any credential that follows a redirect off its configured origin Workspace protocol confusion, where a local package satisfies a requirement intended for the registry or the reverse, which is a monorepo-shaped dependency confusion Lockfile parsing defects that change what resolves. The lockfile is the artefact reviewers skim and every CI run replays, so a divergence between how a human reads it and how pnpm reads it is worth more here than a crash Program rules Submit through sorona.xyz. This project runs no bounty of its own; we validate, coordinate disclosure with the maintainers, and pay you directly. Report through the GitHub advisory form at github.com/pnpm/pnpm/security/advisories , the channel SECURITY.md names, with private vulnerability reporting confirmed enabled Read the threat model before you spend time. pnpm declares the content-addressable store is not a security boundary against a local adversary who can already write to it, so anything that assumes attacker write access to the store, the lockfile, node_modules or the config is out of scope The Rust port pacquet and the resolver server pnpr are stated to sit outside the advisory process Supported versions are the 10.x and 11.x lines, with support running to 30 April 2027. A finding against an older line has nowhere to be fixed Include the pnpm-lock.yaml , the registry configuration and the exact command, since resolution behaviour is the subject of most of the real surface here There is no bounty program. The policy says so directly and there are no reward terms to accept Disclosure Coordinated through GitHub private vulnerability reporting on pnpm/pnpm and published as a GitHub Security Advisory alongside a release. The policy documents supported versions and a threat model but sets no response target, so agree the embargo in the advisory thread. Fixes land on the 10.x and 11.x lines; anything older is out of support and will not receive one. Safe harbor Sorona will not pursue legal action against you for good-faith research submitted to us in line with this policy. We cannot speak for the upstream project, its vendor, or any third party, and we do not grant authorization on their behalf. You are responsible for understanding and following the laws that apply to you, wherever you are, and for staying within any scope the project has defined. Submit a vulnerability