Common Weakness Enumeration

CWE-494

Allowed

Download of Code Without Integrity Check

Abstraction: Base · Status: Draft

The product downloads source code or an executable from a remote location and executes the code without sufficiently verifying the origin and integrity of the code.

317 vulnerabilities reference this CWE, most recent first.

GHSA-FW5P-R5CW-5R92

Vulnerability from github – Published: 2022-05-24 17:28 – Updated: 2024-01-01 00:30
VLAI
Details

A remote code execution vulnerability exists in Microsoft SharePoint when the software fails to check the source markup of an application package, aka 'Microsoft SharePoint Remote Code Execution Vulnerability'. This CVE ID is unique from CVE-2020-1200, CVE-2020-1210, CVE-2020-1453, CVE-2020-1576, CVE-2020-1595.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2020-1452"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-494"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-09-11T17:15:00Z",
    "severity": "HIGH"
  },
  "details": "A remote code execution vulnerability exists in Microsoft SharePoint when the software fails to check the source markup of an application package, aka \u0027Microsoft SharePoint Remote Code Execution Vulnerability\u0027. This CVE ID is unique from CVE-2020-1200, CVE-2020-1210, CVE-2020-1453, CVE-2020-1576, CVE-2020-1595.",
  "id": "GHSA-fw5p-r5cw-5r92",
  "modified": "2024-01-01T00:30:41Z",
  "published": "2022-05-24T17:28:03Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-1452"
    },
    {
      "type": "WEB",
      "url": "https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-1452"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-FWGF-W3W5-CHMP

Vulnerability from github – Published: 2025-01-23 03:30 – Updated: 2025-01-23 03:30
VLAI
Details

BigFix Patch Download Plug-ins are affected by an arbitrary file download vulnerability. It could allow a malicious operator to download files from arbitrary URLs without any proper validation or allowlist controls.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-42183"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-494"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-01-23T02:15:35Z",
    "severity": "LOW"
  },
  "details": "BigFix Patch Download Plug-ins are affected by an arbitrary file download vulnerability.  It could allow a malicious operator to download files from arbitrary URLs without any proper validation or allowlist controls.",
  "id": "GHSA-fwgf-w3w5-chmp",
  "modified": "2025-01-23T03:30:54Z",
  "published": "2025-01-23T03:30:54Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42183"
    },
    {
      "type": "WEB",
      "url": "https://support.hcl-software.com/csm?id=kb_article\u0026sysparm_article=KB0118565"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:C/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-FWW7-PQ4G-VXX7

Vulnerability from github – Published: 2023-07-06 19:24 – Updated: 2025-02-06 18:31
VLAI
Details

Electra Central AC unit – Adjacent attacker may cause the unit to load unauthorized FW.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-24500"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-494"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-04-17T22:15:08Z",
    "severity": "MODERATE"
  },
  "details": "Electra Central AC unit \u2013 Adjacent attacker may cause the unit to load unauthorized FW.",
  "id": "GHSA-fww7-pq4g-vxx7",
  "modified": "2025-02-06T18:31:00Z",
  "published": "2023-07-06T19:24:16Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-24500"
    },
    {
      "type": "WEB",
      "url": "https://www.gov.il/en/Departments/faq/cve_advisories"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-G3M7-G22H-M88G

Vulnerability from github – Published: 2022-05-13 01:19 – Updated: 2022-05-13 01:19
VLAI
Details

The Miss Marple Updater Service in COMPAREX Miss Marple Enterprise Edition before 2.0 allows remote attackers to execute arbitrary code with SYSTEM privileges via vectors related to missing update validation.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2018-19234"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-494"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-12-20T17:29:00Z",
    "severity": "HIGH"
  },
  "details": "The Miss Marple Updater Service in COMPAREX Miss Marple Enterprise Edition before 2.0 allows remote attackers to execute arbitrary code with SYSTEM privileges via vectors related to missing update validation.",
  "id": "GHSA-g3m7-g22h-m88g",
  "modified": "2022-05-13T01:19:45Z",
  "published": "2022-05-13T01:19:45Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-19234"
    },
    {
      "type": "WEB",
      "url": "https://seclists.org/bugtraq/2018/Nov/37"
    },
    {
      "type": "WEB",
      "url": "https://www.sec-consult.com/en/blog/advisories/multiple-critical-vulnerabilities-in-miss-marple-enterprise-edition"
    },
    {
      "type": "WEB",
      "url": "http://packetstormsecurity.com/files/150427/Miss-Marple-Enterprise-Edition-File-Upload-Hardcoded-AES-Key.html"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2018/Nov/55"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-G6PQ-X539-7W4J

Vulnerability from github – Published: 2023-10-19 17:04 – Updated: 2023-10-19 19:35
VLAI
Summary
Artifact Hub has Incorrect Docker Hub registry check
Details

Impact

During a security audit of Artifact Hub's code base, a security researcher at OffSec identified a bug in which the registryIsDockerHub function was only checking that the registry domain had the docker.io suffix.

Artifact Hub allows providing some Docker credentials that are used to increase the rate limit applied when interacting with the Docker Hub registry API to read publicly available content. Due to the incorrect check described above, it'd be possible to hijack those credentials by purchasing a domain which ends with docker.io and deploying a fake OCI registry on it.

https://artifacthub.io/ uses some credentials that only have permissions to read public content available in the Docker Hub. However, even though credentials for private repositories (disabled on artifacthub.io) are handled in a different way, other Artifact Hub deployments could have been using them for a different purpose.

Patches

This issue has been resolved in version 1.16.0.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/artifacthub/hub"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.16.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-45821"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-494"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-10-19T17:04:50Z",
    "nvd_published_at": "2023-10-19T21:15:08Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\n\nDuring a security audit of Artifact Hub\u0027s code base, a security researcher at [OffSec](https://www.offsec.com/) identified a bug in which the `registryIsDockerHub` function was only checking that the registry domain had the `docker.io` suffix.\n\nArtifact Hub allows providing some Docker credentials that are used to increase the rate limit applied when interacting with the Docker Hub registry API to read publicly available content. Due to the incorrect check described above, it\u0027d be possible to hijack those credentials by purchasing a domain which ends with `docker.io` and deploying a fake OCI registry on it.\n\n\u003chttps://artifacthub.io/\u003e uses some credentials that only have permissions to read public content available in the Docker Hub. However, even though credentials for private repositories (disabled on `artifacthub.io`) are handled in a different way, other Artifact Hub deployments could have been using them for a different purpose.\n\n### Patches\n\nThis issue has been resolved in version [1.16.0](https://artifacthub.io/packages/helm/artifact-hub/artifact-hub?modal=changelog\u0026version=1.16.0).",
  "id": "GHSA-g6pq-x539-7w4j",
  "modified": "2023-10-19T19:35:35Z",
  "published": "2023-10-19T17:04:50Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/artifacthub/hub/security/advisories/GHSA-g6pq-x539-7w4j"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-45821"
    },
    {
      "type": "WEB",
      "url": "https://artifacthub.io/packages/helm/artifact-hub/artifact-hub?modal=changelog\u0026version=1.16.0"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/artifacthub/hub"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Artifact Hub has Incorrect Docker Hub registry check"
}

