Common Weakness Enumeration

CWE-829

Allowed

Inclusion of Functionality from Untrusted Control Sphere

Abstraction: Base · Status: Incomplete

The product imports, requires, or includes executable functionality (such as a library) from a source that is outside of the intended control sphere.

393 vulnerabilities reference this CWE, most recent first.

GHSA-G3FX-WRQ8-CP3Q

Vulnerability from github – Published: 2022-07-13 00:01 – Updated: 2022-07-17 00:00
VLAI
Details

Improper access control vulnerability in KnoxCustomManagerService prior to SMR Jul-2022 Release 1 allows attacker to call PowerManaer.goToSleep method which is protected by system permission by sending braodcast intent.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-33701"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-284",
      "CWE-829"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-07-12T14:15:00Z",
    "severity": "LOW"
  },
  "details": "Improper access control vulnerability in KnoxCustomManagerService prior to SMR Jul-2022 Release 1 allows attacker to call PowerManaer.goToSleep method which is protected by system permission by sending braodcast intent.",
  "id": "GHSA-g3fx-wrq8-cp3q",
  "modified": "2022-07-17T00:00:45Z",
  "published": "2022-07-13T00:01:54Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-33701"
    },
    {
      "type": "WEB",
      "url": "https://security.samsungmobile.com/securityUpdate.smsb?year=2022\u0026month=7"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-G6V3-V698-J2CR

Vulnerability from github – Published: 2021-12-08 00:01 – Updated: 2022-03-31 00:01
VLAI
Details

A remote file inclusion vulnerability in the ArcGIS Server help documentation may allow a remote, unauthenticated attacker to inject attacker supplied html into a page.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-29113"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-829",
      "CWE-94"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-12-07T11:15:00Z",
    "severity": "MODERATE"
  },
  "details": "A remote file inclusion vulnerability in the ArcGIS Server help documentation may allow a remote, unauthenticated attacker to inject attacker supplied html into a page.",
  "id": "GHSA-g6v3-v698-j2cr",
  "modified": "2022-03-31T00:01:04Z",
  "published": "2021-12-08T00:01:41Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-29113"
    },
    {
      "type": "WEB",
      "url": "https://www.esri.com/arcgis-blog/products/arcgis-enterprise/administration/arcgis-server-security-2021-update-2-patch-is-now-available"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-G9JW-92Q7-G7FJ

Vulnerability from github – Published: 2026-06-18 18:35 – Updated: 2026-06-19 19:20
VLAI
Summary
[Eclipse Theia] Arbitrary Command Execution via Untrusted Workspace Task Definitions
Details

In Eclipse Theia versions prior to 1.69.0, custom task definitions in workspace files (e.g. .theia/tasks.json, .vscode/tasks.json) could be executed without requiring workspace trust. An attacker could craft a malicious repository that, when cloned and opened in Theia, leads to execution of arbitrary commands with the user's privileges. In combination with AI chat features and a workspace .theia/settings.json that disabled tool confirmation, this could be triggered automatically by sending a message in the AI chat.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@theia/debug"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.69.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@theia/task"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.69.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@theia/workspace"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.69.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-44691"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-829"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-19T19:20:20Z",
    "nvd_published_at": "2026-06-18T16:16:54Z",
    "severity": "HIGH"
  },
  "details": "In Eclipse Theia versions prior to 1.69.0, custom task definitions in workspace files (e.g. .theia/tasks.json, .vscode/tasks.json) could be executed without requiring workspace trust. An attacker could craft a malicious repository that, when cloned and opened in Theia, leads to execution of arbitrary commands with the user\u0027s privileges. In combination with AI chat features and a workspace .theia/settings.json that disabled tool confirmation, this could be triggered automatically by sending a message in the AI chat.",
  "id": "GHSA-g9jw-92q7-g7fj",
  "modified": "2026-06-19T19:20:20Z",
  "published": "2026-06-18T18:35:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44691"
    },
    {
      "type": "WEB",
      "url": "https://github.com/eclipse-theia/theia/issues/16889"
    },
    {
      "type": "WEB",
      "url": "https://github.com/eclipse-theia/theia/pull/16917"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/eclipse-theia/theia"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.eclipse.org/security/cve-assignment/-/work_items/116"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.eclipse.org/security/vulnerability-reports/-/work_items/331"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:A/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "[Eclipse Theia] Arbitrary Command Execution via Untrusted Workspace Task Definitions"
}

