0xmrma/cve-2026-42089
Ein lokales Paketinstallationsprogramm vertraute vom Aufrufer gelieferten Paketnamen zu sehr. In yeoman-environment konnten fehlende Generatoren ohne Benutzerbestätigung installiert werden, wodurch vom Angreifer kontrollierte Projektmetadaten zu einem Paketinstallations- und Codeausführungspfad wurden.
Ein lokaler Paketinstallationshelfer vertraute zu sehr auf vom Aufrufer bereitgestellte Paketnamen. In yeoman-environment konnten fehlende Generatoren ohne Benutzerbestätigung installiert werden, wodurch vom Angreifer kontrollierte Projektmetadaten zu einem Paketinstallations- und Codeausführungspfad wurden.
Ich stieß auf dieses Problem, während ich generator-jhipster mit einer einfachen Sicherheitsfrage überprüfte:
Kann vom Angreifer kontrollierte Projektmetadaten ein Entwicklerwerkzeug dazu bringen, Drittanbieter-Code abzurufen und auszuführen, bevor der Benutzer explizit danach gefragt hat?
In diesem Fall lautete die Antwort ja.
Was zunächst wie ein JHipster-Problem aussah, entpuppte sich als tiefer liegende Ursache in yeoman-environment.
Das angreifbare Verhalten befand sich in Yeomans lokalem Generator-Installationsablauf, bei dem fehlende, vom Aufrufer bereitgestellte Pakete ohne Benutzerbestätigung automatisch installiert wurden. Bei einem nachgelagerten Verbraucher, der vom Angreifer kontrollierte Paketnamen in diesen Pfad einspeiste, reichte dies aus, um eine echte Paketinstallations- und Codeausführungskette zu erzeugen.
Dieses Problem wurde zu CVE-2026-42089.
yeoman-environment: yeoman-environment on GitHub
Package: yeoman-environment (npm)
CVE: CVE-2026-42089
Dies betraf yeoman-environment, die Laufzeitschicht hinter Yeomans Generator-Lade- und Bootstrap-Ablauf. Das offizielle Projekt beschreibt es als die Komponente, die den Generator-Lebenszyklus und die Erkennung verwaltet, und zum June 26, 2026 verzeichnete die npm-Paketseite 1,466,426 wöchentliche Downloads, was dies zu einem weit verbreiteten Paket im JavaScript-Tooling-Ökosystem macht.
vom Angreifer kontrollierte Projektkonfiguration -> vom Aufrufer bereitgestellte Generator-Paketnamen -> yeoman-environment installiert fehlende Pakete stillschweigend -> nachgelagertes Tool lädt installierten Generatorcode -> Paketinstallation und Codeausführung während des CLI-Bootstraps
yeoman-environment ist die Laufzeit- und Generator-Ladeschicht hinter Yeoman-basierten Werkzeugen.
Unter anderem übernimmt es:
Das bedeutet, dass es direkt auf einer Vertrauensgrenze sitzt.
Die relevante Frage ist nicht, ob Yeoman "nur ein lokales Werkzeug" ist.
Die relevante Frage ist, ob nicht vertrauenswürdige Eingaben das Paketinstallations- und Ladeverhalten beeinflussen können.
In diesem Fall war das möglich.
Ich suchte hier nicht nach Speicherkorruption oder reinen Absturzfehlern.
Das stärkere Ziel war die Erweiterungs- und Paketauflösungsoberfläche.
Jedes System, das:
verdient eine genaue Prüfung.
Das gilt besonders dann, wenn der nachgelagerte Verbraucher diese Paketnamen aus projektspezifischen Daten ableiten kann.
Genau das ist die Art von Stelle, an der gewöhnliche Konfiguration leise zu einer Sicherheitsgrenze werden kann.
Das war der richtige Ort zum Suchen.
Ich reproduzierte das Verhalten zunächst über generator-jhipster.
Der wichtige Pfad war:
.yo-rc.json deklariert ein Blueprint-PaketDas bedeutete, dass selbst ein harmloser Befehl wie:
jhipster --help
die Paketinstallation erreichen konnte, bevor der angeforderte Befehl abgeschlossen war.
Das ist ein echtes Vertrauensgrenzenversagen.
Der nachgelagerte Auslöser half, es aufzudecken, aber das unsichere Standardverhalten lag bei Yeoman.
Der Fehler war einfach.
In yeoman-environment war die angreifbare Methode:
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;
}
Diese Methode installierte vom Aufrufer bereitgestellte Paketnamen direkt über:
this.repository.install(specs)
ohne vorherige Rückfrage beim Benutzer.
Das ist die Kernschwachstelle.
Weil die Paketnamen nicht von einer vertrauenswürdigen Quelle stammen müssen.
Wenn ein nachgelagerter Verbraucher sie aus vom Angreifer kontrollierten Projektmetadaten ableitet, dann ist die Ausnutzungskette einfach:
Das ist nicht nur "Paketinstallation fand statt."
Das ist nicht vertrauenswürdige Eingabe, die ohne explizite Zustimmungsgrenze in eine Paketinstallationssenke gelangt.
Der wichtige Unterschied ist die stillschweigende Installation aus nicht vertrauenswürdiger Eingabe.
Es gibt einen echten Unterschied zwischen:
Diese Unterscheidung ist noch wichtiger, wenn das Paket unmittelbar danach ladbar wird.
Das Problem war nicht, dass Drittanbieter-Generatoren existieren.
Das Problem war, dass Yeoman vom Aufrufer bereitgestellte Paketnamen standardmäßig ohne Benutzerbestätigung als installierbar behandelte.
Das verschlimmert unsichere nachgelagerte Vertrauensannahmen erheblich.
Genau deshalb fügte der Fix ein Bestätigungsgate hinzu.
Ich verwendete zwei Beweisebenen, weil sie sowohl die Grundursache als auch die tatsächlichen nachgelagerten Auswirkungen demonstrierten.
Der erste Beweis verwendete unverändertes generator-jhipster.
Ich erstellte ein Projekt mit einer .yo-rc.json im Stammverzeichnis, die auf ein noch nicht installiertes Blueprint-Paket verwies, und führte dann aus:
jhipster --help
Das führte dazu, dass JHipster das fehlende Blueprint an Yeomans lokalen Generator-Installationsablauf übergab, bevor die Hilfe abgeschlossen war.
Das wichtige Ergebnis war:
Das stellte die tatsächliche Auslösebedingung klar fest.
Der zweite Beweis verwendete eine kontrollierte lokale Registry und ein Paket, das dazu entwickelt wurde, Importzeit-Seiteneffekte sicher zu demonstrieren.
Das war wichtig, weil ich die stärkere Geschichte zeigen wollte: