{“lastseen”:”2026-06-26T17:25:50″,”description”:”Yeoman Environment versions 2.9.0 through 6.0.0 have an issue where missing generators can be installed without user confirmation, turning attacker-controlled project metadata into a package-install and code-execution path…”,”published”:”2026-06-26T00:00:00″,”modified”:”2026-06-26T00:00:00″,”type”:”packetstorm”,”title”:”\ud83d\udcc4 Yeoman Environment 6.0.0 Code Execution”,”source”:””,”references”:””,”id”:”PACKETSTORM:224376″,”bulletinFamily”:”exploit”,”cwe”:null,”cvelist”:[“CVE-2026-42089″],”sourceData”:”# CVE-2026-42089\\n 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.\\n \\n ## Intro\\n \\n I found this issue while reviewing **generator-jhipster** with a simple security question in mind:\\n \\n **Can attacker-controlled project metadata make a developer tool fetch and execute third-party code before the user explicitly asked for that?**\\n \\n In this case, the answer was yes.\\n \\n What initially looked like a JHipster issue turned out to have a deeper upstream root cause in **yeoman-environment**.\\n \\n 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.\\n \\n That issue became **CVE-2026-42089**.\\n \\n **yeoman-environment:** [yeoman-environment on GitHub](https:\/\/github.com\/yeoman\/environment) \\n **Package:** `yeoman-environment` (npm) \\n **CVE:** CVE-2026-42089\\n \\n This affected **yeoman-environment**, the runtime layer behind Yeoman\u2019s 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.\\n \\n \\u003cimg width=\\”840\\” height=\\”560\\” alt=\\”photo0\\” src=\\”https:\/\/github.com\/user-attachments\/assets\/7bb6754e-d087-4669-833a-7466d71d4ea1\\” \/\\u003e\\n \\n —\\n \\n ## Attack Chain\\n \\n `attacker-controlled project config -\\u003e caller-supplied generator package names -\\u003e yeoman-environment silently installs missing packages -\\u003e downstream tool loads installed generator code -\\u003e package installation and code execution during CLI bootstrap`\\n \\n —\\n \\n ## What yeoman-environment Does\\n \\n **yeoman-environment** is the runtime and generator-loading layer behind Yeoman-based tooling.\\n \\n Among other things, it handles:\\n – generator lookup\\n – local repository management\\n – package installation for missing generators\\n – registration and loading of generators\\n \\n That means it sits directly on a trust boundary.\\n \\n The relevant question is not whether Yeoman is \\”just a local tool.\\”\\n \\n The relevant question is whether **untrusted input can influence package installation and code loading behavior**.\\n \\n In this case, it could.\\n \\n —\\n \\n ## Why This Surface Was Worth Looking At\\n \\n I was not looking for memory corruption or crash-only bugs here.\\n \\n The stronger target was the extension and package-resolution surface.\\n \\n Any system that:\\n – accepts package names from another layer,\\n – installs them automatically,\\n – and then makes them available for loading\\n \\n deserves close scrutiny.\\n \\n That is especially true when the downstream consumer can derive those package names from project-local data.\\n \\n This is exactly the kind of place where ordinary configuration can quietly become a security boundary.\\n \\n That was the right place to look.\\n \\n —\\n \\n ## The Boundary I Focused On\\n \\n I first reproduced the behavior through **generator-jhipster**.\\n \\n The important path was:\\n \\n – a project-local `.yo-rc.json` declares a blueprint package\\n – JHipster reads that blueprint entry during CLI bootstrap\\n – missing blueprint packages are passed into Yeoman’s install path\\n – Yeoman installs them silently\\n – downstream logic then imports blueprint CLI modules\\n \\n That meant even a benign command such as:\\n \\n “`bash\\n jhipster –help\\n “`\\n \\n could reach package installation before the requested command completed.\\n \\n That is a real trust-boundary failure.\\n \\n The downstream trigger helped expose it, but the unsafe default behavior was in Yeoman.\\n \\n —\\n \\n ## Root Cause\\n \\n The bug was simple.\\n \\n In `yeoman-environment`, the vulnerable method was:\\n \\n “`js\\n async installLocalGenerators(packages) {\\n const entries = Object.entries(packages);\\n const specs = entries.map(([packageName, version]) =\\u003e `${packageName}${version ? `@${version}` : ”}`);\\n const installResult = await this.repository.install(specs);\\n const failToInstall = installResult.find(result =\\u003e !result.path);\\n if (failToInstall) {\\n throw new Error(`Fail to install ${failToInstall.pkgid}`);\\n }\\n await this.lookup({ packagePaths: installResult.map(result =\\u003e result.path) });\\n return true;\\n }\\n “`\\n \\n That method installed caller-supplied package names directly through:\\n \\n “`js\\n this.repository.install(specs)\\n “`\\n \\n without prompting the user first.\\n \\n That is the core vulnerability.\\n \\n ### Why this is exploitable\\n \\n Because the package names do not have to come from a trusted source.\\n \\n If a downstream consumer derives them from attacker-controlled project metadata, then the exploit chain is straightforward:\\n \\n – attacker controls package names indirectly\\n – the downstream tool passes them to Yeoman\\n – Yeoman installs them silently\\n – downstream code continues with the newly installed package available for loading\\n \\n That is not just \\”package install happened.\\”\\n \\n That is untrusted input crossing into a package installation sink without an explicit consent boundary.\\n \\n —\\n \\n ## What Makes This a Security Issue, Not Just Tooling Behavior\\n \\n The important distinction is silent installation from untrusted input.\\n \\n There is a real difference between:\\n \\n – a user explicitly deciding to install a package, and\\n – a framework silently installing a package because project-local data caused a caller to ask for it\\n \\n That distinction matters even more when the package becomes loadable immediately afterward.\\n \\n The issue was not that third-party generators exist.\\n \\n The issue was that **Yeoman treated caller-supplied package names as installable by default without user confirmation**.\\n \\n That makes unsafe downstream trust assumptions materially worse.\\n \\n This is exactly why the fix added a confirmation gate.\\n \\n —\\n \\n ## PoC\\n \\n I used two layers of proof because they demonstrated both root cause and real downstream impact.\\n \\n ### PoC 1: stock downstream trigger\\n \\n The first proof used unmodified `generator-jhipster`.\\n \\n I created a project with a root `.yo-rc.json` that referenced a blueprint package which was not already installed, then ran:\\n \\n “`bash\\n jhipster –help\\n “`\\n \\n That caused JHipster to pass the missing blueprint into Yeoman’s local generator installation flow before help completed.\\n \\n The important result was:\\n – a harmless-looking command reached package resolution and installation behavior\\n – the project-local metadata was enough to trigger the install path\\n \\n That established the real trigger condition clearly.\\n \\n ### PoC 2: controlled package execution path\\n \\n The second proof used a controlled local registry and a package designed to demonstrate import-time side effects safely.\\n \\n That mattered because I wanted to show the stronger story:\\n \\n – project-local metadata influences package selection\\n – Yeoman installs the package silently\\n – downstream logic loads installed blueprint CLI modules\\n – code execution becomes reachable during bootstrap\\n \\n This was the strongest evidence chain because it moved the issue beyond:\\n \\n \\u003e \\”unexpected install attempt\\”\\n \\n and into:\\n \\n \\u003e \\”install plus downstream code-loading path is actually reachable\\”\\n \\n That is the point where the trust-boundary failure becomes much harder to dismiss.\\n \\n —\\n \\n ## Why the PoCs Were Chosen This Way\\n \\n The first PoC proves the silent installation behavior.\\n \\n The second PoC proves why that behavior matters.\\n \\n That split was important.\\n \\n A report that stops at:\\n \\n \\u003e \\”a package can be installed\\”\\n \\n is weaker than a report that shows:\\n \\n – attacker-controlled input reaches the install path\\n – the install happens without confirmation\\n – downstream logic makes code execution reachable\\n \\n That is the complete story.\\n \\n —\\n \\n ## Affected Range\\n \\n During advisory handling and local review, the behavior was traced back to the introduction of `installLocalGenerators()` in:\\n \\n “`text\\n yeoman-environment 2.9.0\\n “`\\n \\n The affected range was therefore:\\n \\n “`text\\n \\u003e= 2.9.0 and \\u003c 6.0.1\\n “`\\n \\n The fixed version was:\\n \\n “`text\\n 6.0.1\\n “`\\n \\n —\\n \\n ## Fix Analysis\\n \\n The fix was correct and minimal.\\n \\n In `6.0.1`, `installLocalGenerators()` was changed to add a confirmation step before installation unless force-install is explicitly requested.\\n \\n The fixed shape looked like this:\\n \\n “`js\\n async installLocalGenerators(packages, forceInstall = false) {\\n “`\\n \\n and then:\\n \\n “`js\\n const { aproveInstall } = await this.adapter.prompt({\\n message: `The following packages need to be installed in the local repository: ${specs.join(‘, ‘)}. Do you want to proceed?`,\\n type: ‘confirm’,\\n name: ‘aproveInstall’,\\n default: false,\\n });\\n “`\\n \\n If the user declines, installation is aborted.\\n \\n That is the right fix because it restores the missing trust boundary:\\n \\n – caller-supplied package names are no longer silently installed by default\\n – explicit user approval is required\\n – downstream tools can no longer rely on accidental implicit trust\\n \\n This fix landed in:\\n \\n “`text\\n 78d2af7\\n “`\\n \\n through:\\n \\n “`text\\n PR #753\\n “`\\n \\n That is exactly the kind of remediation you want in a security issue like this:\\n \\n – small\\n – direct\\n – easy to reason about\\n – tied to the vulnerable sink itself\\n \\n —\\n \\n ## Severity and Classification\\n \\n This issue was reasonably taken seriously because the impact is more than cosmetic or surprising behavior.\\n \\n The vulnerable behavior can lead to:\\n – attacker-selected package installation\\n – network access to package infrastructure from benign command paths\\n – downstream code-loading reachability\\n – compromise of the developer environment in affected consumers\\n \\n The CVSS vector associated with the issue was:\\n \\n “`text\\n CVSS:3.1\/AV:L\/AC:L\/PR:N\/UI:R\/S:C\/C:H\/I:H\/A:H\\n “`\\n \\n That makes sense for the downstream exploit story:\\n – local execution context\\n – low complexity\\n – no prior privileges required\\n – user interaction required\\n – strong confidentiality, integrity, and availability impact once the package execution path is reached\\n \\n —\\n \\n ## Disclosure\\n \\n This issue started as a private report against **generator-jhipster**, because that was the real-world trigger path I initially validated.\\n \\n During triage, the JHipster maintainers pointed out that the auto-install behavior itself was in **yeoman-environment** and referenced the upstream fix.\\n \\n That led to the correct pivot:\\n \\n – narrow the root cause to Yeoman\\n – treat JHipster as a downstream affected consumer\\n – report the upstream issue privately\\n \\n The Yeoman maintainers reviewed the issue, confirmed the affected range, and tracked it through a private advisory.\\n \\n The report was later assigned:\\n \\n **CVE-2026-42089**\\n \\n That advisory also documented the real downstream trigger path through `generator-jhipster`.\\n \\n This was a good example of why coordinated disclosure sometimes needs one extra step:\\n \\n – first identify the practical trigger\\n – then identify the true ownership boundary\\n \\n Here, the downstream reproduction was useful, but the upstream package was the right place for the CVE.\\n \\n —\\n \\n ## What This Bug Actually Teaches\\n \\n The key lesson here is simple:\\n \\n \\u003e package installation is a security boundary, even in local developer tooling\\n \\n A lot of people instinctively downgrade issues like this because they happen in CLI tools.\\n \\n That is a mistake.\\n \\n The real question is not whether the tool is local.\\n \\n The real question is:\\n \\n **Can untrusted input make the tool fetch and trust code without an explicit user decision?**\\n \\n In this case, yes.\\n \\n That is the real takeaway.\\n \\n This issue also reinforces something important about good vulnerability research:\\n \\n – the first product you reproduce on is not always the true root cause owner\\n – downstream PoCs are often what make the risk obvious\\n – upstream trust-boundary mistakes are where the actual fix belongs\\n \\n That was exactly the shape of this CVE.\\n \\n —\\n \\n ## Key Points\\n \\n – package-install helpers are security boundaries\\n – caller-supplied package names should not be silently installed by default\\n – local project metadata can become dangerous when it influences extension loading\\n – the downstream reproduction in generator-jhipster exposed the issue clearly\\n – the root cause still belonged to yeoman-environment\\n – adding an explicit confirmation gate was the correct fix\\n \\n —\\n \\n ## Final Words\\n \\n This vulnerability was not about a flashy payload.\\n \\n It was about asking the right trust-boundary question.\\n \\n A downstream tool let project-local data influence package selection.\\n Yeoman installed the missing package without confirmation.\\n The rest of the code-loading chain did the rest.\\n \\n That is why this became **CVE-2026-42089**.\\n \\n Fixed in **yeoman-environment 6.0.1**.”,”sourceHref”:”https:\/\/packetstorm.news\/download\/224376″,”cvss”:{“score”:8.6,”severity”:”HIGH”,”vector”:”CVSS:3.1\/AV:L\/AC:L\/PR:N\/UI:R\/S:C\/C:H\/I:H\/A:H”,”version”:”3.1″},”cvss2″:{},”cvss3″:{“version”:””,”vectorString”:””,”baseScore”:0,”baseSeverity”:””,”attackVector”:””,”attackComplexity”:””,”privilegesRequired”:””,”userInteraction”:””,”scope”:””,”confidentialityImpact”:””,”integrityImpact”:””,”availabilityImpact”:””,”cvssV3″:{“version”:””,”vectorString”:””,”baseScore”:0,”baseSeverity”:””,”attackVector”:””,”attackComplexity”:””,”privilegesRequired”:””,”userInteraction”:””,”scope”:””,”confidentialityImpact”:””,”integrityImpact”:””,”availabilityImpact”:””}},”href”:”https:\/\/packetstorm.news\/files\/id\/224376\/”,”category_name”:”Exploit”,”post_link”:””,”product”:””,”version”:””,”vendor”:””,”ai_description”:””,”ai_severity”:””,”ai_vendor”:””,”ai_product”:””,”ai_version”:””,”ai_score”:0}<\/p>\n","protected":false},"excerpt":{"rendered":"
{“lastseen”:”2026-06-26T17:25:50″,”description”:”Yeoman Environment versions 2.9.0 through 6.0.0 have an issue where missing generators can be installed without user confirmation, turning attacker-controlled project metadata into a package-install…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[6,8,81,12,15,13,53,7,11,5],"class_list":["post-66261","post","type-post","status-publish","format-standard","hentry","category-category_exploit","tag-cve","tag-cvss","tag-cvss-86","tag-exploit","tag-high","tag-news","tag-packetstorm","tag-security","tag-tapic","tag-vulnerability"],"yoast_head":"\n