GHSA-GGPC-F69F-XP45

Vulnerability from github – Published: 2023-08-31 18:30 – Updated: 2024-04-04 07:20
VLAI
Details

An Inclusion of Functionality from Untrusted Control Sphere vulnerability in the Schweitzer Engineering Laboratories SEL-5030 acSELerator QuickSet Software could allow an attacker to embed instructions that could be executed by an authorized device operator.

See Instruction Manual Appendix A and Appendix E dated 20230615 for more details.

This issue affects SEL-5030 acSELerator QuickSet Software: through 7.1.3.0.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-31168"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-829"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-08-31T16:15:08Z",
    "severity": "MODERATE"
  },
  "details": "\nAn Inclusion of Functionality from Untrusted Control Sphere vulnerability in the Schweitzer Engineering Laboratories SEL-5030 acSELerator QuickSet Software could allow an attacker to embed instructions that could be executed by an authorized device operator.\n\n\n\nSee Instruction Manual Appendix A and Appendix E dated 20230615 for more details.\n\n\n\n\n\n\nThis issue affects SEL-5030 acSELerator QuickSet Software: through 7.1.3.0.\n\n",
  "id": "GHSA-ggpc-f69f-xp45",
  "modified": "2024-04-04T07:20:41Z",
  "published": "2023-08-31T18:30:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-31168"
    },
    {
      "type": "WEB",
      "url": "https://selinc.com/support/security-notifications/external-reports"
    },
    {
      "type": "WEB",
      "url": "https://www.nozominetworks.com/blog"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:R/S:C/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-GJ8W-MVPF-X27X

Vulnerability from github – Published: 2026-06-26 23:20 – Updated: 2026-06-26 23:20
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": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c 10.34.2"
      },
      "package": {
        "ecosystem": "npm",
        "name": "pnpm"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "11.5.3"
            }
          ],
          "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-06-26T23:20:47Z",
  "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"
}

GHSA-GM29-HCQ8-QWP5

Vulnerability from github – Published: 2025-07-25 18:30 – Updated: 2025-07-25 18:30
VLAI
Details

