<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://vulnerability.circl.lu</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Tue, 29 Sep 2026 20:05:57 +0000</lastBuildDate>
    <item>
      <title>CVE-2026-50015 — pnpm: Arbitrary File Write/Delete via Malicious Patch File (Path Traversal)</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2026-50015</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; pnpm&lt;/p&gt;
&lt;p&gt;pnpm is a package manager. Prior to 10.34.0 and 11.4.0, pnpm&amp;#39;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 --git header paths containing ../../ sequences traverse out of the package directory, and the traversal is difficult to catch in code review because patch file diff headers are opaque to most reviewers. This vulnerability is fixed in 10.34.0 and 11.4.0.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; pnpm&lt;/p&gt;
&lt;p&gt;pnpm is a package manager. Prior to 10.34.0 and 11.4.0, pnpm&amp;#39;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 --git header paths containing ../../ sequences traverse out of the package directory, and the traversal is difficult to catch in code review because patch file diff headers are opaque to most reviewers. This vulnerability is fixed in 10.34.0 and 11.4.0.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2026-50015</guid>
    </item>
    <item>
      <title>GHSA-rxhj-4m44-96r4 — pnpm Vulnerable to Arbitrary File Write/Delete via Malicious Patch File (Path Traversal)</title>
      <link>https://vulnerability.circl.lu/vuln/ghsa-rxhj-4m44-96r4</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; npm: pnpm&lt;/p&gt;
&lt;p&gt;## Summary&lt;/p&gt;
&lt;p&gt;pnpm&amp;#39;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 --git` header paths containing `../../` sequences traverse out of the package directory, and the traversal is difficult to catch in code review because patch file diff headers are opaque to most reviewers.&lt;/p&gt;
&lt;p&gt;## Vulnerability Details&lt;/p&gt;
&lt;p&gt;During `pnpm install`, when a `patchedDependencies` entry is present in `pnpm-workspace.yaml`, pnpm reads the referenced `.patch` file and applies it via the embedded `@pnpm/patch-package` library. The `applyPatchToDir` function at `patching/apply-patch/src/index.ts:12-13` calls `process.chdir(opts.patchedDir)`, setting the working directory to the installed package location deep inside `node_modules/.pnpm/`.&lt;/p&gt;
&lt;p&gt;The patch parser at `@pnpm/patch-package/dist/patch/parse.js:88` extracts file paths from `diff --git a/(.*?) b/(.*?)` headers using a regex with no path sanitization. The `executeEffects` function in `apply.js` then operates on these unsanitized paths:&lt;/p&gt;
&lt;p&gt;**File write** (`apply.js:35-49`):
```javascript
case &amp;#39;file creation&amp;#39;: {
  const eff = effect
  fs.ensureDirSync(dirname(eff.path))
  fs.writeFileSync(eff.path, fileContents, { mode: eff.mode })
  break
}
```&lt;/p&gt;
&lt;p&gt;**File delete** (`apply…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; npm: pnpm&lt;/p&gt;
&lt;p&gt;## Summary&lt;/p&gt;
&lt;p&gt;pnpm&amp;#39;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 --git` header paths containing `../../` sequences traverse out of the package directory, and the traversal is difficult to catch in code review because patch file diff headers are opaque to most reviewers.&lt;/p&gt;
&lt;p&gt;## Vulnerability Details&lt;/p&gt;
&lt;p&gt;During `pnpm install`, when a `patchedDependencies` entry is present in `pnpm-workspace.yaml`, pnpm reads the referenced `.patch` file and applies it via the embedded `@pnpm/patch-package` library. The `applyPatchToDir` function at `patching/apply-patch/src/index.ts:12-13` calls `process.chdir(opts.patchedDir)`, setting the working directory to the installed package location deep inside `node_modules/.pnpm/`.&lt;/p&gt;
&lt;p&gt;The patch parser at `@pnpm/patch-package/dist/patch/parse.js:88` extracts file paths from `diff --git a/(.*?) b/(.*?)` headers using a regex with no path sanitization. The `executeEffects` function in `apply.js` then operates on these unsanitized paths:&lt;/p&gt;
&lt;p&gt;**File write** (`apply.js:35-49`):
```javascript
case &amp;#39;file creation&amp;#39;: {
  const eff = effect
  fs.ensureDirSync(dirname(eff.path))
  fs.writeFileSync(eff.path, fileContents, { mode: eff.mode })
  break
}
```&lt;/p&gt;
&lt;p&gt;**File delete** (`apply…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/ghsa-rxhj-4m44-96r4</guid>
    </item>
  </channel>
</rss>
