vpmdhaj-Typosquat-Welle: 14 maliziose npm-Pakete in vier Stunden, AWS- und Vault-Tokens als Beute — warum --ignore-scripts ab heute ein Standard-Reflex ist
29. Mai 2026. Microsoft Threat Intelligence hat gestern eine aktive npm-Lieferketten-Kampagne offengelegt: ein Akteur unter dem frisch erstellten Maintainer-Alias vpmdhaj hat in einem Vier-Stunden-Fenster am 28. Mai 14 maliziose Pakete publiziert, die OpenSearch-, ElasticSearch-, DevOps- und Environment-Config-Bibliotheken typosquatten und im repository.url-Feld bewusst auf das offizielle OpenSearch-GitHub-Repo zeigen — als Beispiele nennt Microsoft opensearch-setup und elastic-opensearch-helper; die vollständige Paket-Liste hat Microsoft zurückgehalten, um Imitations-Wellen zu vermeiden. Der Schadcode läuft über preinstall-Lifecycle-Hooks in zwei Stager-Varianten (Gen-1 mit preinstall.js/index.js, Gen-2 mit setup.mjs) und greift AWS-Credentials, HashiCorp-Vault-Tokens und CI/CD-Pipeline-Secrets vom Host ab. Methodisch sitzt der Befund neben der TanStack-/Nx-Console-Linie der letzten zwei Wochen: keine kompromittierte Maintainer-Identität, sondern eine frische Alias-Identität mit visueller Tarnkappe. Für den Mittelstand ist die Reflex-Frage drei Schritte lang: läuft --ignore-scripts per Default, sind die Token-Rotations-Pfade bekannt, sind die SBOM-Strict-Modi auf neue Maintainer-Identitäten konfiguriert.