Inclusion of Functionality from Untrusted Control Sphere vulnerability in Simplehelp.This issue affects Simplehelp: before 5.5.12.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-36727"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-829"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-07-25T17:15:31Z",
    "severity": "HIGH"
  },
  "details": "Inclusion of Functionality from Untrusted Control Sphere vulnerability in Simplehelp.This issue affects Simplehelp: before 5.5.12.",
  "id": "GHSA-gm29-hcq8-qwp5",
  "modified": "2025-07-25T18:30:41Z",
  "published": "2025-07-25T18:30:41Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-36727"
    },
    {
      "type": "WEB",
      "url": "https://www.tenable.com/security/research/tra-2025-24"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-GPPM-8RX9-64W6

Vulnerability from github – Published: 2022-07-16 00:00 – Updated: 2022-07-23 00:00
VLAI
Details

Honeywell Alerton Visual Logic through 2022-05-04 allows unauthenticated programming writes from remote users. This enables code to be stored on the controller and then run without verification. A user with malicious intent can send a crafted packet to change and/or stop the program without the knowledge of other users, altering the controller's function. After the programming change, the program needs to be overwritten in order for the controller to restore its original operational function.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-30243"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-829"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-07-15T12:15:00Z",
    "severity": "HIGH"
  },
  "details": "Honeywell Alerton Visual Logic through 2022-05-04 allows unauthenticated programming writes from remote users. This enables code to be stored on the controller and then run without verification. A user with malicious intent can send a crafted packet to change and/or stop the program without the knowledge of other users, altering the controller\u0027s function. After the programming change, the program needs to be overwritten in order for the controller to restore its original operational function.",
  "id": "GHSA-gppm-8rx9-64w6",
  "modified": "2022-07-23T00:00:20Z",
  "published": "2022-07-16T00:00:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-30243"
    },
    {
      "type": "WEB",
      "url": "https://blog.scadafence.com"
    },
    {
      "type": "WEB",
      "url": "https://github.com/scadafence/Honeywell-Alerton-Vulnerabilities"
    },
    {
      "type": "WEB",
      "url": "https://www.honeywell.com/us/en/product-security"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-GVPP-V77H-5W8G

Vulnerability from github – Published: 2026-07-01 18:41 – Updated: 2026-07-01 18:41
VLAI
Summary
Cortex has Untrusted Project Bootstrap Code Execution via `CLAUDE_PROJECT_DIR`
Details

Untrusted Project Bootstrap Code Execution via CLAUDE_PROJECT_DIR

Summary

The Cortex MCP server (neuro-cortex-memory) treats the CLAUDE_PROJECT_DIR environment variable — automatically set by Claude Code to the currently open project directory — as a trusted Cortex developer checkout. When the open_visualization tool is invoked, _find_dev_source() resolves the user's active project directory as a candidate Cortex source root. The only validation performed by _is_cortex_root() is a check for the presence of an mcp_server/ subdirectory and a ui/unified-viz.html file. An attacker who places these two marker files in a malicious repository can cause Cortex to execute an arbitrary mcp_server/server/visualize_bootstrap.py from that directory via subprocess.run([sys.executable, ...]), achieving code execution with the privileges of the victim's local user process. CVSS v3.1 Base Score: 7.8 (High).

Details

The vulnerability originates in _find_dev_source() inside mcp_server/handlers/open_visualization.py. The function builds a list of candidate directories by iterating over the environment variables CORTEX_DEV_ROOT and CLAUDE_PROJECT_DIR:

# mcp_server/handlers/open_visualization.py:73-76
for env in ("CORTEX_DEV_ROOT", "CLAUDE_PROJECT_DIR"):
    v = os.environ.get(env)
    if v:
        candidates.append(Path(v))

CLAUDE_PROJECT_DIR is set automatically by the Claude Code IDE extension to whichever directory the user has currently open. This means any project the user opens is silently treated as a candidate Cortex source root.

Each candidate is then validated by _is_cortex_root() (lines 65–70), which only verifies that the directory contains an mcp_server/ subdirectory and a ui/unified-viz.html file — trivial markers that an attacker can replicate:

# mcp_server/handlers/open_visualization.py:65-70
def _is_cortex_root(path: Path) -> bool:
    return (path / "mcp_server").is_dir() and \
           (path / "ui" / "unified-viz.html").is_file()

There is no git remote identity check, no cryptographic signature verification, no release path allowlist, and no explicit developer opt-in requirement. Once a directory passes _is_cortex_root(), the handler constructs a bootstrap path and executes it unconditionally:

# mcp_server/handlers/open_visualization.py:179-185
bootstrap_path = dev_src / "mcp_server" / "server" / "visualize_bootstrap.py"
if bootstrap_path.is_file():
    ...
    proc = subprocess.run(
        [sys.executable, str(bootstrap_path)],
    )

A secondary code-execution path exists in mcp_server/server/http_launcher.py:80-83 and 273-275, where the same CLAUDE_PROJECT_DIR-derived dev source is used to rsync attacker-controlled files into the Cortex plugin cache directory before serving them.

Entry point: MCP tool open_visualization, registered at mcp_server/tool_registry_core.py:194-207 (no authentication required at tool layer). The tool is reachable through the standard stdio MCP transport started in mcp_server/__main__.py:66.

PoC

Prerequisites

  • Cortex (neuro-cortex-memory ≥ 3.17.0) installed and importable.
  • Victim opens an attacker-controlled project directory in Claude Code (sets CLAUDE_PROJECT_DIR automatically) or the attacker otherwise controls CLAUDE_PROJECT_DIR.
  • Victim invokes /cortex-visualize or triggers the open_visualization MCP tool (e.g., by selecting a visualization command in the Claude Code interface).

Inline PoC

import asyncio, os, tempfile
from pathlib import Path
from mcp_server.handlers import open_visualization as ov

base = Path(tempfile.mkdtemp(prefix="cortex-malicious-project-"))
(base / "mcp_server" / "server").mkdir(parents=True)
(base / "ui").mkdir()
(base / "ui" / "unified-viz.html").write_text("<html>attacker</html>", encoding="utf-8")

sentinel = Path("/tmp/cortex-open-visualization-poc-owned")
if sentinel.exists():
    sentinel.unlink()

(base / "mcp_server" / "server" / "visualize_bootstrap.py").write_text(
    "from pathlib import Path\n"
    "Path('/tmp/cortex-open-visualization-poc-owned').write_text('executed', encoding='utf-8')\n"
    "print('bootstrap-ran')\n",
    encoding="utf-8",
)

os.environ["CLAUDE_PROJECT_DIR"] = str(base)
ov.launch_server = lambda _typ: "http://127.0.0.1:3458"
ov.open_in_browser = lambda _url: None

result = asyncio.run(ov.handler({}))
print(result.get("bootstrap"))
print(sentinel.read_text())

Expected output:

bootstrap-ran
executed

Recommended Remediation

Remove CLAUDE_PROJECT_DIR from the dev-source candidate list. Gate executable dev-source resolution behind an explicit opt-in flag so that only a developer who deliberately sets both CORTEX_DEV_SOURCE_SYNC=1 and CORTEX_DEV_ROOT can trigger the bootstrap path:

--- a/mcp_server/handlers/open_visualization.py
+++ b/mcp_server/handlers/open_visualization.py
-    candidates: list[Path] = []
-    for env in ("CORTEX_DEV_ROOT", "CLAUDE_PROJECT_DIR"):
-        v = os.environ.get(env)
-        if v:
-            candidates.append(Path(v))
+    candidates: list[Path] = []
+    if os.environ.get("CORTEX_DEV_SOURCE_SYNC") == "1":
+        v = os.environ.get("CORTEX_DEV_ROOT")
+        if v:
+            candidates.append(Path(v))
     candidates.append(Path.home() / "Documents" / "Developments" / "Cortex")

Apply the same change to mcp_server/server/http_launcher.py:80-83 to eliminate the secondary rsync execution path.

Impact

This is a local arbitrary code execution vulnerability. Any user who has the Cortex MCP plugin installed and opens (or is social-engineered into opening) an attacker-crafted project directory in Claude Code is at risk. When the victim invokes the open_visualization tool (e.g., via the /cortex-visualize slash command), attacker-controlled Python code runs immediately with the full privileges of the victim's local user account — the same privileges used by Claude Code and the Cortex MCP server process.

Consequences include but are not limited to:

  • Confidentiality: exfiltration of files, secrets, environment variables, and SSH/GPG keys accessible to the local user.
  • Integrity: modification or deletion of local files, source code, credentials, and plugin caches.
  • Availability: termination of local processes or destruction of user data.

The secondary path through http_launcher.py additionally allows the attacker to overwrite files in the Cortex plugin cache directory, potentially establishing persistence that survives after the malicious project is closed.

The attack requires the victim to invoke the visualization tool (UI:R), which is reflected in the CVSS score. No elevated privileges or prior authentication to any network service are required.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.17.0"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "neuro-cortex-memory"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.18.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-49986"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-829"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-01T18:41:35Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Untrusted Project Bootstrap Code Execution via `CLAUDE_PROJECT_DIR`\n\n### Summary\n\nThe Cortex MCP server (`neuro-cortex-memory`) treats the `CLAUDE_PROJECT_DIR` environment variable \u2014 automatically set by Claude Code to the currently open project directory \u2014 as a trusted Cortex developer checkout. When the `open_visualization` tool is invoked, `_find_dev_source()` resolves the user\u0027s active project directory as a candidate Cortex source root. The only validation performed by `_is_cortex_root()` is a check for the presence of an `mcp_server/` subdirectory and a `ui/unified-viz.html` file. An attacker who places these two marker files in a malicious repository can cause Cortex to execute an arbitrary `mcp_server/server/visualize_bootstrap.py` from that directory via `subprocess.run([sys.executable, ...])`, achieving code execution with the privileges of the victim\u0027s local user process. CVSS v3.1 Base Score: **7.8 (High)**.\n\n### Details\n\nThe vulnerability originates in `_find_dev_source()` inside `mcp_server/handlers/open_visualization.py`. The function builds a list of candidate directories by iterating over the environment variables `CORTEX_DEV_ROOT` and `CLAUDE_PROJECT_DIR`:\n\n```python\n# mcp_server/handlers/open_visualization.py:73-76\nfor env in (\"CORTEX_DEV_ROOT\", \"CLAUDE_PROJECT_DIR\"):\n    v = os.environ.get(env)\n    if v:\n        candidates.append(Path(v))\n```\n\n`CLAUDE_PROJECT_DIR` is set automatically by the Claude Code IDE extension to whichever directory the user has currently open. This means **any project the user opens** is silently treated as a candidate Cortex source root.\n\nEach candidate is then validated by `_is_cortex_root()` (lines 65\u201370), which only verifies that the directory contains an `mcp_server/` subdirectory and a `ui/unified-viz.html` file \u2014 trivial markers that an attacker can replicate:\n\n```python\n# mcp_server/handlers/open_visualization.py:65-70\ndef _is_cortex_root(path: Path) -\u003e bool:\n    return (path / \"mcp_server\").is_dir() and \\\n           (path / \"ui\" / \"unified-viz.html\").is_file()\n```\n\nThere is no git remote identity check, no cryptographic signature verification, no release path allowlist, and no explicit developer opt-in requirement. Once a directory passes `_is_cortex_root()`, the handler constructs a bootstrap path and executes it unconditionally:\n\n```python\n# mcp_server/handlers/open_visualization.py:179-185\nbootstrap_path = dev_src / \"mcp_server\" / \"server\" / \"visualize_bootstrap.py\"\nif bootstrap_path.is_file():\n    ...\n    proc = subprocess.run(\n        [sys.executable, str(bootstrap_path)],\n    )\n```\n\nA secondary code-execution path exists in `mcp_server/server/http_launcher.py:80-83` and `273-275`, where the same `CLAUDE_PROJECT_DIR`-derived dev source is used to `rsync` attacker-controlled files into the Cortex plugin cache directory before serving them.\n\n**Entry point**: MCP tool `open_visualization`, registered at `mcp_server/tool_registry_core.py:194-207` (no authentication required at tool layer). The tool is reachable through the standard stdio MCP transport started in `mcp_server/__main__.py:66`.\n\n### PoC\n\n**Prerequisites**\n\n- Cortex (`neuro-cortex-memory` \u2265 3.17.0) installed and importable.\n- Victim opens an attacker-controlled project directory in Claude Code (sets `CLAUDE_PROJECT_DIR` automatically) or the attacker otherwise controls `CLAUDE_PROJECT_DIR`.\n- Victim invokes `/cortex-visualize` or triggers the `open_visualization` MCP tool (e.g., by selecting a visualization command in the Claude Code interface).\n\n**Inline PoC**\n\n```python\nimport asyncio, os, tempfile\nfrom pathlib import Path\nfrom mcp_server.handlers import open_visualization as ov\n\nbase = Path(tempfile.mkdtemp(prefix=\"cortex-malicious-project-\"))\n(base / \"mcp_server\" / \"server\").mkdir(parents=True)\n(base / \"ui\").mkdir()\n(base / \"ui\" / \"unified-viz.html\").write_text(\"\u003chtml\u003eattacker\u003c/html\u003e\", encoding=\"utf-8\")\n\nsentinel = Path(\"/tmp/cortex-open-visualization-poc-owned\")\nif sentinel.exists():\n    sentinel.unlink()\n\n(base / \"mcp_server\" / \"server\" / \"visualize_bootstrap.py\").write_text(\n    \"from pathlib import Path\\n\"\n    \"Path(\u0027/tmp/cortex-open-visualization-poc-owned\u0027).write_text(\u0027executed\u0027, encoding=\u0027utf-8\u0027)\\n\"\n    \"print(\u0027bootstrap-ran\u0027)\\n\",\n    encoding=\"utf-8\",\n)\n\nos.environ[\"CLAUDE_PROJECT_DIR\"] = str(base)\nov.launch_server = lambda _typ: \"http://127.0.0.1:3458\"\nov.open_in_browser = lambda _url: None\n\nresult = asyncio.run(ov.handler({}))\nprint(result.get(\"bootstrap\"))\nprint(sentinel.read_text())\n```\n\nExpected output:\n```\nbootstrap-ran\nexecuted\n```\n\n**Recommended Remediation**\n\nRemove `CLAUDE_PROJECT_DIR` from the dev-source candidate list. Gate executable dev-source resolution behind an explicit opt-in flag so that only a developer who deliberately sets both `CORTEX_DEV_SOURCE_SYNC=1` and `CORTEX_DEV_ROOT` can trigger the bootstrap path:\n\n```diff\n--- a/mcp_server/handlers/open_visualization.py\n+++ b/mcp_server/handlers/open_visualization.py\n-    candidates: list[Path] = []\n-    for env in (\"CORTEX_DEV_ROOT\", \"CLAUDE_PROJECT_DIR\"):\n-        v = os.environ.get(env)\n-        if v:\n-            candidates.append(Path(v))\n+    candidates: list[Path] = []\n+    if os.environ.get(\"CORTEX_DEV_SOURCE_SYNC\") == \"1\":\n+        v = os.environ.get(\"CORTEX_DEV_ROOT\")\n+        if v:\n+            candidates.append(Path(v))\n     candidates.append(Path.home() / \"Documents\" / \"Developments\" / \"Cortex\")\n```\n\nApply the same change to `mcp_server/server/http_launcher.py:80-83` to eliminate the secondary rsync execution path.\n\n### Impact\n\nThis is a **local arbitrary code execution** vulnerability. Any user who has the Cortex MCP plugin installed and opens (or is social-engineered into opening) an attacker-crafted project directory in Claude Code is at risk. When the victim invokes the `open_visualization` tool (e.g., via the `/cortex-visualize` slash command), attacker-controlled Python code runs immediately with the full privileges of the victim\u0027s local user account \u2014 the same privileges used by Claude Code and the Cortex MCP server process.\n\nConsequences include but are not limited to:\n\n- **Confidentiality**: exfiltration of files, secrets, environment variables, and SSH/GPG keys accessible to the local user.\n- **Integrity**: modification or deletion of local files, source code, credentials, and plugin caches.\n- **Availability**: termination of local processes or destruction of user data.\n\nThe secondary path through `http_launcher.py` additionally allows the attacker to overwrite files in the Cortex plugin cache directory, potentially establishing persistence that survives after the malicious project is closed.\n\nThe attack requires the victim to invoke the visualization tool (UI:R), which is reflected in the CVSS score. No elevated privileges or prior authentication to any network service are required.",
  "id": "GHSA-gvpp-v77h-5w8g",
  "modified": "2026-07-01T18:41:35Z",
  "published": "2026-07-01T18:41:35Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/cdeust/Cortex/security/advisories/GHSA-gvpp-v77h-5w8g"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/cdeust/Cortex"
    },
    {
      "type": "WEB",
      "url": "https://github.com/cdeust/Cortex/releases/tag/v3.17.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:P",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Cortex has Untrusted Project Bootstrap Code Execution via `CLAUDE_PROJECT_DIR`"
}

