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-VMQV-HX8Q-J7MG

Vulnerability from github – Published: 2025-09-03 21:27 – Updated: 2025-09-05 16:10
VLAI
Summary
Electron has ASAR Integrity Bypass via resource modification
Details

Impact

This only impacts apps that have the embeddedAsarIntegrityValidation and onlyLoadAppFromAsar fuses enabled. Apps without these fuses enabled are not impacted.

Specifically this issue can only be exploited if your app is launched from a filesystem the attacker has write access too. i.e. the ability to edit files inside the resources folder in your app installation on Windows which these fuses are supposed to protect against.

Workarounds

There are no app side workarounds, you must update to a patched version of Electron.

Fixed Versions

  • 38.0.0-beta.6
  • 37.3.1
  • 36.8.1
  • 35.7.5

For more information

If you have any questions or comments about this advisory, email us at security@electronjs.org

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "electron"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "35.7.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "electron"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "36.0.0-alpha.1"
            },
            {
              "fixed": "36.8.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "electron"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "37.0.0-alpha.1"
            },
            {
              "fixed": "37.3.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "electron"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "38.0.0-alpha.1"
            },
            {
              "fixed": "38.0.0-beta.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-55305"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-829",
      "CWE-94"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-09-03T21:27:37Z",
    "nvd_published_at": "2025-09-04T23:15:33Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\nThis only impacts apps that have the `embeddedAsarIntegrityValidation` and `onlyLoadAppFromAsar` [fuses](https://www.electronjs.org/docs/latest/tutorial/fuses) enabled.  Apps without these fuses enabled are not impacted.\n\nSpecifically this issue can only be exploited if your app is launched from a filesystem the attacker has write access too.  i.e. the ability to edit files inside the `resources` folder in your app installation on Windows which these fuses are supposed to protect against.\n\n### Workarounds\nThere are no app side workarounds, you must update to a patched version of Electron.\n\n### Fixed Versions\n* `38.0.0-beta.6`\n* `37.3.1`\n* `36.8.1`\n* `35.7.5`\n\n### For more information\nIf you have any questions or comments about this advisory, email us at [security@electronjs.org](mailto:security@electronjs.org)",
  "id": "GHSA-vmqv-hx8q-j7mg",
  "modified": "2025-09-05T16:10:10Z",
  "published": "2025-09-03T21:27:37Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/electron/electron/security/advisories/GHSA-vmqv-hx8q-j7mg"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-55305"
    },
    {
      "type": "WEB",
      "url": "https://github.com/electron/electron/pull/48101"
    },
    {
      "type": "WEB",
      "url": "https://github.com/electron/electron/pull/48102"
    },
    {
      "type": "WEB",
      "url": "https://github.com/electron/electron/pull/48103"
    },
    {
      "type": "WEB",
      "url": "https://github.com/electron/electron/pull/48104"
    },
    {
      "type": "WEB",
      "url": "https://github.com/electron/electron/commit/23a02934510fcf951428e14573d9b2d2a3c4f28b"
    },
    {
      "type": "WEB",
      "url": "https://github.com/electron/electron/commit/2e5a0b7220ebf955c6785cc5adb2e2b1cf77dac1"
    },
    {
      "type": "WEB",
      "url": "https://github.com/electron/electron/commit/3f92511cdecc39f46b0e86cce40a0c691e301c9d"
    },
    {
      "type": "WEB",
      "url": "https://github.com/electron/electron/commit/fdf29ce83870109d403f5c23ae529dbd0e8f4fee"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/electron/electron"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:L/I:H/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Electron has ASAR Integrity Bypass via resource modification"
}

GHSA-VRGW-PC9C-QRRC

Vulnerability from github – Published: 2026-01-13 19:54 – Updated: 2026-01-16 21:54
VLAI
Summary
UmbracoForms Vulnerable to Remote Code Execution via Untrusted WSDL Compilation in Dynamic SOAP Client Generation
Details

Impact

Within Umbraco Forms, configuring a malicious URL on the Webservice data source can result in Remote Code Execution. This affects all Umbraco Forms versions running on .NET Framework (up to and including version 8).

Patches

The affected Umbraco Forms versions are all End-of-Life (EOL) and not supported anymore, hence no patches will be released. Upgrading to any of the currently supported versions (v13, v16 or v17) is recommended.

Workarounds

If none of the configured Forms data sources uses the Webservice type, it can be safely excluded by adding the following code to the application. This will completely remove the option to select/use this data source within the Backoffice and thereby mitigate the vulnerability.

using Umbraco.Core.Composing;
using Umbraco.Forms.Core.Providers;
using Umbraco.Forms.Core.Providers.DatasourceTypes;

internal sealed class RemoveFormsWebserviceDataSourceTypeComposer : IUserComposer
{
    public void Compose(Composition composition)
        => composition.WithCollectionBuilder<DataSourceCollectionBuilder>().Exclude<Webservice>();
}

Any Webservice data source that is configured and still in use should be replaced with a custom implementation instead, before applying the above code. If this is not feasible, the vulnerability can be minimized by revoking the 'Manage Data Sources' from any non-administrator user and/or inheriting from the default Umbraco.Forms.Core.Providers.DatasourceTypes.Webservice class and overriding the ValidateSettings() method to ensure only trusted URLs can be used.

References

When upgrading to a supported version, please take the Forms version specific upgrade notes into account and check the CMS upgrade documentation. Content and schema can also be migrated straight to the latest version using Deploy export/import with migrations.