GHSA-G8WQ-427W-WGQM

Vulnerability from github – Published: 2022-05-13 01:37 – Updated: 2022-05-13 01:37
VLAI
Details

Siemens LOGO! Soft Comfort (All versions before V8.2) lacks integrity verification of software packages downloaded via an unprotected communication channel. This could allow a remote attacker to manipulate the software package while performing a Man-in-the-Middle (MitM) attack.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2017-12740"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-345",
      "CWE-494"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-12-26T04:29:00Z",
    "severity": "MODERATE"
  },
  "details": "Siemens LOGO! Soft Comfort (All versions before V8.2) lacks integrity verification of software packages downloaded via an unprotected communication channel. This could allow a remote attacker to manipulate the software package while performing a Man-in-the-Middle (MitM) attack.",
  "id": "GHSA-g8wq-427w-wgqm",
  "modified": "2022-05-13T01:37:44Z",
  "published": "2022-05-13T01:37:44Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-12740"
    },
    {
      "type": "WEB",
      "url": "https://www.siemens.com/cert/pool/cert/siemens_security_advisory_ssa-888929.pdf"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-G938-H978-WF7V

Vulnerability from github – Published: 2026-06-26 00:32 – Updated: 2026-06-26 00:32
VLAI
Details

Parse Server before 4.10.0 contains a supply chain vulnerability where incorrect version tags were pushed to the repository linking to unreviewed code in a personal fork. Attackers could exploit this by specifying affected version tags in dependency declarations to execute unreviewed and potentially malicious code.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-47986"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-494"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-25T22:16:58Z",
    "severity": "HIGH"
  },
  "details": "Parse Server before 4.10.0 contains a supply chain vulnerability where incorrect version tags were pushed to the repository linking to unreviewed code in a personal fork. Attackers could exploit this by specifying affected version tags in dependency declarations to execute unreviewed and potentially malicious code.",
  "id": "GHSA-g938-h978-wf7v",
  "modified": "2026-06-26T00:32:04Z",
  "published": "2026-06-26T00:32:04Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/parse-community/parse-server/security/advisories/GHSA-593v-wcqx-hq2w"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47986"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/parse-server-unreviewed-code-execution-via-malicious-version-tags"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:P/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-GC7M-MHR5-PHFH

Vulnerability from github – Published: 2023-12-05 12:30 – Updated: 2023-12-05 12:30
VLAI
Details