GHSA-H7MX-548V-CR9R

Vulnerability from github – Published: 2025-04-03 15:31 – Updated: 2026-06-26 00:31
VLAI
Details

A flaw was found in Yelp. The Gnome user help application allows the help document to execute arbitrary scripts. This vulnerability allows malicious users to input help documents, which may exfiltrate user files to an external environment.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-3155"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-601",
      "CWE-829"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-04-03T14:15:46Z",
    "severity": "MODERATE"
  },
  "details": "A flaw was found in Yelp. The Gnome user help application allows the help document to execute arbitrary scripts. This vulnerability allows malicious users to input help documents, which may exfiltrate user files to an external environment.",
  "id": "GHSA-h7mx-548v-cr9r",
  "modified": "2026-06-26T00:31:59Z",
  "published": "2025-04-03T15:31:19Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-3155"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2025:4450"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2025:4451"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2025:4455"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2025:4456"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2025:4457"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2025:4505"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2025:4532"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2025:7430"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2025:7569"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2025-3155"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2357091"
    },
    {
      "type": "WEB",
      "url": "https://gist.github.com/parrot409/e970b155358d45b298d7024edd9b17f2"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.gnome.org/GNOME/yelp/-/issues/221"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/05/msg00036.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/05/msg00037.html"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2025/04/04/1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-HG32-P8HW-8G3X

Vulnerability from github – Published: 2022-04-29 02:57 – Updated: 2024-02-08 03:32
VLAI
Details

PHP remote file inclusion vulnerabilities in include/footer.inc.php in (1) AllMyVisitors, (2) AllMyLinks, and (3) AllMyGuests allow remote attackers to execute arbitrary PHP code via a URL in the _AMVconfig[cfg_serverpath] parameter.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2004-0285"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-829",
      "CWE-94"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2004-11-23T05:00:00Z",
    "severity": "HIGH"
  },
  "details": "PHP remote file inclusion vulnerabilities in include/footer.inc.php in (1) AllMyVisitors, (2) AllMyLinks, and (3) AllMyGuests allow remote attackers to execute arbitrary PHP code via a URL in the _AMVconfig[cfg_serverpath] parameter.",
  "id": "GHSA-hg32-p8hw-8g3x",
  "modified": "2024-02-08T03:32:43Z",
  "published": "2022-04-29T02:57:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2004-0285"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/15226"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/15227"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/15228"
    },
    {
      "type": "WEB",
      "url": "http://marc.info/?l=bugtraq\u0026m=107696209514155\u0026w=2"
    },
    {
      "type": "WEB",
      "url": "http://marc.info/?l=bugtraq\u0026m=107696235424865\u0026w=2"
    },
    {
      "type": "WEB",
      "url": "http://marc.info/?l=bugtraq\u0026m=107696291728750\u0026w=2"
    },
    {
      "type": "WEB",
      "url": "http://www.osvdb.org/6721"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/9664"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

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].