Implementation details on data sources are not extensively documented, but they follow the general Forms provider model and inherit from Umbraco.Forms.Core.FormDataSource.

A special thanks to Piotr Bazydlo (@chudyPB) of watchTowr for finding and disclosing this vulnerability

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "UmbracoForms"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "8.13.16"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-68924"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-502",
      "CWE-829",
      "CWE-915",
      "CWE-94"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-01-13T19:54:05Z",
    "nvd_published_at": "2026-01-16T19:16:18Z",
    "severity": "CRITICAL"
  },
  "details": "### Impact\nWithin Umbraco Forms, configuring a malicious URL on the Webservice data source can result in Remote Code Execution. This affects all Umbraco Forms versions running on .NET Framework (up to and including version 8).\n\n### Patches\nThe affected Umbraco Forms versions are all End-of-Life (EOL) and not supported anymore, hence no patches will be released. Upgrading to any of the currently supported versions (v13, v16 or v17) is recommended.\n\n### Workarounds\nIf none of the configured Forms data sources uses the Webservice type, it can be safely excluded by adding the following code to the application. This will completely remove the option to select/use this data source within the Backoffice and thereby mitigate the vulnerability.\n\n```c#\nusing Umbraco.Core.Composing;\nusing Umbraco.Forms.Core.Providers;\nusing Umbraco.Forms.Core.Providers.DatasourceTypes;\n\ninternal sealed class RemoveFormsWebserviceDataSourceTypeComposer : IUserComposer\n{\n    public void Compose(Composition composition)\n        =\u003e composition.WithCollectionBuilder\u003cDataSourceCollectionBuilder\u003e().Exclude\u003cWebservice\u003e();\n}\n```\n\nAny Webservice data source that is configured and still in use should be replaced with a custom implementation instead, before applying the above code. If this is not feasible, the vulnerability can be minimized by revoking the \u0027Manage Data Sources\u0027 from any non-administrator user and/or inheriting from the default `Umbraco.Forms.Core.Providers.DatasourceTypes.Webservice` class and overriding the `ValidateSettings()` method to ensure only trusted URLs can be used.\n\n### References\nWhen upgrading to a supported version, please take the Forms [version specific upgrade notes](https://docs.umbraco.com/umbraco-forms/13.latest/upgrading/version-specific) into account and check the [CMS upgrade documentation](https://docs.umbraco.com/umbraco-cms/13.latest/fundamentals/setup/upgrading). Content and schema can also be migrated straight to the latest version using [Deploy export/import with migrations](https://docs.umbraco.com/umbraco-deploy/13.latest/deployment-workflow/import-export).\n\nImplementation details on data sources are not extensively documented, but they follow the general Forms [provider model](https://docs.umbraco.com/umbraco-forms/13.latest/developer/extending/adding-a-type) and inherit from `Umbraco.Forms.Core.FormDataSource`.\n\nA special thanks to Piotr Bazydlo (@chudyPB) of watchTowr for finding and disclosing this vulnerability",
  "id": "GHSA-vrgw-pc9c-qrrc",
  "modified": "2026-01-16T21:54:55Z",
  "published": "2026-01-13T19:54:05Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/umbraco/Umbraco.Forms.Issues/security/advisories/GHSA-vrgw-pc9c-qrrc"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68924"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/advisories/GHSA-vrgw-pc9c-qrrc"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/umbraco/Umbraco.Forms.Issues"
    },
    {
      "type": "WEB",
      "url": "https://our.umbraco.com/packages/developer-tools/umbraco-forms"
    },
    {
      "type": "WEB",
      "url": "https://www.nuget.org/packages/UmbracoForms"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "UmbracoForms Vulnerable to Remote Code Execution via Untrusted WSDL Compilation in Dynamic SOAP Client Generation"
}

GHSA-VV9J-GJW2-J8WP

Vulnerability from github – Published: 2026-05-26 23:10 – Updated: 2026-07-08 17:36
VLAI
Summary
yeoman-environment Vulnerable to Arbitrary Package Installation without User Confirmation
Details

Impact

yeoman-environment versions >= 2.9.0 and < 6.0.1 install missing local generator packages from caller-supplied package names without user confirmation. In downstream consumers that pass attacker-controlled project configuration into this path, this can result in arbitrary package installation and code execution during CLI bootstrap.

The vulnerable method is installLocalGenerators(), which calls repository.install() directly without prompting the user.

Patches

