CVE-2026-42089

A local package installation helper trusted caller-supplied package names too much. In yeoman-environment, missing generators could be installed without user confirmation, turning attacker-controlled project metadata into a package-install and code-execution path.

Intro

I found this issue while reviewing generator-jhipster with a simple security question in mind:

Can attacker-controlled project metadata make a developer tool fetch and execute third-party code before the user explicitly asked for that?

In this case, the answer was yes.

What initially looked like a JHipster issue turned out to have a deeper upstream root cause in yeoman-environment.

The vulnerable behavior was in Yeoman's local generator installation flow, where missing packages supplied by the caller were installed automatically without user confirmation. In a downstream consumer that passed attacker-controlled package names into that path, that was enough to create a real package-installation and code-execution chain.

That issue became CVE-2026-42089.

yeoman-environment: yeoman-environment on GitHub
Package: yeoman-environment (npm)
CVE: CVE-2026-42089

This affected yeoman-environment, the runtime layer behind Yeoman’s generator-loading and bootstrapping flow. The official project describes it as the component that handles generator lifecycle and discovery, and as of June 26, 2026, the npm package page listed 1,466,426 weekly downloads, making this a widely deployed package in the JavaScript tooling ecosystem.

---

Attack Chain

attacker-controlled project config -> caller-supplied generator package names -> yeoman-environment silently installs missing packages -> downstream tool loads installed generator code -> package installation and code execution during CLI bootstrap

---

What yeoman-environment Does

yeoman-environment is the runtime and generator-loading layer behind Yeoman-based tooling.

Among other things, it handles:

• generator lookup
• local repository management
• package installation for missing generators
• registration and loading of generators

That means it sits directly on a trust boundary.

The relevant question is not whether Yeoman is "just a local tool."

The relevant question is whether untrusted input can influence package installation and code loading behavior.

In this case, it could.

---

Why This Surface Was Worth Looking At

I was not looking for memory corruption or crash-only bugs here.

The stronger target was the extension and package-resolution surface.

Any system that:

• accepts package names from another layer,
• installs them automatically,
• and then makes them available for loading

deserves close scrutiny.

That is especially true when the downstream consumer can derive those package names from project-local data.

This is exactly the kind of place where ordinary configuration can quietly become a security boundary.

That was the right place to look.

---

The Boundary I Focused On

I first reproduced the behavior through generator-jhipster.

The important path was:

• a project-local .yo-rc.json declares a blueprint package
• JHipster reads that blueprint entry during CLI bootstrap
• missing blueprint packages are passed into Yeoman's install path
• Yeoman installs them silently
• downstream logic then imports blueprint CLI modules

That meant even a benign command such as:

jhipster --help

could reach package installation before the requested command completed.

That is a real trust-boundary failure.

The downstream trigger helped expose it, but the unsafe default behavior was in Yeoman.

---

Root Cause

The bug was simple.

In yeoman-environment, the vulnerable method was:

async installLocalGenerators(packages) {
    const entries = Object.entries(packages);
    const specs = entries.map(([packageName, version]) => `${packageName}${version ? `@${version}` : ''}`);
    const installResult = await this.repository.install(specs);
    const failToInstall = installResult.find(result => !result.path);
    if (failToInstall) {
        throw new Error(`Fail to install ${failToInstall.pkgid}`);
    }
    await this.lookup({ packagePaths: installResult.map(result => result.path) });
    return true;
}

That method installed caller-supplied package names directly through:

this.repository.install(specs)

without prompting the user first.

That is the core vulnerability.

Why this is exploitable

Because the package names do not have to come from a trusted source.

If a downstream consumer derives them from attacker-controlled project metadata, then the exploit chain is straightforward:

• attacker controls package names indirectly
• the downstream tool passes them to Yeoman
• Yeoman installs them silently
• downstream code continues with the newly installed package available for loading

That is not just "package install happened."

That is untrusted input crossing into a package installation sink without an explicit consent boundary.

---

What Makes This a Security Issue, Not Just Tooling Behavior

The important distinction is silent installation from untrusted input.

There is a real difference between:

• a user explicitly deciding to install a package, and
• a framework silently installing a package because project-local data caused a caller to ask for it

That distinction matters even more when the package becomes loadable immediately afterward.

The issue was not that third-party generators exist.

The issue was that Yeoman treated caller-supplied package names as installable by default without user confirmation.

That makes unsafe downstream trust assumptions materially worse.

This is exactly why the fix added a confirmation gate.

---

PoC

I used two layers of proof because they demonstrated both root cause and real downstream impact.

PoC 1: stock downstream trigger

The first proof used unmodified generator-jhipster.

I created a project with a root .yo-rc.json that referenced a blueprint package which was not already installed, then ran:

jhipster --help

That caused JHipster to pass the missing blueprint into Yeoman's local generator installation flow before help completed.

The important result was:

• a harmless-looking command reached package resolution and installation behavior
• the project-local metadata was enough to trigger the install path

That established the real trigger condition clearly.

PoC 2: controlled package execution path

The second proof used a controlled local registry and a package designed to demonstrate import-time side effects safely.

That mattered because I wanted to show the stronger story:

• project-local metadata influences package selection
• Yeoman installs the package silently
• downstream logic loads installed blueprint CLI modules
• code execution becomes reachable during bootstrap

This was the strongest evidence chain because it moved the issue beyond:

"unexpected install attempt"

and into:

"install plus downstream code-loading path is actually reachable"

That is the point where the trust-boundary failure becomes much harder to dismiss.

---

Why the PoCs Were Chosen This Way

The first PoC proves the silent installation behavior.

The second PoC proves why that behavior matters.

That split was important.

A report that stops at:

"a package can be installed"

is weaker than a report that shows:

• attacker-controlled input reaches the install path
• the install happens without confirmation
• downstream logic makes code execution reachable

That is the complete story.

---

Affected Range