Mitigation MIT-21.1
Architecture and Design

Strategy: Enforcement by Conversion

  • When the set of acceptable objects, such as filenames or URLs, is limited or known, create a mapping from a set of fixed input values (such as numeric IDs) to the actual filenames or URLs, and reject all other inputs.
  • For example, ID 1 could map to "inbox.txt" and ID 2 could map to "profile.txt". Features such as the ESAPI AccessReferenceMap [REF-45] provide this capability.
Mitigation MIT-15
Architecture and Design

For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.

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.
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-5.1
Implementation

Strategy: Input Validation

  • Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
  • When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."
  • Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
  • When validating filenames, use stringent allowlists that limit the character set to be used. If feasible, only allow a single "." character in the filename to avoid weaknesses such as CWE-23, and exclude directory separators such as "/" to avoid CWE-36. Use a list of allowable file extensions, which will help to avoid CWE-434.
  • Do not rely exclusively on a filtering mechanism that removes potentially dangerous characters. This is equivalent to a denylist, which may be incomplete (CWE-184). For example, filtering "/" is insufficient protection if the filesystem also supports the use of "\" as a directory separator. Another possible error could occur when the filtering is applied in a way that still produces dangerous data (CWE-182). For example, if "../" sequences are removed from the ".../...//" string in a sequential fashion, two instances of "../" would be removed from the original string, but the remaining characters would still form the "../" string.