Upgrade to yeoman-environment 6.0.1, which adds an interactive confirmation prompt before installation (PR #753).

Workarounds

None.

Resources

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "yeoman-environment"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.9.0"
            },
            {
              "fixed": "6.0.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-42089"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-829"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-26T23:10:38Z",
    "nvd_published_at": "2026-06-16T17:16:40Z",
    "severity": "HIGH"
  },
  "details": "### Impact\n\n`yeoman-environment` versions `\u003e= 2.9.0` and `\u003c 6.0.1` install missing local generator packages from caller-supplied package names without user confirmation. In downstream consumers that pass attacker-controlled project configuration into this path, this can result in arbitrary package installation and code execution during CLI bootstrap.\n\nThe vulnerable method is `installLocalGenerators()`, which calls `repository.install()` directly without prompting the user.\n\n### Patches\n\nUpgrade to `yeoman-environment` `6.0.1`, which adds an interactive confirmation prompt before installation ([PR #753](https://github.com/yeoman/environment/pull/753)).\n\n### Workarounds\n\nNone.\n\n### Resources\n\n- [Fix commit 78d2af7](https://github.com/yeoman/environment/commit/78d2af7e60294784b8a8b3b3b5099c6874b6a1fa)",
  "id": "GHSA-vv9j-gjw2-j8wp",
  "modified": "2026-07-08T17:36:49Z",
  "published": "2026-05-26T23:10:38Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/yeoman/environment/security/advisories/GHSA-vv9j-gjw2-j8wp"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42089"
    },
    {
      "type": "WEB",
      "url": "https://github.com/yeoman/environment/pull/753"
    },
    {
      "type": "WEB",
      "url": "https://github.com/yeoman/environment/commit/78d2af7e60294784b8a8b3b3b5099c6874b6a1fa"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/yeoman/environment"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "yeoman-environment Vulnerable to Arbitrary Package Installation without User Confirmation"
}

GHSA-W466-C33R-3GJP

Vulnerability from github – Published: 2026-06-26 23:34 – Updated: 2026-06-26 23:34
VLAI
Summary
pnpm: Project env lockfile can short-circuit package-manager resolution and execute lockfile-selected pnpm bytes
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-063 / GHSA-w466-c33r-3gjp
  • Advisory URL: https://github.com/pnpm/pnpm/security/advisories/GHSA-w466-c33r-3gjp
  • 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 packageManager env lockfile
  • Patch area: package-manager env lockfile is re-resolved through trusted registries before execution
  • Affected packages: npm:pnpm, npm:@pnpm/installing.env-installer
  • CWE IDs: CWE-829, CWE-494, CWE-345
  • Conservative CVSS: 8.8 / CVSS:3.1/AV:N/AC:L/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

Committed env-lockfile package-manager entries are force-refreshed through trusted registries before execution; attacker tarball requests and markers stay at zero.

Files And Tests To Review

  • installing/env-installer/src/resolvePackageManagerIntegrities.ts
  • pnpm/src/switchCliVersion.ts
  • pnpm/src/switchCliVersion.test.ts
  • .changeset/clean-package-manager-registries.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 installing/env-installer/tsconfig.json
./node_modules/.bin/tsgo --build pnpm/tsconfig.json
PNPM_REGISTRY_MOCK_PORT=7799 NODE_OPTIONS="--experimental-vm-modules --disable-warning=ExperimentalWarning --disable-warning=DEP0169" ../node_modules/.bin/jest src/switchCliVersion.test.ts -t "re-resolved package-manager lockfile" --runInBand
PNPM_REGISTRY_MOCK_PORT=7799 NODE_OPTIONS="--experimental-vm-modules --disable-warning=ExperimentalWarning --disable-warning=DEP0169" ../node_modules/.bin/jest src/switchCliVersion.test.ts src/syncEnvLockfile.test.ts --runInBand
./node_modules/.bin/eslint installing/env-installer/src/resolvePackageManagerIntegrities.ts pnpm/src/switchCliVersion.ts pnpm/src/switchCliVersion.test.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-063-patched-result.json.

Summary

pnpm can persist package-manager bootstrap metadata in the first YAML document of pnpm-lock.yaml. Before the patch, direct pnpm execution trusted an already resolved packageManagerDependencies entry when the committed env lockfile contained matching pnpm and @pnpm/exe versions. A malicious repository could therefore commit package-manager lockfile package records and snapshots that bypassed fresh package-manager resolution, then cause pnpm to install and execute bytes selected by that committed lockfile state during automatic version switching.

Details

The vulnerable source-to-sink path was:

  • lockfile/fs/src/envLockfile.ts reads the repository's first YAML lockfile document and validates shape only.
  • pnpm/src/main.ts reaches switchCliVersion() when a direct pnpm invocation sees a wanted pnpm package manager with onFail=download.
  • pnpm/src/switchCliVersion.ts reads the committed env lockfile when package-manager metadata should be persisted.
  • installing/env-installer/src/resolvePackageManagerIntegrities.ts treated packageManagerDependencies as resolved when only the pnpm and @pnpm/exe versions matched.
  • engine/pm/commands/src/self-updater/installPnpm.ts converts env-lockfile snapshots and packages into the wanted lockfile used by headlessInstall().
  • pnpm/src/switchCliVersion.ts executes the installed pnpm binary with spawn.sync().

The helper fast path is intentionally still version-based for non-execution callers, so the security boundary is enforced at the execution path: switchCliVersion() now re-resolves already present package-manager env-lockfile entries before they can reach installPnpmToStore() and spawn.sync().

PoC

Standalone PoC and verification script:

The PoC constructs a committed env-lockfile object with matching package-manager dependency versions and attacker-selected package metadata:

{
  "importers": {
    ".": {
      "configDependencies": {},
      "packageManagerDependencies": {
        "@pnpm/exe": { "specifier": "9.3.0", "version": "9.3.0" },
        "pnpm": { "specifier": "9.3.0", "version": "9.3.0" }
      }
    }
  },
  "lockfileVersion": "9.0",
  "packages": {
    "/pnpm@9.3.0": {
      "resolution": {
        "integrity": "sha512-poisoned"
      }
    }
  },
  "snapshots": {
    "/pnpm@9.3.0": {}
  }
}