Multiple data integrity vulnerabilities exist in the package hash checking functionality of Buildroot 2023.08.1 and Buildroot dev commit 622698d7847. A specially crafted man-in-the-middle attack can lead to arbitrary command execution in the builder.This vulnerability is related to the mxsldr package.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-45842"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-494"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-12-05T12:15:43Z",
    "severity": "HIGH"
  },
  "details": "Multiple data integrity vulnerabilities exist in the package hash checking functionality of Buildroot 2023.08.1 and Buildroot dev commit 622698d7847. A specially crafted man-in-the-middle attack can lead to arbitrary command execution in the builder.This vulnerability is related to the `mxsldr` package.",
  "id": "GHSA-gc7m-mhr5-phfh",
  "modified": "2023-12-05T12:30:45Z",
  "published": "2023-12-05T12:30:45Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-45842"
    },
    {
      "type": "WEB",
      "url": "https://talosintelligence.com/vulnerability_reports/TALOS-2023-1844"
    },
    {
      "type": "WEB",
      "url": "https://www.talosintelligence.com/vulnerability_reports/TALOS-2023-1844"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2023/12/11/1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-GF32-CMJH-8M9V

Vulnerability from github – Published: 2026-08-22 15:31 – Updated: 2026-08-22 15:31
VLAI
Details

NLTK before 3.9.3 fails to verify file integrity after downloading packages and before extraction in the downloader module. Attackers can perform man-in-the-middle attacks or DNS poisoning to inject malicious package contents that are extracted without validation.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-63310"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-494"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-22T15:16:19Z",
    "severity": "CRITICAL"
  },
  "details": "NLTK before 3.9.3 fails to verify file integrity after downloading packages and before extraction in the downloader module. Attackers can perform man-in-the-middle attacks or DNS poisoning to inject malicious package contents that are extracted without validation.",
  "id": "GHSA-gf32-cmjh-8m9v",
  "modified": "2026-08-22T15:31:03Z",
  "published": "2026-08-22T15:31:03Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/nltk/nltk/security/advisories/GHSA-5wp5-5229-5g6q"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-63310"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/nltk-before-missing-post-download-integrity-verification"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-GJ8W-MVPF-X27X

Vulnerability from github – Published: 2026-06-26 23:20 – Updated: 2026-08-13 16:06
VLAI
Summary
pnpm: Repository-controlled configDependencies can select a pacquet native install engine
Details

Maintainer Action Plan

This report is ready to review with the shared patch branch. Start with the PR and the expected fixed behavior, then use the detailed exploit narrative below only if you want to replay the original path.

  • Advisory: CAND-PNPM-097 / GHSA-gj8w-mvpf-x27x
  • Advisory URL: https://github.com/pnpm/pnpm/security/advisories/GHSA-gj8w-mvpf-x27x
  • Shared patch PR: https://github.com/pnpm/pnpm-ghsa-j2hc-m6cf-6jm8/pull/1
  • Shared patch branch: security/ghsa-batch-2026-06-09
  • Patch commit: a93449314f398cf4bdf2e28d033c02d37395ad22
  • Base commit: origin/main 55a4035abf1ae3fe7208ba1f5ef43c5eff58ccec
  • Maintainer priority: start-here
  • Component: pnpm configDependencies / pacquet delegation
  • Patch area: pacquet/configDependency lifecycle execution is not used as install engine without trust
  • Affected packages: npm:pnpm, npm:@pnpm/config.reader, npm:@pnpm/installing.commands
  • CWE IDs: CWE-829, CWE-78, CWE-494
  • Conservative CVSS: 7.5 / CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H
  • Next action: review the shared patch branch for this component, set the final affected version range, merge and release the fix, then publish or close the advisory.

Expected Patched Behavior

config-dependency pacquet install engines are not selected unless the trusted allowlist is set outside the repository; the marker file is not created.

Files And Tests To Review

  • config/reader/src/Config.ts
  • config/reader/src/types.ts
  • config/reader/src/configFileKey.ts
  • config/reader/src/index.ts
  • config/reader/test/index.ts
  • installing/commands/src/installDeps.ts
  • installing/commands/test/runPacquet.ts
  • pnpm/test/install/pacquet.ts
  • .changeset/lucky-config-plugin-pnpmfiles.md

Focused Validation

Run these from a checkout of the shared patch branch. They are the useful maintainer commands with machine-local artifact paths removed.

./node_modules/.bin/tsgo --build config/reader/tsconfig.json
./node_modules/.bin/tsgo --build installing/commands/tsconfig.json
./node_modules/.bin/tsgo --build pnpm/tsconfig.json
NODE_OPTIONS="--experimental-vm-modules --disable-warning=ExperimentalWarning --disable-warning=DEP0169" ../../node_modules/.bin/jest test/runPacquet.ts --runInBand
NODE_OPTIONS="--experimental-vm-modules --disable-warning=ExperimentalWarning --disable-warning=DEP0169" ../../node_modules/.bin/jest test/index.ts -t "config dependency code allowlists|user-level preference settings" --runInBand
./node_modules/.bin/eslint config/reader/src/Config.ts config/reader/src/types.ts config/reader/src/configFileKey.ts config/reader/src/index.ts config/reader/test/index.ts installing/commands/src/installDeps.ts installing/commands/test/runPacquet.ts pnpm/test/install/pacquet.ts
git diff --check

The full patched replay for the shared branch passed with all 20 candidates marked fixed. This candidate's replay evidence is results/CAND-PNPM-097-patched-result.json.