Mitigation MIT-34
Architecture and Design Operation

Strategy: Attack Surface Reduction

  • Store library, include, and utility files outside of the web document root, if possible. Otherwise, store them in a separate directory and use the web server's access control capabilities to prevent attackers from directly requesting them. One common practice is to define a fixed constant in each calling program, then check for the existence of the constant in the library/include file; if the constant does not exist, then the file was directly requested, and it can exit immediately.
  • This significantly reduces the chance of an attacker being able to bypass any protection mechanisms that are in the base program but not in the include files. It will also reduce the attack surface.
Mitigation MIT-6
Architecture and Design Implementation

Strategy: Attack Surface Reduction

  • Understand all the potential areas where untrusted inputs can enter your software: parameters or arguments, cookies, anything read from the network, environment variables, reverse DNS lookups, query results, request headers, URL components, e-mail, files, filenames, databases, and any external systems that provide data to the application. Remember that such inputs may be obtained indirectly through API calls.
  • Many file inclusion problems occur because the programmer assumed that certain inputs could not be modified, especially for cookies and URL components.
Mitigation MIT-29
Operation

Strategy: Firewall

Use an application firewall that can detect attacks against this weakness. It can be beneficial in cases in which the code cannot be fixed (because it is controlled by a third party), as an emergency prevention measure while more comprehensive software assurance measures are applied, or to provide defense in depth [REF-1481].