Pre-patch exploit model:

  1. The victim runs pnpm directly in a malicious repository.
  2. The requested package-manager version differs from the currently running pnpm.
  3. pnpm enters switchCliVersion() and reads the committed env lockfile.
  4. Matching pnpm / @pnpm/exe versions short-circuit package-manager resolution.
  5. pnpm installs from the committed env-lockfile package records and executes the resulting pnpm binary.

Observed primitive proof from the PoC:

{
  "primitive": "unforced resolver reuses already-resolved env lockfile metadata",
  "isResolvedByVersionOnly": true,
  "reusedPoisonedIntegrity": true
}

The same script then runs the patched switchCliVersion regression. The regression seeds a poisoned committed env lockfile, has the resolver return a trusted replacement lockfile, and asserts installPnpmToStore() receives the trusted lockfile rather than the committed one. This would fail on the vulnerable control flow because the resolver was not called and the committed lockfile reached the installer.

Focused validation commands:

./node_modules/.bin/tsgo --build installing/env-installer/tsconfig.json
./node_modules/.bin/tsgo --build pnpm/tsconfig.json
PNPM_REGISTRY_MOCK_PORT=7799 NODE_OPTIONS="--experimental-vm-modules --disable-warning=ExperimentalWarning --disable-warning=DEP0169" ../node_modules/.bin/jest src/switchCliVersion.test.ts -t "re-resolved package-manager lockfile" --runInBand
PNPM_REGISTRY_MOCK_PORT=7799 NODE_OPTIONS="--experimental-vm-modules --disable-warning=ExperimentalWarning --disable-warning=DEP0169" ../node_modules/.bin/jest src/switchCliVersion.test.ts src/syncEnvLockfile.test.ts --runInBand
./node_modules/.bin/eslint installing/env-installer/src/resolvePackageManagerIntegrities.ts pnpm/src/switchCliVersion.ts pnpm/src/switchCliVersion.test.ts
git diff --check

Validation result:

  • The PoC confirmed the unforced resolver still reuses a version-matching env lockfile, proving the original primitive.
  • Patched switchCliVersion() calls resolvePackageManagerIntegrities() with force: true when committed env-lockfile package-manager entries already satisfy the requested version.
  • Patched switchCliVersion() assigns the resolver return value back to envLockfile.
  • The installer receives the refreshed lockfile and not the poisoned committed lockfile.
  • TypeScript builds passed for @pnpm/installing.env-installer and pnpm.
  • The focused Jest regression passed: 1 passed, 1 skipped in switchCliVersion.test.ts.
  • ESLint passed for the affected package-manager switch files.
  • git diff --check passed.

Impact

A malicious repository can cause arbitrary package-manager code execution in the victim's developer or CI environment before normal command handling continues. That code executes with the victim user's privileges and can read local secrets, alter project files, mutate dependency state, or run further commands.

Affected products

Ecosystem: npm

Package name: pnpm, @pnpm/installing.env-installer

Affected versions: current main before this patch; direct pnpm execution with package-manager auto-switching and a repository-controlled env lockfile.

Patched versions: pending release containing this patch.

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: the malicious source is repository-controlled package-manager lockfile state delivered through normal supply-chain channels. Exploitation is low complexity once the victim runs pnpm directly, no attacker privileges are required, and user interaction is required. Successful exploitation executes attacker-selected package-manager code in the victim user's security context, with high confidentiality, integrity, and availability impact.

Weaknesses

CWE-829: Inclusion of Functionality from Untrusted Control Sphere

CWE-494: Download of Code Without Integrity Check

CWE-345: Insufficient Verification of Data Authenticity

Patch

The patch makes automatic package-manager switching re-resolve repository-provided bootstrap metadata before install and execution:

  • resolvePackageManagerIntegrities() accepts force, which bypasses the version-only fast path.
  • switchCliVersion() creates a store controller even when the committed env lockfile already contains satisfying package-manager dependency versions.
  • switchCliVersion() calls resolvePackageManagerIntegrities() with force: true for already resolved package-manager entries.
  • switchCliVersion() assigns the returned env lockfile back to envLockfile, so installPnpmToStore() installs from freshly resolved metadata.
  • The package-manager bootstrap registry hardening from CAND-PNPM-061 is reused, so the refresh happens through trusted package-manager registries rather than repository workspace registries.

Changed files:

  • installing/env-installer/src/resolvePackageManagerIntegrities.ts
  • pnpm/src/switchCliVersion.ts
  • pnpm/src/switchCliVersion.test.ts

Changeset:

  • .changeset/clean-package-manager-registries.md

Pacquet parity:

No pacquet-side patch is required for this finding because pacquet does not implement pnpm's package-manager auto-switch path or installPnpmToStore().

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 still demonstrates the underlying unforced env-lockfile reuse primitive, but the patched execution path force-refreshes package-manager metadata through trusted bootstrap registries before install or execution.

Remaining Risk