Summary

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>-<arch>/pacquet binary from node_modules/.pnpm-config/<packageName> and spawned it as the developer or CI user.

Details

The vulnerable source-to-sink path was:

  • config/reader/src/getOptionsFromRootManifest.ts copies repository pnpm-workspace.yaml configDependencies into config.
  • pnpm/src/getConfig.ts installs config dependencies before command dispatch.
  • installing/env-installer/src/resolveAndInstallConfigDeps.ts resolves the repository-declared dependency and its optional platform subdependencies.
  • installing/env-installer/src/installConfigDeps.ts fetches, imports, and symlinks the config dependency tree under node_modules/.pnpm-config.
  • installing/commands/src/installDeps.ts selected pacquet delegation whenever configDependencies contained pacquet or @pnpm/pacquet.
  • installing/deps-installer/src/install/index.ts called opts.runPacquet from frozen and materialization paths.
  • installing/commands/src/runPacquet.ts resolved @pacquet/${process.platform}-${process.arch}/pacquet from the installed config dependency package and executed it with spawn().

Exact-version, integrity, and platform filters only proved which bytes package resolution selected; they did not establish that the repository was trusted to choose a native install engine.

PoC

Standalone PoC and verification script:

Repository fixture:

packages:
  - .
configDependencies:
  pacquet: 0.2.2

Registry package shape:

{
  "name": "pacquet",
  "version": "0.2.2",
  "optionalDependencies": {
    "@pacquet/darwin-arm64": "0.2.2"
  }
}

Platform package payload:

#!/bin/sh
echo "$PWD" > /tmp/pacquet-engine-ran
env > /tmp/pacquet-engine-env

Pre-patch exploit model:

  1. The victim runs a dependency-management command such as pnpm install in the repository.
  2. pnpm installs the repository-declared config dependency and its host-compatible optional platform dependency into .pnpm-config.
  3. installDeps() treats the presence of configDependencies.pacquet or configDependencies["@pnpm/pacquet"] as authorization to delegate install materialization.
  4. runPacquet() resolves the platform binary from the installed config dependency tree and spawns it in the lockfile directory.

Observed PoC output:

{
  "primitive": "repository-selected pacquet config dependency reaches native process execution when selected",
  "patchedWithoutAllowlist": "blocked",
  "trustedAllowlist": "allows explicit opt-in"
}

Focused validation commands:

./node_modules/.bin/tsgo --build config/reader/tsconfig.json
./node_modules/.bin/tsgo --build installing/commands/tsconfig.json
./node_modules/.bin/tsgo --build pnpm/tsconfig.json
NODE_OPTIONS="--experimental-vm-modules --disable-warning=ExperimentalWarning --disable-warning=DEP0169" ../../node_modules/.bin/jest test/runPacquet.ts --runInBand
NODE_OPTIONS="--experimental-vm-modules --disable-warning=ExperimentalWarning --disable-warning=DEP0169" ../../node_modules/.bin/jest test/index.ts -t "config dependency code allowlists|user-level preference settings" --runInBand
./node_modules/.bin/eslint config/reader/src/Config.ts config/reader/src/types.ts config/reader/src/configFileKey.ts config/reader/src/index.ts config/reader/test/index.ts installing/commands/src/installDeps.ts installing/commands/test/runPacquet.ts pnpm/test/install/pacquet.ts
git diff --check

Validation result:

  • The PoC confirmed a selected pacquet config dependency reaches native process execution.
  • Patched getPacquetConfigDependencyName() returns undefined without a trusted allowlist.
  • Patched getPacquetConfigDependencyName() allows exact pacquet, exact @pnpm/pacquet, and wildcard * trusted opt-in.
  • Config reader regressions prove user/global config can set configDependencyInstallEngineAllowlist, while pnpm-workspace.yaml cannot grant this permission to itself.
  • E2E fixtures that intentionally delegate to pacquet now pass the trusted allowlist through environment config.
  • TypeScript builds passed for @pnpm/config.reader, @pnpm/installing.commands, and pnpm.
  • Focused installing/commands/test/runPacquet.ts: 3 passed.
  • Focused config/reader/test/index.ts: 2 passed, 132 skipped under the focused pattern.
  • ESLint passed with warnings only for existing skipped tests in config/reader/test/index.ts and pnpm/test/install/pacquet.ts.
  • git diff --check: passed.

Impact

A malicious repository can cause pnpm to execute a registry-selected native binary while handling dependency-management commands. The binary runs with the victim developer or CI user's filesystem, environment, registry credentials, git/SSH credentials, and network access.

Affected products

Ecosystem: npm

Package name: pnpm, @pnpm/config.reader, @pnpm/installing.commands

Affected versions: current main before this patch, when configDependencies contains pacquet or @pnpm/pacquet and install paths delegate to pacquet.

Patched versions: 10.34.2, 11.5.3.

Severity

Severity: High

Vector string: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

Base score: 8.8