CAPEC-175: Code Inclusion

An adversary exploits a weakness on the target to force arbitrary code to be retrieved locally or from a remote location and executed. This differs from code injection in that code injection involves the direct inclusion of code while code inclusion involves the addition or replacement of a reference to a code file, which is subsequently loaded by the target and used as part of the code of some application.

CAPEC-201: Serialized Data External Linking

An adversary creates a serialized data file (e.g. XML, YAML, etc...) that contains an external data reference. Because serialized data parsers may not validate documents with external references, there may be no checks on the nature of the reference in the external data. This can allow an adversary to open arbitrary files or connections, which may further lead to the adversary gaining access to information on the system that they would normally be unable to obtain.

CAPEC-228: DTD Injection

An attacker injects malicious content into an application's DTD in an attempt to produce a negative technical impact. DTDs are used to describe how XML documents are processed. Certain malformed DTDs (for example, those with excessive entity expansion as described in CAPEC 197) can cause the XML parsers that process the DTDs to consume excessive resources resulting in resource depletion.

CAPEC-251: Local Code Inclusion

The attacker forces an application to load arbitrary code files from the local machine. The attacker could use this to try to load old versions of library files that have known vulnerabilities, to load files that the attacker placed on the local machine during a prior attack, or to otherwise change the functionality of the targeted application in unexpected ways.

