CVE-2026-42089: Yeoman Environment Arbitrary Package Installation Vulnerability

Technical summary

The vulnerability exists in the installLocalGenerators() method of Yeoman Environment, which directly invokes repository.install() on caller-supplied package names without user interaction or validation. This creates an implicit trust boundary violation: downstream tools that integrate Yeoman and pass attacker-influenced configuration data into the generator resolution path become attack vectors. The issue is classified as CWE-829 (Inclusion of Functionality from Untrusted Control Sphere), reflecting the core problem of trusting external configuration to determine what code gets executed. The LOCAL execution context (CVSS vector AV:L) means an attacker must have some foothold or ability to modify project files, but the scope is expanded (S:C) because the installation happens with the user's privileges, affecting the broader system.

Business impact

Development teams using Yeoman or tools built atop it face supply chain risk during project initialization. A compromised upstream repository, a trojanized fork on npm, or a subtly modified configuration file in a seemingly legitimate open-source project could silently install malicious packages. Since code execution occurs during CLI bootstrap—before typical code review—detection is difficult. This is particularly damaging for organizations relying on Yeoman-based generators for rapid project scaffolding, where developers may clone and initialize projects without careful inspection. The impact extends beyond individual developers to CI/CD pipelines that auto-generate or test projects, potentially compromising build infrastructure.

Affected systems

Yeoman Environment versions 2.9.0 through 6.0.0 are vulnerable. Any downstream application or tool that integrates Yeoman's API and exposes generator installation to external configuration (e.g., user-supplied project metadata, remote configuration files, or untrusted package.json data) is at risk. This includes custom scaffolding tools, monorepo generators, and internal CLI frameworks built on Yeoman. Version 6.0.0 and later are patched. Developers should verify their specific Yeoman Environment version and confirm whether their workflow allows attacker-controlled configuration to reach the installLocalGenerators() method.

Exploitability

Exploitability depends on the attack surface exposed by each downstream consumer. The vulnerability requires local file system access or the ability to inject malicious configuration (CWE-829), making it most dangerous in scenarios where: (1) a developer clones a public or shared repository with a booby-trapped config, (2) a CI/CD system processes user-submitted project definitions, or (3) an npm package squatting attack targets a common generator name. Once triggered, code execution is immediate and runs with the user's privileges. No special knowledge of Yeoman internals is required—simply crafting a project config with a malicious generator reference is sufficient. The user interaction requirement (CVSS UI:R) reflects the need for a developer to initiate the generator, not to approve installation.

Remediation

Upgrade Yeoman Environment to version 6.0.0 or later. For projects that depend on Yeoman transitively through other tools (e.g., Ember CLI, Angular Schematics, or custom generators), verify that the parent tool has likewise updated its Yeoman dependency. Review downstream tools and internal scaffolding frameworks for similar patterns: any code that auto-installs packages based on external configuration without explicit user consent should be audited and hardened. Consider adding configuration validation and user prompts before generator installation in custom tools that wrap Yeoman.

Patch guidance

Verify the patch version against official Yeoman Environment release notes and npm package registry. Version 6.0.0 includes the fix; confirm this through your dependency lock file (package-lock.json or yarn.lock). If upgrading to 6.0.0 introduces breaking changes for your organization, review the Yeoman changelog for migration guidance. For tools with pinned or ranged Yeoman dependencies, proactively update and test before rolling out to developers. Automated dependency scanning (e.g., npm audit, Dependabot) should flag this vulnerability; enable alerts and enforce updates in your development workflow.

Detection guidance

Monitor npm package installation logs and audit trails during project initialization. Look for unexpected package downloads from the generator namespace or unusual packages installed without explicit user requests. In CI/CD environments, log all npm install and generator bootstrap steps; correlate installer behavior with configuration file contents to spot divergence. Use Software Composition Analysis (SCA) tools to identify Yeoman Environment versions in your codebase and dependency tree. For tools built on Yeoman, validate configuration schemas and implement explicit approval steps before triggering generator installation. Consider sandboxing the generator initialization phase or using read-only file systems for untrusted project imports.

Why prioritize this

This is a HIGH severity vulnerability affecting the software supply chain at the point of project creation. While it requires local file system access, that barrier is low in collaborative development and CI/CD contexts. The lack of user confirmation makes it particularly insidious: developers expect scaffolding tools to be safe, yet a single malicious config file silently installs attacker code. Any organization using Yeoman or Yeoman-based generators (Ember, Angular, custom internal tools) should prioritize immediate patching, especially if they process external project configurations or allow developer-submitted scaffolding templates.

Risk score, explained

The CVSS 3.1 score of 8.6 (HIGH) reflects: (1) High confidentiality, integrity, and availability impact (C:H, I:H, A:H) due to arbitrary code execution, (2) Scope change (S:C) indicating the vulnerability can affect the system beyond the vulnerable component, (3) Local attack vector (AV:L) and no special privileges required (PR:N), but requiring user interaction (UI:R) to trigger the generator. The score appropriately captures the severity of silent code execution during a trusted development operation, balanced against the requirement for local access and user action to bootstrap a project.

Frequently asked questions