Rationale: attacker input is delivered through a repository and registry package, exploitation is low complexity once the victim runs pnpm, no attacker privileges are required, and user interaction is required. Successful exploitation executes a native binary in the victim user's context, with high confidentiality, integrity, and availability impact.

Weaknesses

CWE-829: Inclusion of Functionality from Untrusted Control Sphere

CWE-78: Improper Neutralization of Special Elements used in an OS Command

CWE-494: Download of Code Without Integrity Check

Patch

The patch adds a trusted opt-in gate for config-dependency install-engine delegation:

  • New setting: configDependencyInstallEngineAllowlist.
  • The allowlist can be set from trusted user-controlled config such as global config, CLI config, or environment config.
  • pnpm-workspace.yaml cannot grant this permission to itself; workspace-provided values are discarded after workspace settings are merged.
  • installDeps() delegates to pacquet only when pacquet, @pnpm/pacquet, or * is present in the trusted allowlist.
  • Repositories can still install pacquet as a config dependency, but pnpm will not spawn it as an install engine unless trusted config opts in.
  • Existing tests that intentionally exercise pacquet delegation were updated to pass the trusted allowlist via environment config.

Changed files:

  • config/reader/src/Config.ts
  • config/reader/src/types.ts
  • config/reader/src/configFileKey.ts
  • config/reader/src/index.ts
  • config/reader/test/index.ts
  • installing/commands/src/installDeps.ts
  • installing/commands/test/runPacquet.ts
  • pnpm/test/install/pacquet.ts

Changeset:

  • .changeset/lucky-config-plugin-pnpmfiles.md

Pacquet parity:

No pacquet-side code-execution sink exists for this finding. The Rust port parses and records configDependencies for workspace-state compatibility, but it does not install config dependencies or select/spawn an alternate install engine from them. The user-visible trust setting is TypeScript-side today because it gates pnpm's pacquet delegation path.

CVSS Reassessment

Initial CVSS remains correct for vulnerable versions: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H / 8.8 High.

Final CVSS after patch: not vulnerable after patch / 0.0. The PoC no longer reaches pacquet install-engine selection or native process execution unless the victim has set a trusted allowlist outside the repository's own workspace settings.

Remaining Risk