CAPEC-252: PHP Local File Inclusion

The attacker loads and executes an arbitrary local PHP file on a target machine. The attacker could use this to try to load old versions of PHP files that have known vulnerabilities, to load PHP files that the attacker placed on the local machine during a prior attack, or to otherwise change the functionality of the targeted application in unexpected ways.

CAPEC-253: Remote Code Inclusion

The attacker forces an application to load arbitrary code files from a remote location. The attacker could use this to try to load old versions of library files that have known vulnerabilities, to load malicious files that the attacker placed on the remote machine, or to otherwise change the functionality of the targeted application in unexpected ways.

CAPEC-263: Force Use of Corrupted Files

This describes an attack where an application is forced to use a file that an attacker has corrupted. The result is often a denial of service caused by the application being unable to process the corrupted file, but other results, including the disabling of filters or access controls (if the application fails in an unsafe way rather than failing by locking down) or buffer overflows are possible.

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-549: Local Execution of Code

An adversary installs and executes malicious code on the target system in an effort to achieve a negative technical impact. Examples include rootkits, ransomware, spyware, adware, and others.

CAPEC-640: Inclusion of Code in Existing Process

The adversary takes advantage of a bug in an application failing to verify the integrity of the running process to execute arbitrary code in the address space of a separate live process. The adversary could use running code in the context of another process to try to access process's memory, system/network resources, etc. The goal of this attack is to evade detection defenses and escalate privileges by masking the malicious code under an existing legitimate process. Examples of approaches include but not limited to: dynamic-link library (DLL) injection, portable executable injection, thread execution hijacking, ptrace system calls, VDSO hijacking, function hooking, reflective code loading, and more.

CAPEC-660: Root/Jailbreak Detection Evasion via Hooking

An adversary forces a non-restricted mobile application to load arbitrary code or code files, via Hooking, with the goal of evading Root/Jailbreak detection. Mobile device users often Root/Jailbreak their devices in order to gain administrative control over the mobile operating system and/or to install third-party mobile applications that are not provided by authorized application stores (e.g. Google Play Store and Apple App Store). Adversaries may further leverage these capabilities to escalate privileges or bypass access control on legitimate applications. Although many mobile applications check if a mobile device is Rooted/Jailbroken prior to authorized use of the application, adversaries may be able to "hook" code in order to circumvent these checks. Successfully evading Root/Jailbreak detection allows an adversary to execute administrative commands, obtain confidential data, impersonate legitimate users of the application, and more.

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.

CAPEC-698: Install Malicious Extension

An adversary directly installs or tricks a user into installing a malicious extension into existing trusted software, with the goal of achieving a variety of negative technical impacts.