The helper resolvePackageManagerIntegrities() still has an unforced fast path that treats matching pnpm and @pnpm/exe versions as resolved. Current execution-sensitive callers either use trusted roots/registries or pass through the patched switchCliVersion() boundary, but future execution paths should use force: true before installing or executing package-manager bytes from repository-provided env-lockfile metadata.

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-55698"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-345",
      "CWE-494",
      "CWE-829"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-26T23:34:06Z",
    "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-063` / `GHSA-w466-c33r-3gjp`\n- Advisory URL: https://github.com/pnpm/pnpm/security/advisories/GHSA-w466-c33r-3gjp\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 packageManager env lockfile`\n- Patch area: package-manager env lockfile is re-resolved through trusted registries before execution\n- Affected packages: `npm:pnpm`, `npm:@pnpm/installing.env-installer`\n- CWE IDs: `CWE-829`, `CWE-494`, `CWE-345`\n- Conservative CVSS: `8.8` / `CVSS:3.1/AV:N/AC:L/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\nCommitted env-lockfile package-manager entries are force-refreshed through trusted registries before execution; attacker tarball requests and markers stay at zero.\n\n### Files And Tests To Review\n\n- `installing/env-installer/src/resolvePackageManagerIntegrities.ts`\n- `pnpm/src/switchCliVersion.ts`\n- `pnpm/src/switchCliVersion.test.ts`\n- `.changeset/clean-package-manager-registries.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 installing/env-installer/tsconfig.json\n./node_modules/.bin/tsgo --build pnpm/tsconfig.json\nPNPM_REGISTRY_MOCK_PORT=7799 NODE_OPTIONS=\"--experimental-vm-modules --disable-warning=ExperimentalWarning --disable-warning=DEP0169\" ../node_modules/.bin/jest src/switchCliVersion.test.ts -t \"re-resolved package-manager lockfile\" --runInBand\nPNPM_REGISTRY_MOCK_PORT=7799 NODE_OPTIONS=\"--experimental-vm-modules --disable-warning=ExperimentalWarning --disable-warning=DEP0169\" ../node_modules/.bin/jest src/switchCliVersion.test.ts src/syncEnvLockfile.test.ts --runInBand\n./node_modules/.bin/eslint installing/env-installer/src/resolvePackageManagerIntegrities.ts pnpm/src/switchCliVersion.ts pnpm/src/switchCliVersion.test.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-063-patched-result.json`.\n\u003c!-- maintainer-action:end --\u003e\n\n### Summary\n\npnpm can persist package-manager bootstrap metadata in the first YAML document of `pnpm-lock.yaml`. Before the patch, direct pnpm execution trusted an already resolved `packageManagerDependencies` entry when the committed env lockfile contained matching `pnpm` and `@pnpm/exe` versions. A malicious repository could therefore commit package-manager lockfile package records and snapshots that bypassed fresh package-manager resolution, then cause pnpm to install and execute bytes selected by that committed lockfile state during automatic version switching.\n\n### Details\n\nThe vulnerable source-to-sink path was:\n\n- `lockfile/fs/src/envLockfile.ts` reads the repository\u0027s first YAML lockfile document and validates shape only.\n- `pnpm/src/main.ts` reaches `switchCliVersion()` when a direct pnpm invocation sees a wanted `pnpm` package manager with `onFail=download`.\n- `pnpm/src/switchCliVersion.ts` reads the committed env lockfile when package-manager metadata should be persisted.\n- `installing/env-installer/src/resolvePackageManagerIntegrities.ts` treated `packageManagerDependencies` as resolved when only the `pnpm` and `@pnpm/exe` versions matched.\n- `engine/pm/commands/src/self-updater/installPnpm.ts` converts env-lockfile `snapshots` and `packages` into the wanted lockfile used by `headlessInstall()`.\n- `pnpm/src/switchCliVersion.ts` executes the installed `pnpm` binary with `spawn.sync()`.\n\nThe helper fast path is intentionally still version-based for non-execution callers, so the security boundary is enforced at the execution path: `switchCliVersion()` now re-resolves already present package-manager env-lockfile entries before they can reach `installPnpmToStore()` and `spawn.sync()`.\n\n### PoC\n\nStandalone PoC and verification script:\n\nThe PoC constructs a committed env-lockfile object with matching package-manager dependency versions and attacker-selected package metadata:\n\n```json\n{\n  \"importers\": {\n    \".\": {\n      \"configDependencies\": {},\n      \"packageManagerDependencies\": {\n        \"@pnpm/exe\": { \"specifier\": \"9.3.0\", \"version\": \"9.3.0\" },\n        \"pnpm\": { \"specifier\": \"9.3.0\", \"version\": \"9.3.0\" }\n      }\n    }\n  },\n  \"lockfileVersion\": \"9.0\",\n  \"packages\": {\n    \"/pnpm@9.3.0\": {\n      \"resolution\": {\n        \"integrity\": \"sha512-poisoned\"\n      }\n    }\n  },\n  \"snapshots\": {\n    \"/pnpm@9.3.0\": {}\n  }\n}\n```\n\nPre-patch exploit model:\n\n1. The victim runs pnpm directly in a malicious repository.\n2. The requested package-manager version differs from the currently running pnpm.\n3. pnpm enters `switchCliVersion()` and reads the committed env lockfile.\n4. Matching `pnpm` / `@pnpm/exe` versions short-circuit package-manager resolution.\n5. pnpm installs from the committed env-lockfile package records and executes the resulting `pnpm` binary.\n\nObserved primitive proof from the PoC:\n\n```json\n{\n  \"primitive\": \"unforced resolver reuses already-resolved env lockfile metadata\",\n  \"isResolvedByVersionOnly\": true,\n  \"reusedPoisonedIntegrity\": true\n}\n```\n\nThe same script then runs the patched `switchCliVersion` regression. The regression seeds a poisoned committed env lockfile, has the resolver return a trusted replacement lockfile, and asserts `installPnpmToStore()` receives the trusted lockfile rather than the committed one. This would fail on the vulnerable control flow because the resolver was not called and the committed lockfile reached the installer.\n\nFocused validation commands:\n\n```bash\n./node_modules/.bin/tsgo --build installing/env-installer/tsconfig.json\n./node_modules/.bin/tsgo --build pnpm/tsconfig.json\nPNPM_REGISTRY_MOCK_PORT=7799 NODE_OPTIONS=\"--experimental-vm-modules --disable-warning=ExperimentalWarning --disable-warning=DEP0169\" ../node_modules/.bin/jest src/switchCliVersion.test.ts -t \"re-resolved package-manager lockfile\" --runInBand\nPNPM_REGISTRY_MOCK_PORT=7799 NODE_OPTIONS=\"--experimental-vm-modules --disable-warning=ExperimentalWarning --disable-warning=DEP0169\" ../node_modules/.bin/jest src/switchCliVersion.test.ts src/syncEnvLockfile.test.ts --runInBand\n./node_modules/.bin/eslint installing/env-installer/src/resolvePackageManagerIntegrities.ts pnpm/src/switchCliVersion.ts pnpm/src/switchCliVersion.test.ts\ngit diff --check\n```\n\nValidation result:\n\n- The PoC confirmed the unforced resolver still reuses a version-matching env lockfile, proving the original primitive.\n- Patched `switchCliVersion()` calls `resolvePackageManagerIntegrities()` with `force: true` when committed env-lockfile package-manager entries already satisfy the requested version.\n- Patched `switchCliVersion()` assigns the resolver return value back to `envLockfile`.\n- The installer receives the refreshed lockfile and not the poisoned committed lockfile.\n- TypeScript builds passed for `@pnpm/installing.env-installer` and `pnpm`.\n- The focused Jest regression passed: 1 passed, 1 skipped in `switchCliVersion.test.ts`.\n- ESLint passed for the affected package-manager switch files.\n- `git diff --check` passed.\n\n### Impact\n\nA malicious repository can cause arbitrary package-manager code execution in the victim\u0027s developer or CI environment before normal command handling continues. That code executes with the victim user\u0027s privileges and can read local secrets, alter project files, mutate dependency state, or run further commands.\n\n## Affected products\n\nEcosystem: npm\n\nPackage name: `pnpm`, `@pnpm/installing.env-installer`\n\nAffected versions: current main before this patch; direct pnpm execution with package-manager auto-switching and a repository-controlled env lockfile.\n\nPatched versions: pending release containing this patch.\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: the malicious source is repository-controlled package-manager lockfile state delivered through normal supply-chain channels. Exploitation is low complexity once the victim runs pnpm directly, no attacker privileges are required, and user interaction is required. Successful exploitation executes attacker-selected package-manager code in the victim user\u0027s security context, with high confidentiality, integrity, and availability impact.\n\n## Weaknesses\n\nCWE-829: Inclusion of Functionality from Untrusted Control Sphere\n\nCWE-494: Download of Code Without Integrity Check\n\nCWE-345: Insufficient Verification of Data Authenticity\n\n## Patch\n\nThe patch makes automatic package-manager switching re-resolve repository-provided bootstrap metadata before install and execution:\n\n- `resolvePackageManagerIntegrities()` accepts `force`, which bypasses the version-only fast path.\n- `switchCliVersion()` creates a store controller even when the committed env lockfile already contains satisfying package-manager dependency versions.\n- `switchCliVersion()` calls `resolvePackageManagerIntegrities()` with `force: true` for already resolved package-manager entries.\n- `switchCliVersion()` assigns the returned env lockfile back to `envLockfile`, so `installPnpmToStore()` installs from freshly resolved metadata.\n- The package-manager bootstrap registry hardening from CAND-PNPM-061 is reused, so the refresh happens through trusted package-manager registries rather than repository workspace registries.\n\nChanged files:\n\n- `installing/env-installer/src/resolvePackageManagerIntegrities.ts`\n- `pnpm/src/switchCliVersion.ts`\n- `pnpm/src/switchCliVersion.test.ts`\n\nChangeset:\n\n- `.changeset/clean-package-manager-registries.md`\n\nPacquet parity:\n\nNo pacquet-side patch is required for this finding because pacquet does not implement pnpm\u0027s package-manager auto-switch path or `installPnpmToStore()`.\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 still demonstrates the underlying unforced env-lockfile reuse primitive, but the patched execution path force-refreshes package-manager metadata through trusted bootstrap registries before install or execution.\n\n## Remaining Risk\n\nThe helper `resolvePackageManagerIntegrities()` still has an unforced fast path that treats matching `pnpm` and `@pnpm/exe` versions as resolved. Current execution-sensitive callers either use trusted roots/registries or pass through the patched `switchCliVersion()` boundary, but future execution paths should use `force: true` before installing or executing package-manager bytes from repository-provided env-lockfile metadata.",
  "id": "GHSA-w466-c33r-3gjp",
  "modified": "2026-06-26T23:34:06Z",
  "published": "2026-06-26T23:34:06Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/pnpm/pnpm/security/advisories/GHSA-w466-c33r-3gjp"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-55698"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/pnpm/pnpm"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "pnpm: Project env lockfile can short-circuit package-manager resolution and execute lockfile-selected pnpm bytes"
}