Users can explicitly trust pacquet install-engine delegation through the new allowlist. That is intentional behavior; the closed issue is repository self-authorization of a registry-provided native install engine.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "pnpm"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "10.34.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "pnpm"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "11.0.0"
            },
            {
              "fixed": "11.5.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-55697"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-494",
      "CWE-78",
      "CWE-829"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-26T23:20:47Z",
    "nvd_published_at": "2026-06-25T18:16:40Z",
    "severity": "HIGH"
  },
  "details": "\u003c!-- maintainer-action:start --\u003e\n## Maintainer Action Plan\n\nThis report is ready to review with the shared patch branch. Start with the PR and the expected fixed behavior, then use the detailed exploit narrative below only if you want to replay the original path.\n\n- Advisory: `CAND-PNPM-097` / `GHSA-gj8w-mvpf-x27x`\n- Advisory URL: https://github.com/pnpm/pnpm/security/advisories/GHSA-gj8w-mvpf-x27x\n- Shared patch PR: https://github.com/pnpm/pnpm-ghsa-j2hc-m6cf-6jm8/pull/1\n- Shared patch branch: `security/ghsa-batch-2026-06-09`\n- Patch commit: `a93449314f398cf4bdf2e28d033c02d37395ad22`\n- Base commit: `origin/main` `55a4035abf1ae3fe7208ba1f5ef43c5eff58ccec`\n- Maintainer priority: `start-here`\n- Component: `pnpm configDependencies / pacquet delegation`\n- Patch area: pacquet/configDependency lifecycle execution is not used as install engine without trust\n- Affected packages: `npm:pnpm`, `npm:@pnpm/config.reader`, `npm:@pnpm/installing.commands`\n- CWE IDs: `CWE-829`, `CWE-78`, `CWE-494`\n- Conservative CVSS: `7.5` / `CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H`\n- Next action: review the shared patch branch for this component, set the final affected version range, merge and release the fix, then publish or close the advisory.\n\n### Expected Patched Behavior\n\nconfig-dependency pacquet install engines are not selected unless the trusted allowlist is set outside the repository; the marker file is not created.\n\n### Files And Tests To Review\n\n- `config/reader/src/Config.ts`\n- `config/reader/src/types.ts`\n- `config/reader/src/configFileKey.ts`\n- `config/reader/src/index.ts`\n- `config/reader/test/index.ts`\n- `installing/commands/src/installDeps.ts`\n- `installing/commands/test/runPacquet.ts`\n- `pnpm/test/install/pacquet.ts`\n- `.changeset/lucky-config-plugin-pnpmfiles.md`\n\n### Focused Validation\n\nRun these from a checkout of the shared patch branch. They are the useful maintainer commands with machine-local artifact paths removed.\n\n```bash\n./node_modules/.bin/tsgo --build config/reader/tsconfig.json\n./node_modules/.bin/tsgo --build installing/commands/tsconfig.json\n./node_modules/.bin/tsgo --build pnpm/tsconfig.json\nNODE_OPTIONS=\"--experimental-vm-modules --disable-warning=ExperimentalWarning --disable-warning=DEP0169\" ../../node_modules/.bin/jest test/runPacquet.ts --runInBand\nNODE_OPTIONS=\"--experimental-vm-modules --disable-warning=ExperimentalWarning --disable-warning=DEP0169\" ../../node_modules/.bin/jest test/index.ts -t \"config dependency code allowlists|user-level preference settings\" --runInBand\n./node_modules/.bin/eslint config/reader/src/Config.ts config/reader/src/types.ts config/reader/src/configFileKey.ts config/reader/src/index.ts config/reader/test/index.ts installing/commands/src/installDeps.ts installing/commands/test/runPacquet.ts pnpm/test/install/pacquet.ts\ngit diff --check\n```\n\nThe full patched replay for the shared branch passed with all 20 candidates marked fixed. This candidate\u0027s replay evidence is `results/CAND-PNPM-097-patched-result.json`.\n\u003c!-- maintainer-action:end --\u003e\n\n### Summary\n\npnpm 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/\u003cplatform\u003e-\u003carch\u003e/pacquet` binary from `node_modules/.pnpm-config/\u003cpackageName\u003e` and spawned it as the developer or CI user.\n\n### Details\n\nThe vulnerable source-to-sink path was:\n\n- `config/reader/src/getOptionsFromRootManifest.ts` copies repository `pnpm-workspace.yaml` `configDependencies` into config.\n- `pnpm/src/getConfig.ts` installs config dependencies before command dispatch.\n- `installing/env-installer/src/resolveAndInstallConfigDeps.ts` resolves the repository-declared dependency and its optional platform subdependencies.\n- `installing/env-installer/src/installConfigDeps.ts` fetches, imports, and symlinks the config dependency tree under `node_modules/.pnpm-config`.\n- `installing/commands/src/installDeps.ts` selected pacquet delegation whenever `configDependencies` contained `pacquet` or `@pnpm/pacquet`.\n- `installing/deps-installer/src/install/index.ts` called `opts.runPacquet` from frozen and materialization paths.\n- `installing/commands/src/runPacquet.ts` resolved `@pacquet/${process.platform}-${process.arch}/pacquet` from the installed config dependency package and executed it with `spawn()`.\n\nExact-version, integrity, and platform filters only proved which bytes package resolution selected; they did not establish that the repository was trusted to choose a native install engine.\n\n### PoC\n\nStandalone PoC and verification script:\n\nRepository fixture:\n\n```yaml\npackages:\n  - .\nconfigDependencies:\n  pacquet: 0.2.2\n```\n\nRegistry package shape:\n\n```json\n{\n  \"name\": \"pacquet\",\n  \"version\": \"0.2.2\",\n  \"optionalDependencies\": {\n    \"@pacquet/darwin-arm64\": \"0.2.2\"\n  }\n}\n```\n\nPlatform package payload:\n\n```sh\n#!/bin/sh\necho \"$PWD\" \u003e /tmp/pacquet-engine-ran\nenv \u003e /tmp/pacquet-engine-env\n```\n\nPre-patch exploit model:\n\n1. The victim runs a dependency-management command such as `pnpm install` in the repository.\n2. pnpm installs the repository-declared config dependency and its host-compatible optional platform dependency into `.pnpm-config`.\n3. `installDeps()` treats the presence of `configDependencies.pacquet` or `configDependencies[\"@pnpm/pacquet\"]` as authorization to delegate install materialization.\n4. `runPacquet()` resolves the platform binary from the installed config dependency tree and spawns it in the lockfile directory.\n\nObserved PoC output:\n\n```json\n{\n  \"primitive\": \"repository-selected pacquet config dependency reaches native process execution when selected\",\n  \"patchedWithoutAllowlist\": \"blocked\",\n  \"trustedAllowlist\": \"allows explicit opt-in\"\n}\n```\n\nFocused validation commands:\n\n```bash\n./node_modules/.bin/tsgo --build config/reader/tsconfig.json\n./node_modules/.bin/tsgo --build installing/commands/tsconfig.json\n./node_modules/.bin/tsgo --build pnpm/tsconfig.json\nNODE_OPTIONS=\"--experimental-vm-modules --disable-warning=ExperimentalWarning --disable-warning=DEP0169\" ../../node_modules/.bin/jest test/runPacquet.ts --runInBand\nNODE_OPTIONS=\"--experimental-vm-modules --disable-warning=ExperimentalWarning --disable-warning=DEP0169\" ../../node_modules/.bin/jest test/index.ts -t \"config dependency code allowlists|user-level preference settings\" --runInBand\n./node_modules/.bin/eslint config/reader/src/Config.ts config/reader/src/types.ts config/reader/src/configFileKey.ts config/reader/src/index.ts config/reader/test/index.ts installing/commands/src/installDeps.ts installing/commands/test/runPacquet.ts pnpm/test/install/pacquet.ts\ngit diff --check\n```\n\nValidation result:\n\n- The PoC confirmed a selected pacquet config dependency reaches native process execution.\n- Patched `getPacquetConfigDependencyName()` returns `undefined` without a trusted allowlist.\n- Patched `getPacquetConfigDependencyName()` allows exact `pacquet`, exact `@pnpm/pacquet`, and wildcard `*` trusted opt-in.\n- Config reader regressions prove user/global config can set `configDependencyInstallEngineAllowlist`, while `pnpm-workspace.yaml` cannot grant this permission to itself.\n- E2E fixtures that intentionally delegate to pacquet now pass the trusted allowlist through environment config.\n- TypeScript builds passed for `@pnpm/config.reader`, `@pnpm/installing.commands`, and `pnpm`.\n- Focused `installing/commands/test/runPacquet.ts`: 3 passed.\n- Focused `config/reader/test/index.ts`: 2 passed, 132 skipped under the focused pattern.\n- ESLint passed with warnings only for existing skipped tests in `config/reader/test/index.ts` and `pnpm/test/install/pacquet.ts`.\n- `git diff --check`: passed.\n\n### Impact\n\nA malicious repository can cause pnpm to execute a registry-selected native binary while handling dependency-management commands. The binary runs with the victim developer or CI user\u0027s filesystem, environment, registry credentials, git/SSH credentials, and network access.\n\n## Affected products\n\nEcosystem: npm\n\nPackage name: `pnpm`, `@pnpm/config.reader`, `@pnpm/installing.commands`\n\nAffected versions: current main before this patch, when `configDependencies` contains `pacquet` or `@pnpm/pacquet` and install paths delegate to pacquet.\n\nPatched versions: 10.34.2, 11.5.3.\n\n## Severity\n\nSeverity: High\n\nVector string: `CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H`\n\nBase score: 8.8\n\nRationale: attacker input is delivered through a repository and registry package, exploitation is low complexity once the victim runs pnpm, no attacker privileges are required, and user interaction is required. Successful exploitation executes a native binary in the victim user\u0027s context, with high confidentiality, integrity, and availability impact.\n\n## Weaknesses\n\nCWE-829: Inclusion of Functionality from Untrusted Control Sphere\n\nCWE-78: Improper Neutralization of Special Elements used in an OS Command\n\nCWE-494: Download of Code Without Integrity Check\n\n## Patch\n\nThe patch adds a trusted opt-in gate for config-dependency install-engine delegation:\n\n- New setting: `configDependencyInstallEngineAllowlist`.\n- The allowlist can be set from trusted user-controlled config such as global config, CLI config, or environment config.\n- `pnpm-workspace.yaml` cannot grant this permission to itself; workspace-provided values are discarded after workspace settings are merged.\n- `installDeps()` delegates to pacquet only when `pacquet`, `@pnpm/pacquet`, or `*` is present in the trusted allowlist.\n- Repositories can still install `pacquet` as a config dependency, but pnpm will not spawn it as an install engine unless trusted config opts in.\n- Existing tests that intentionally exercise pacquet delegation were updated to pass the trusted allowlist via environment config.\n\nChanged files:\n\n- `config/reader/src/Config.ts`\n- `config/reader/src/types.ts`\n- `config/reader/src/configFileKey.ts`\n- `config/reader/src/index.ts`\n- `config/reader/test/index.ts`\n- `installing/commands/src/installDeps.ts`\n- `installing/commands/test/runPacquet.ts`\n- `pnpm/test/install/pacquet.ts`\n\nChangeset:\n\n- `.changeset/lucky-config-plugin-pnpmfiles.md`\n\nPacquet parity:\n\nNo pacquet-side code-execution sink exists for this finding. The Rust port parses and records `configDependencies` for workspace-state compatibility, but it does not install config dependencies or select/spawn an alternate install engine from them. The user-visible trust setting is TypeScript-side today because it gates pnpm\u0027s pacquet delegation path.\n\n## CVSS Reassessment\n\nInitial CVSS remains correct for vulnerable versions: `CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H` / 8.8 High.\n\nFinal CVSS after patch: not vulnerable after patch / 0.0. The PoC no longer reaches pacquet install-engine selection or native process execution unless the victim has set a trusted allowlist outside the repository\u0027s own workspace settings.\n\n## Remaining Risk\n\nUsers can explicitly trust pacquet install-engine delegation through the new allowlist. That is intentional behavior; the closed issue is repository self-authorization of a registry-provided native install engine.",
  "id": "GHSA-gj8w-mvpf-x27x",
  "modified": "2026-08-13T16:06:30Z",
  "published": "2026-06-26T23:20:47Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/pnpm/pnpm/security/advisories/GHSA-gj8w-mvpf-x27x"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-55697"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/pnpm/pnpm"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "pnpm: Repository-controlled configDependencies can select a pacquet native install engine"
}