TL;DR — die 90-Sekunden-Zusammenfassung
- Was wurde veröffentlicht?
Microsoft-Threat-Intelligence-Befund vom 28.05.2026: ein einzelner Akteur unter dem Maintainer-Alias
vpmdhajpubliziert in einem Vier-Stunden-Fenster 14 maliziose npm-Pakete, die OpenSearch-, ElasticSearch-, DevOps- und Environment-Config-Bibliotheken typosquatten. Beispiele:opensearch-setup,elastic-opensearch-helper— Paket-Namen, die in einem hektischen Setup-Flow oder einem flüchtigen Copy-Paste aus einer Anleitung nicht als Typosquat auffallen. Dasrepository.url-Feld im jeweiligenpackage.jsonzeigt auf die offizielleopensearch-project/opensearch-GitHub-Adresse — eine visuelle Tarnkappe, die einen oberflächlichen Audit auf den Repository-Link bestehen würde.- Wie schwer?
Hoch auf der Credential-Klasse. Die Payload läuft über den
preinstall-Lifecycle-Hook, also automatisch bei jedemnpm install— ohne Entwickler-Interaktion und ohne dass das Paket im Application-Code importiert sein muss. Microsoft beschreibt zwei Stager-Varianten: Gen-1 (≤ 1.0.7265) ruftpreinstall.js/index.jsaus den drei Hooks install/preinstall/postinstall, Gen-2 (≥ 1.0.7266) lädtsetup.mjsals leisere Variante nur überpreinstallnach. Beuteklasse laut Microsoft: AWS-Credentials (IAM/STS), HashiCorp-Vault-Tokens und CI/CD-Pipeline-Secrets aus der Host-Umgebung. Microsoft nennt die genauen Auslese-Pfade nicht; in der Wellen-Praxis (TanStack/@antv-Vergleich) sind die kanonischen Quellen~/.aws/credentials+ EC2-Instance-Metadata-Service,VAULT_TOKEN-Env,~/.npmrc-_authToken, GitHub-Actions-OIDC.- Bin ich als Moselwal-Kunde betroffen?
Moselwal-eigene Pipelines ziehen die maliziosen Pakete nicht — wir betreiben keinen OpenSearch-/ElasticSearch-Stack in den Standard-Plattformen. Direkt betroffen sind Sie, wenn auf einer Ihrer Plattformen oder in einem Ihrer CI/CD-Runner ein npm-Workspace lebt, der OpenSearch- oder ElasticSearch-Pakete als Dependency führt — typisch bei Custom-Search-Integrationen, Logging-Pipelines (z. B. Symfony-Apps mit OpenSearch-Backend statt MySQL-Fulltext), Frontend-Komponenten mit OpenSearch-Dashboards. Indirekt trifft Sie der Befund über jeden CI/CD-Runner, der seit dem 28.05.-Fenster
npm installausgelöst hat und den Lifecycle-Hook nicht deaktiviert betreibt.- Sofort-Mitigation?
Drei Schritte. Erstens,
npm config set ignore-scripts trueglobal setzen (analog pnpm und yarn) und in den CI/CD-Runnern erzwingen. Zweitens, Lockfile-Audit: über allepackage-lock.json- undpnpm-lock.yaml-Dateien grep auf die zwei von Microsoft genannten Paketnamen plus eine zweite Suche über allepackage.json-Verweise mitrepository.url=opensearch-project/opensearchund Publish-Datum 2026-05-28. Falls Treffer: sofortige Token-Rotation der AWS-IAM/STS-Schlüssel, Vault-Tokens, npm-Publish-Tokens und GitHub-Actions-Tokens. Drittens, SBOM- und Audit-Pipeline auf neue Maintainer-Identitäten konfigurieren: ein Maintainer mit Account-Alter <30 Tage und einem einzigen oder wenigen veröffentlichten Paketen ist ab heute ein Audit-Trigger.- Kritikalität?
Siehe Hero-Badge
high— handeln im 48h-Fenster, weil aktive Ausnutzung im Microsoft-Befund dokumentiert ist und die Lifecycle-Hook-Auto-Ausführung die Eintrittsschwelle effektiv aufhebt.
Was ist passiert
Microsoft Threat Intelligence hat am 28. Mai 2026 eine aktive npm-Lieferketten-Kampagne dokumentiert. Ein einzelner Threat-Actor unter dem frisch erstellten Maintainer-Alias vpmdhaj hat in einem Vier-Stunden-Fenster 14 maliziose Pakete in das npm-Registry hochgeladen. Die Paketnamen typosquatten OpenSearch-, ElasticSearch-, allgemeine DevOps- und Environment-Config-Bibliotheken; konkret nennt Microsoft opensearch-setup und elastic-opensearch-helper als Beispiele. Die package.json-Metadaten zeigen im repository.url-Feld bewusst auf die offizielle GitHub-Adresse des OpenSearch-Projekts (github.com/opensearch-project/opensearch) — eine visuelle Tarnkappe, die einen schnellen Sicht-Audit auf den Repository-Link bestehen würde.
Der Schadcode läuft über den preinstall-Lifecycle-Hook. Das ist der npm-eingebauten Mechanismus, der Skripte aus dem Paket automatisch ausführt, bevor das Paket installiert wird — also auch dann, wenn das Paket nie im Application-Code importiert wird. Sobald ein Entwickler oder ein CI/CD-Runner npm install ausführt und das maliziose Paket in der Dependency-Resolution landet (typischerweise als transitive Dependency oder durch einen Tippfehler im manuellen npm install <name>-Aufruf), startet die Payload ohne weitere Interaktion. Microsoft hat zwei Stager-Varianten dokumentiert: Gen-1 in Paket-Versionen ≤ 1.0.7265 ruft preinstall.js bzw. index.js aus den drei Hooks install, preinstall und postinstall parallel; Gen-2 in Versionen ≥ 1.0.7266 verwendet einen einzelnen preinstall-Hook, der setup.mjs als neueren, leiseren Loader nachführt.
Die Payload zielt laut Microsoft-Bericht auf AWS-Credentials (IAM/STS), HashiCorp-Vault-Tokens und CI/CD-Pipeline-Secrets aus der Host-Umgebung. Konkrete Auslese-Pfade nennt Microsoft im veröffentlichten Blog-Post nicht im Detail; aus der Klasse „CI/CD-Pipeline-Secrets“ und den üblichen Stealer-Patterns dieser Welle (TanStack, Mini-Shai-Hulud-@antv) lassen sich die kanonischen Quellen als typischen Schnitt skizzieren: AWS-Standard-Profile (~/.aws/credentials, EC2-Instance-Metadata-Service), VAULT_TOKEN-Env oder ~/.vault-token-Datei, _authToken-Eintrag in ~/.npmrc, GitHub-Actions-OIDC über ACTIONS_ID_TOKEN_REQUEST_TOKEN. Diese Liste ist als generische Klassen-Aufzählung zu lesen, nicht als verifizierter Vektor-Katalog des konkreten Stealer-Programms.
Microsoft hat die Pakete dem npm-Security-Team gemeldet. Die vollständige Liste der vierzehn Paketnamen hat Microsoft im Blog-Post zurückgehalten, um weitere Imitations-Wellen zu vermeiden; als Beispiele werden opensearch-setup und elastic-opensearch-helper genannt. Die Frage „wer hat in den vier Stunden installiert“ bleibt für jede betroffene Organisation einzeln zu klären — npm hat zu Download-Counts in dem Fenster keine öffentlichen Zahlen veröffentlicht.
Technische Einordnung
Strukturell zeichnet die vpmdhaj-Welle eine andere Klasse als die TanStack-Welle (11.05.) oder die Nx-Console-Welle (18.05.). TanStack und Nx-Console waren Kompromittierungen etablierter Maintainer-Identitäten — TeamPCP hat über „Pwn Request“-Pull-Request-Target-Pattern, GitHub-Actions-Cache-Poisoning und OIDC-Token-Extraktion existierende Maintainer-Tokens übernommen und damit unter etablierten Paketnamen publiziert. Die vpmdhaj-Welle nutzt einen frisch erstellten Maintainer-Alias mit visueller Tarnkappe — die repository.url zeigt auf das offizielle OpenSearch-Repo, der Paketname klingt plausibel im Setup-Flow, der Lifecycle-Hook läuft beim ersten npm install an.
Methodisch ist das die nächste Eskalations-Stufe in einem npm-Bedrohungs-Spektrum, das jetzt zwei klar getrennte Klassen kennt. Klasse A: Maintainer-Identitäts-Kompromittierung mit Veröffentlichung unter etablierten Namen (TanStack, Nx-Console). Klasse B: frische Alias-Identität mit Typosquat-Tarnkappe und Lifecycle-Hook-Trigger (vpmdhaj). Beide Klassen brauchen jeweils eigene Detektions-Patterns. Klasse A lässt sich mit Lockfile-Diff-Audits und Maintainer-Wechsel-Alerting erkennen — wenn ein Paket plötzlich neue Maintainer im maintainers-Feld bekommt, ist das ein Trigger. Klasse B lässt sich nicht erkennen, weil das Paket nie in einer Lockfile war — der Trigger ist der erste npm install <name>-Aufruf, der den Paketnamen überhaupt erst einbringt.
Die zwei generalisierbaren Lehren. Erstens, --ignore-scripts als Default ist ab heute keine paranoide Konfiguration mehr, sondern eine vernünftige Grundeinstellung — die Lifecycle-Hook-Auto-Ausführung ist die zentrale Eintritts-Schwelle für Klasse-B-Angriffe, und sie zu deaktivieren kostet nur den Komfort von postinstall-Build-Schritten in legitimer Software (die sich ueberall, wo sie wirklich gebraucht werden, explizit per npm install <pkg> --foreground-scripts einschalten lassen). Zweitens, SBOM-Audit-Pipelines müssen das Maintainer-Account-Alter als eigene Risiko-Achse einbeziehen — ein Maintainer mit Account-Alter unter 30 Tagen und ein bis drei veröffentlichten Paketen ist ein Audit-Trigger, nicht ein Default-Trust. Tools wie socket-security, snyk advisor und npm audit signatures exportieren diese Metadaten bereits; die Reflex-Schwelle in der eigenen Pipeline zu setzen ist eine Konfigurations-Frage.
Bedeutung für den Mittelstand
Moselwal-eigene Pipelines führen die genannten Paketnamen nicht — wir betreiben keine OpenSearch-/ElasticSearch-Stacks in den Standard-TYPO3-/Sylius-Plattformen, und unsere package-lock.json-Dateien haben in der Stichprobe vom 29.05. keinen Treffer auf die zwei von Microsoft öffentlich genannten Paketnamen. Bei einem Teil unserer Kundschaft sitzt das Suchstack-Bild aber sehr wohl im Plattform-Stack: in Sylius-Storefronts mit OpenSearch-Backend statt MySQL-Fulltext (Performance-Anforderungen >100k Produkte), in Symfony-Plattformen mit ElasticSearch-Backend für Logging-Aggregation (Stack-Variante mit friendsofsymfony/elastica-bundle), in Drupal-Sites mit search_api_elasticsearch oder search_api_opensearch, in Custom-Frontends mit OpenSearch-Dashboards-Komponenten. Überall dort, wo ein Frontend- oder Build-Team JavaScript-Pakete für OpenSearch-Integration nachzieht, ist die vpmdhaj-Klasse im Eintritts-Pfad.
Die operative Pointe sitzt im CI/CD-Runner. Ein einzelner npm install auf einem GitHub-Actions-Runner reicht aus, um GitHub-Actions-OIDC-Tokens, AWS-Credentials (wenn der Runner mit AWS-Provider konfiguriert ist) und npm-Publish-Tokens an einen externen Endpoint zu exfiltrieren. Die Folge-Welle ist dann nicht die Pipeline selbst, sondern was an die Pipeline-Identität hängt: Push-Rechte in das Plattform-Repository, Container-Registry-Push-Rechte, Deployment-Rollout-Identitäten. Wer in seiner Pipeline OIDC-Federation gegen AWS oder Azure betreibt, hat damit eine Cloud-Identität abgegeben — und der Sprung von „Pipeline-Token gestohlen“ auf „Production-Cloud-Konto kompromittiert“ ist trivial, weil OIDC-Federation in den meisten Setups Workload-Identität auf Cloud-Identität abbildet.
Compliance-seitig wirkt der Befund auf den Standard-Achsen. DSGVO Art. 32 trifft jede Plattform, deren Pipeline Personendaten verarbeitet — Customer-Datenbestände in Migrations-Pipelines, Test-Datasets mit Echt-Daten-Sample. NIS-2 Art. 21 fordert Lieferketten-Disziplin in der erweiterten Definition; npm-Pakete sind unbestritten Lieferketten-Komponente, und ein SBOM, der das Maintainer-Account-Alter nicht abbildet, führt das Inventar nicht vollständig. Für DORA-Pflichtige und MaRisk-Häuser sitzt jede npm-Lifecycle-Hook-Ausführung im Drittparteien-Risiko-Inventar.
Bedeutung für die technische Entwicklung
Methodisch zwingt die vpmdhaj-Welle zu einer Hardening-Konvention auf der Pipeline-Ebene, die seit Jahren empfohlen, aber selten erzwungen wurde. npm config set ignore-scripts true als globale CI/CD-Runner-Konfiguration plus die .npmrc-Variante (ignore-scripts=true) im Repository ist die saubere Linie. Wer Build-Schritte aus postinstall-Hooks braucht (z. B. husky für Git-Hooks, puppeteer für Chromium-Download), ruft sie explizit nach dem npm install als eigenen Skript-Schritt auf — das macht die Build-Pipeline um eine Zeile länger und legt die unsichtbaren Build-Schritte als sichtbare Pipeline-Stufen offen.
Architektonisch ist die zweite Lehre die Token-Rotations-Disziplin. AWS-IAM-Keys, Vault-Tokens, npm-Publish-Tokens und GitHub-Actions-OIDC-Tokens müssen rotierbar sein, ohne dass die Pipeline anschließend manuell nachgezogen werden muss — das geht über Rotation-Workflows in AWS Secrets Manager, Vault-Renewal, npm-Granular-Access-Tokens mit kurzen Laufzeiten, GitHub-Federated-OIDC ohne langlebige Secrets. Wer diese Disziplin nicht hat, hat im Vorfalls-Fall ein Wartungsfenster von Tagen, wo Stunden nötig wären.
Drittens, SBOM-Pipelines müssen Maintainer-Metadaten exportieren. Cyclone DX 1.5 hat das component.authors-Feld, das Maintainer-Identität abbildet; cyclonedx-bom-für-npm zieht es per Default. Die nächste Schicht ist die Audit-Pipeline, die das Maintainer-Account-Alter, die Anzahl veröffentlichter Pakete und die Maintainer-Konstanz pro Paket als Risiko-Score aufnimmt. Open-Source-Werkzeuge wie socket-security, snyk advisor und dependency-track bieten dafür Auswertungs-Hooks; die Disziplin sitzt in der Konfiguration der Strict-Modi.
Konkrete Handlungsempfehlung
In dieser Reihenfolge. Erstens, npm config set ignore-scripts true global auf allen Entwickler-Maschinen und CI/CD-Runnern setzen; .npmrc im Repository mit ignore-scripts=true versehen; pnpm- und yarn-Äquivalente konfigurieren (pnpm config set side-effects-cache false, yarn config set enableScripts false). Zweitens, Lockfile-Audit über alle Projekte: grep -r "opensearch-setup\|elastic-opensearch-helper" package-lock.json pnpm-lock.yaml yarn.lock als Erst-Sweep. Microsoft hält die vollständige Liste der vierzehn Paketnamen im Blog-Post bewusst zurück, um Imitations-Wellen zu vermeiden — die generischere Suche nach Maintainer-Alias und Veröffentlichungs-Fenster (alle package.json-Verweise mit "repository.url": "https://github.com/opensearch-project/opensearch" und Publish-Datum 2026-05-28) fängt die zweite Indikator-Klasse ab. Wer Zugang zu einem npm-Audit-Service mit Threat-Intelligence-Feed hat (socket-security, snyk advisor, npm audit signatures), zieht dort die Microsoft-Indikatoren in den Audit-Lauf.
Drittens, für jeden Treffer: sofortige Token-Rotation der auf dem betroffenen Runner eingerichteten AWS-IAM-/STS-Schlüssel, HashiCorp-Vault-Tokens, npm-Publish-Tokens und GitHub-Actions-Tokens; Audit-Sweep der CI/CD-Logs auf ungewöhnliche Push-/Release-/Deployment-Aktivität seit dem 28.05.-Vier-Stunden-Fenster. Viertens, SBOM- und Audit-Pipeline-Konfiguration: Maintainer-Account-Alter <30 Tage und Anzahl publizierter Pakete <5 als Audit-Trigger setzen — Tools wie socket-security und snyk advisor bieten diese Filter direkt. Fünftens, dokumentieren Sie die Lifecycle-Hook-Disziplin und die Token-Rotations-Pfade im Plattform-Runbook. Wenn diese Schritte aus eigener Kraft nicht laufen, sprechen Sie mit uns: Moselwal richtet npm-/Composer-Pipelines, in denen --ignore-scripts-Default, Token-Rotation und SBOM-Maintainer-Audit Pflicht-Konfigurationen sind.
Dieser Beitrag spiegelt unsere technische und strategische Einschätzung. Er ersetzt keine Rechtsberatung und keine Datenschutz-Folgenabschätzung.
Quellen
- Microsoft Security Blog — Typosquatted npm packages used to steal cloud and CI/CD secrets (28.05.2026)
- Microsoft Threat Intelligence on X — vpmdhaj-Befund (28.05.2026)
- GBHackers — Typosquatted npm Packages Steal Cloud and CI/CD Secrets (28.05.2026)
- Palo Alto Unit 42 — The npm Threat Landscape (Updated 21.05.2026)