GHSA-W4GP-QV48-5JC9

Vulnerability from github – Published: 2022-07-21 00:00 – Updated: 2026-01-09 06:31
VLAI
Details

Inclusion of Functionality from Untrusted Control Sphere vulnerability in ICONICS GENESIS64 versions 10.97.1 and prior and Mitsubishi Electric MC Works64 versions 4.04E (10.95.210.01) and prior allows an unauthenticated attacker to execute an arbitrary malicious code by leading a user to load a monitoring screen file including malicious script codes.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-33317"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-829"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-07-20T17:15:00Z",
    "severity": "HIGH"
  },
  "details": "Inclusion of Functionality from Untrusted Control Sphere vulnerability in ICONICS GENESIS64 versions 10.97.1 and prior and Mitsubishi Electric MC Works64 versions 4.04E (10.95.210.01) and prior allows an unauthenticated attacker to execute an arbitrary malicious code by leading a user to load a monitoring screen file including malicious script codes.",
  "id": "GHSA-w4gp-qv48-5jc9",
  "modified": "2026-01-09T06:31:04Z",
  "published": "2022-07-21T00:00:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-33317"
    },
    {
      "type": "WEB",
      "url": "https://jvn.jp/vu/JVNVU96480474/index.html"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/news-events/ics-advisories/icsa-22-202-04"
    },
    {
      "type": "WEB",
      "url": "https://www.mitsubishielectric.com/en/psirt/vulnerability/pdf/2022-008_en.pdf"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-W7H5-55JG-CQ2F

Vulnerability from github – Published: 2026-02-18 21:45 – Updated: 2026-02-20 16:48
VLAI
Summary
Improper Control of Generation of Code ('Code Injection') in @tygo-van-den-hurk/slyde
Details

Impact

This is a remote code execution (RCE) vulnerability. Node.js automatically imports **/*.plugin.{js,mjs} files including those from node_modules, so any malicious package with a .plugin.js file could execute arbitrary code when installed or required. All projects using this loading behavior are affected, especially those installing untrusted packages.

Patches

The issue has been patched in v0.0.5. Users should upgrade to v0.0.5 or later to mitigate the vulnerability.

Workarounds

  • Audit and restrict which packages are installed in node_modules.

References

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@tygo-van-den-hurk/slyde"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.0.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-26974"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-829"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-02-18T21:45:06Z",
    "nvd_published_at": "2026-02-20T01:16:00Z",
    "severity": "HIGH"
  },
  "details": "### Impact\nThis is a **remote code execution (RCE) vulnerability**. Node.js automatically imports `**/*.plugin.{js,mjs}` files including those from `node_modules`, so any malicious package with a `.plugin.js` file could execute arbitrary code when installed or required. **All projects using this loading behavior are affected**, especially those installing untrusted packages.\n\n### Patches\nThe issue has been **patched in v0.0.5**. Users should upgrade to **v0.0.5 or later** to mitigate the vulnerability.\n\n### Workarounds\n- Audit and restrict which packages are installed in `node_modules`.\n\n### References\n- [CWE-94: Improper Control of Generation of Code](https://cwe.mitre.org/data/definitions/94.html)  \n- GitHub Security Advisories documentation: [https://docs.github.com/en/code-security/security-advisories](https://docs.github.com/en/code-security/security-advisories)",
  "id": "GHSA-w7h5-55jg-cq2f",
  "modified": "2026-02-20T16:48:00Z",
  "published": "2026-02-18T21:45:06Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Tygo-van-den-Hurk/Slyde/security/advisories/GHSA-w7h5-55jg-cq2f"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-26974"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Tygo-van-den-Hurk/Slyde/commit/e4c215b061e44fd2ead805de34d72642a710af60"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/Tygo-van-den-Hurk/Slyde"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Tygo-van-den-Hurk/Slyde/releases/tag/v0.0.5"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:P/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Improper Control of Generation of Code (\u0027Code Injection\u0027) in @tygo-van-den-hurk/slyde"
}

GHSA-WFJ8-M9JG-H945

Vulnerability from github – Published: 2025-05-16 18:31 – Updated: 2026-04-01 18:35
VLAI
Details

Improper Control of Filename for Include/Require Statement in PHP Program ('PHP Remote File Inclusion') vulnerability in NasaTheme Nasa Core allows PHP Local File Inclusion. This issue affects Nasa Core: from n/a through 6.3.2.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-39507"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-829",
      "CWE-98"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-05-16T16:15:40Z",
    "severity": "HIGH"
  },
  "details": "Improper Control of Filename for Include/Require Statement in PHP Program (\u0027PHP Remote File Inclusion\u0027) vulnerability in NasaTheme Nasa Core allows PHP Local File Inclusion. This issue affects Nasa Core: from n/a through 6.3.2.",
  "id": "GHSA-wfj8-m9jg-h945",
  "modified": "2026-04-01T18:35:06Z",
  "published": "2025-05-16T18:31:07Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39507"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/wordpress/plugin/nasa-core/vulnerability/wordpress-nasa-core-plugin-6-3-2-local-file-inclusion-vulnerability?_s_id=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-WH9V-9X96-V32X

Vulnerability from github – Published: 2022-12-26 06:30 – Updated: 2023-01-05 18:30
VLAI
Details

Certain General Electric Renewable Energy products have a hidden feature for unauthenticated remote access to the device configuration shell. This affects iNET and iNET II before 8.3.0.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-24119"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-829"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-12-26T05:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "Certain General Electric Renewable Energy products have a hidden feature for unauthenticated remote access to the device configuration shell. This affects iNET and iNET II before 8.3.0.",
  "id": "GHSA-wh9v-9x96-v32x",
  "modified": "2023-01-05T18:30:30Z",
  "published": "2022-12-26T06:30:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-24119"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/uscert/ics/advisories/icsa-22-090-06"
    }
  ],
  "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"
    }
  ]
}

GHSA-WPQC-H9WP-CHMQ

Vulnerability from github – Published: 2025-12-08 21:30 – Updated: 2025-12-09 16:28
VLAI
Summary
n8n vulnerable to Remote Code Execution via Git Node Custom Pre-Commit Hook
Details

Impact

The n8n Git node allows workflows to set arbitrary Git configuration values through the Add Config operation. When an attacker-controlled workflow sets core.hooksPath to a directory within the cloned repository containing a Git hook such as pre-commit, Git executes that hook during subsequent Git operations. Because Git hooks run as local system commands, this behavior can lead to arbitrary command execution on the underlying n8n host.

Successful exploitation requires the ability to create or modify an n8n workflow that uses the Git node.

Affected versions: ≥ 0.123.1 and < 1.119.2

Patches

This issue has been patched in n8n version 1.119.2.

All users running affected versions should upgrade to 1.119.2 or later.

Workarounds

If upgrading is not immediately possible, the following mitigations can reduce exposure:

  • Exclude the Git node (Docs).
  • Avoid cloning or interacting with untrusted repositories using the Git Node.
Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "n8n"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.123.1"
            },
            {
              "fixed": "1.119.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-65964"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-829"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-12-08T21:30:07Z",
    "nvd_published_at": "2025-12-09T00:15:48Z",
    "severity": "CRITICAL"
  },
  "details": "### Impact\n\nThe n8n Git node allows workflows to set arbitrary Git configuration values through the _Add Config_ operation. When an attacker-controlled workflow sets `core.hooksPath` to a directory within the cloned repository containing a Git hook such as `pre-commit`, Git executes that hook during subsequent Git operations. Because Git hooks run as local system commands, this behavior can lead to **arbitrary command execution** on the underlying n8n host.\n\nSuccessful exploitation requires the ability to create or modify an n8n workflow that uses the Git node.\n\nAffected versions: **\u2265 0.123.1 and \u003c 1.119.2**\n\n### Patches\n\nThis issue has been patched in **n8n version 1.119.2**.\n\nAll users running affected versions should upgrade to **1.119.2 or later**.\n\n### Workarounds\n\nIf upgrading is not immediately possible, the following mitigations can reduce exposure:\n\n- Exclude the Git node ([Docs](https://n8n-docs.teamlab.info/hosting/securing/blocking-nodes/#exclude-nodes)).\n- Avoid cloning or interacting with untrusted repositories using the Git Node.",
  "id": "GHSA-wpqc-h9wp-chmq",
  "modified": "2025-12-09T16:28:13Z",
  "published": "2025-12-08T21:30:07Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/n8n-io/n8n/security/advisories/GHSA-wpqc-h9wp-chmq"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-65964"
    },
    {
      "type": "WEB",
      "url": "https://github.com/n8n-io/n8n/commit/d5a1171f95f75def5c3ac577707ab913e22aef04"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/n8n-io/n8n"
    },
    {
      "type": "WEB",
      "url": "https://github.com/n8n-io/n8n/releases/tag/n8n%401.119.2"
    },
    {
      "type": "WEB",
      "url": "https://n8n-docs.teamlab.info/hosting/securing/blocking-nodes/#exclude-nodes"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H",
      "type": "CVSS_V4"
    }
  ],
  "summary": "n8n vulnerable to Remote Code Execution via Git Node Custom Pre-Commit Hook"
}

GHSA-WPVM-WQR4-P7CW

Vulnerability from github – Published: 2021-10-13 15:34 – Updated: 2022-02-08 21:39
VLAI
Summary
Inclusion of Functionality from Untrusted Control Sphere in CKEditor 4
Details

It was possible to execute a ReDoS-type attack inside CKEditor 4 before 4.16 by persuading a victim to paste crafted URL-like text into the editor, and then press Enter or Space (in the Autolink plugin).

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "ckeditor4"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.16.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-26272"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-829"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-10-07T19:01:30Z",
    "nvd_published_at": "2021-01-26T21:15:00Z",
    "severity": "MODERATE"
  },
  "details": "It was possible to execute a ReDoS-type attack inside CKEditor 4 before 4.16 by persuading a victim to paste crafted URL-like text into the editor, and then press Enter or Space (in the Autolink plugin).",
  "id": "GHSA-wpvm-wqr4-p7cw",
  "modified": "2022-02-08T21:39:05Z",
  "published": "2021-10-13T15:34:09Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-26272"
    },
    {
      "type": "WEB",
      "url": "https://ckeditor.com/blog/CKEditor-4.16-with-improved-image-pasting-High-Contrast-support-and-a-new-color-API/#security-comes-first"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/ckeditor/ckeditor4"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ckeditor/ckeditor4/blob/major/CHANGES.md#ckeditor-416"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com//security-alerts/cpujul2021.html"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpujan2022.html"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpuoct2021.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Inclusion of Functionality from Untrusted Control Sphere in CKEditor 4"
}

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.