Mitigation MIT-42
Implementation

Perform proper forward and reverse DNS lookups to detect DNS spoofing.

Mitigation
Architecture and Design Operation
  • Encrypt the code with a reliable encryption scheme before transmitting.
  • This will only be a partial solution, since it will not detect DNS spoofing and it will not prevent your code from being modified on the hosting site.
Mitigation MIT-4
Architecture and Design

Strategy: Libraries or Frameworks

  • Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid [REF-1482].
  • Speficially, it may be helpful to use tools or frameworks to perform integrity checking on the transmitted code.
  • When providing the code that is to be downloaded, such as for automatic updates of the software, then use cryptographic signatures for the code and modify the download clients to verify the signatures. Ensure that the implementation does not contain CWE-295, CWE-320, CWE-347, and related weaknesses.
  • Use code signing technologies such as Authenticode. See references [REF-454] [REF-455] [REF-456].
Mitigation MIT-17
Architecture and Design Operation

Strategy: Environment Hardening

Run your code using the lowest privileges that are required to accomplish the necessary tasks [REF-76]. If possible, create isolated accounts with limited privileges that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations.

Mitigation MIT-22
Architecture and Design Operation

Strategy: Sandbox or Jail

  • Run the code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which files can be accessed in a particular directory or which commands can be executed by the software.
  • OS-level examples include the Unix chroot jail, AppArmor, and SELinux. In general, managed code may provide some protection. For example, java.io.FilePermission in the Java SecurityManager allows the software to specify restrictions on file operations.
  • This may not be a feasible solution, and it only limits the impact to the operating system; the rest of the application may still be subject to compromise.
  • Be careful to avoid CWE-243 and other weaknesses related to jails.
CAPEC-184: Software Integrity Attack

An attacker initiates a series of events designed to cause a user, program, server, or device to perform actions which undermine the integrity of software code, device data structures, or device firmware, achieving the modification of the target's integrity to achieve an insecure state.

CAPEC-185: Malicious Software Download

An attacker uses deceptive methods to cause a user or an automated process to download and install dangerous code that originates from an attacker controlled source. There are several variations to this strategy of attack.

CAPEC-186: Malicious Software Update

An adversary uses deceptive methods to cause a user or an automated process to download and install dangerous code believed to be a valid update that originates from an adversary controlled source.

CAPEC-187: Malicious Automated Software Update via Redirection

An attacker exploits two layers of weaknesses in server or client software for automated update mechanisms to undermine the integrity of the target code-base. The first weakness involves a failure to properly authenticate a server as a source of update or patch content. This type of weakness typically results from authentication mechanisms which can be defeated, allowing a hostile server to satisfy the criteria that establish a trust relationship. The second weakness is a systemic failure to validate the identity and integrity of code downloaded from a remote location, hence the inability to distinguish malicious code from a legitimate update.

CAPEC-533: Malicious Manual Software Update

An attacker introduces malicious code to the victim's system by altering the payload of a software update, allowing for additional compromise or site disruption at the victim location. These manual, or user-assisted attacks, vary from requiring the user to download and run an executable, to as streamlined as tricking the user to click a URL. Attacks which aim at penetrating a specific network infrastructure often rely upon secondary attack methods to achieve the desired impact. Spamming, for example, is a common method employed as an secondary attack vector. Thus the attacker has in their arsenal a choice of initial attack vectors ranging from traditional SMTP/POP/IMAP spamming and its varieties, to web-application mechanisms which commonly implement both chat and rich HTML messaging within the user interface.

CAPEC-538: Open-Source Library Manipulation

Adversaries implant malicious code in open source software (OSS) libraries to have it widely distributed, as OSS is commonly downloaded by developers and other users to incorporate into software development projects. The adversary can have a particular system in mind to target, or the implantation can be the first stage of follow-on attacks on many systems.

CAPEC-657: Malicious Automated Software Update via Spoofing

An attackers uses identify or content spoofing to trick a client into performing an automated software update from a malicious source. A malicious automated software update that leverages spoofing can include content or identity spoofing as well as protocol spoofing. Content or identity spoofing attacks can trigger updates in software by embedding scripted mechanisms within a malicious web page, which masquerades as a legitimate update source. Scripting mechanisms communicate with software components and trigger updates from locations specified by the attackers' server. The result is the client believing there is a legitimate software update available but instead downloading a malicious update from the attacker.

CAPEC-662: Adversary in the Browser (AiTB)

An adversary exploits security vulnerabilities or inherent functionalities of a web browser, in order to manipulate traffic between two endpoints.

CAPEC-691: Spoof Open-Source Software Metadata

An adversary spoofs open-source software metadata in an attempt to masquerade malicious software as popular, maintained, and trusted.

CAPEC-692: Spoof Version Control System Commit Metadata

An adversary spoofs metadata pertaining to a Version Control System (VCS) (e.g., Git) repository's commits to deceive users into believing that the maliciously provided software is frequently maintained and originates from a trusted source.

CAPEC-693: StarJacking

An adversary spoofs software popularity metadata to deceive users into believing that a maliciously provided package is widely used and originates from a trusted source.

CAPEC-695: Repo Jacking

An adversary takes advantage of the redirect property of directly linked Version Control System (VCS) repositories to trick users into incorporating malicious code into their applications.