TL; DR
Am 14. September 2025 identifizierten Forscher Shai Hulud, ein sich selbst replizierender Wurm, der im Inneren versteckt ist npm-Pakete, wodurch aus einer routinemäßigen Abhängigkeitsaktualisierung eine umfassende Supply-Chain-Angriff. Zuerst entdeckt in der @Strg/Tinycolor Mit dem Paket von Daniel dos Santos Pereira sammelt Shai-Hulud Geheimnisse, exfiltriert sie über GitHub-Repos und Workflows und veröffentlicht sich mit gestohlenen Anmeldeinformationen erneut im Register. Innerhalb weniger Tage stieg die Zahl der infizierten Pakete von Dutzenden auf Hunderte, was bestätigt, dass Shaihulud ist nicht nur ein weiterer Trojaner, sondern ein Wurm, der sich automatisch im npm-Ökosystem verbreitet.
Auswirkungen: Jeder Entwickler oder CI-Runner, der öffentliche npm-Pakete installiert, ist gefährdet.
Sofortmaßnahmen: Blockieren Sie bekannte Versionen, wechseln Sie zu Nur-Lockfile-Installationen, rotieren Sie NPM- und GitHub-Token, prüfen Sie Workflows und überwachen Sie auf Indikatoren für Kompromittierung (IoCs).
Was passiert?
Die Shai-Hulud-Lieferkettenangriff in npm-Paketen ist einer der verheerendsten Vorfälle der letzten Zeit. Im Gegensatz zu isolierten Trojanern vermischt dieser Wurm Diebstahl von Anmeldeinformationen, automatisierte Exfiltration und SelbstreplikationInfolgedessen verkürzte sich die Zeitspanne bis zur Infektion von Wochen auf nur wenige Stunden.
Für DevOps-Teams ist die Lektion klar: Wenn jede Installation Code ausführen kann, dann ist jedes Abhängigkeitsupdate eine potenzielle Schwachstelle.
Möglicher anfänglicher Vektor und gezielte Anmeldeinformationen
Frühe Analyse deutet darauf hin, dass der Angriff wahrscheinlich mit gestohlene Ausweise. Beispielsweise Phishing-Kampagnen, die npm fälschen login oder MFA-Eingabeaufforderungen haben möglicherweise Entwickler-Token abgefangen. Nachdem die Angreifer diesen ersten Angriffspunkt erreicht hatten, verbreitete sich der Wurm, indem er sich in npm-Pakete einbettete und weitere Geheimnisse stahl von:
- npm-Konfigurationsdateien Google Trends, Amazons Bestseller
.npmrc, die häufig Veröffentlichungstoken enthalten. - Umgebungsvariablen und Konfigurationen mit GitHub PATs und CI/CD Geheimnisse.
- Cloud-Metadaten-Endpunkte (AWS, GCP, Azure) und liefert kurzlebige Anmeldeinformationen für die laterale Bewegung.
Daher wurde der Diebstahl von Anmeldeinformationen zum Ausgangspunkt. Mit gültigen npm-Token und GitHub-Geheimnissen konnte sich Shai-Hulud ohne zusätzlichen menschlichen Aufwand über mehrere Pakete und Repositories hinweg selbst replizieren.
Auswirkungen des Shai-Hulud-Angriffs auf die Lieferkette auf die Führungsebene
Shai-Hulud ist noch heute aktiv. Dieser Wurm beschleunigt die Wirkungszeit. Was früher mit einem Trojaner Wochen dauerte, entfaltet sich heute in Stunden. Infolgedessen Die Ausbreitung erfolgt schneller und ist schwerer einzudämmen. Es wird vorangetrieben durch:
- Diebstahl von NPM-Veröffentlichungstoken und GitHub-Geheimnissen.
- Veröffentlichen Sie sich selbst erneut in anderen npm-Paketen.
- Hinzufügen bösartiger GitHub Actions-Workflows zur Persistenz.
Wer ist betroffen:
Jedes Team, das öffentliche NPM-Pakete installiert, ist gefährdet. Darüber hinaus sind Entwickler mit zwischengespeicherten NPM- oder GitHub-Token einem hohen Risiko ausgesetzt. CI-Runner, die weitreichende Geheimnisse verwenden, sind ebenfalls anfällig.
Geschäftsrisiko
Die geschäftlichen Auswirkungen nehmen schnell zu. Gestohlene Token können zu Kontoübernahmen, Paketentführungen und sogar Cloud-Missbrauch führen. Darüber hinaus erschwert die Persistenz in GitHub-Workflows die Bereinigung. Dahermüssen die Teams Shai-Hulud als einen andauernden Vorfall behandeln, nicht als einen abgeschlossenen.
Wie der Shai-Hulud-Lieferkettenangriff in npm-Paketen funktioniert
Ziele und Motive des Angreifers
Die Kampagne optimiert drei Dinge:
- Das erste Ziel besteht darin, Anmeldeinformationen in großem Umfang stehlen von Entwickler-Laptops und CI-Runnern. Dazu gehören NPM-Publish-Token, GitHub-Token und Cloud-Anmeldeinformationen. Tatsächlich bestätigen mehrere Analysen das systematische Sammeln von Geheimnissen, beispielsweise durch die Ausführung von TruffleHog und die Abfrage von Cloud-Metadaten-Endpunkten.
- Das zweite Ziel besteht darin, automatisch verbreiten durch Missbrauch der Veröffentlichungsrechte kompromittierter Paketbetreuer. Dadurch werden aus einem Angriffspunkt schnell viele weitere, da ohne zusätzliche menschliche Anstrengung neue infizierte Versionen anderer Pakete auftauchen.
- Das dritte Ziel besteht darin, bestehen bleiben und zuverlässig exfiltrieren über die GitHub-Infrastruktur. Angreifer erstellen ein öffentliches Repo namens „Shai-Hulud“ mit einem doppelten Base64 data.json, und zusätzlich installieren sie einen Workflow, der serialisiert ${{ toJSON(Geheimnisse) }} und postet es an einen statischen Webhook.
Der wahrscheinliche Vorteil umfasst einen dauerhaften Zugriff auf Register und Quellcode, einen schnellen lateralen Wechsel in Cloud-Konten und die Möglichkeit, die Lieferkette weiter zu mobilisieren. Öffentliche Berichte zeigen, dass private Repos mit einem "-Migration" Suffix, das die Datenpräsenz und Dynamik erhöht
Im Inneren der Shai-Hulud-Nutzlast: Bundle.js in npm-Paketen
Shai-Hulud-Schiffe als groß, Webpack-gebündelt und stark minimiert JavaScript-Datei (Bundle.js, ca. 3–3.7 MB) das von einem Nachinstallation einhaken paket.jsonFolglich, Jede Installation löst die Nutzlast automatisch aus. Dieses Design verbirgt Kennungen, komprimiert den Kontrollfluss und verlagert die gesamte Logik in ein einziges Artefakt, das während der Installation ausgeführt wird. Analysten bestätigen immer wieder Webpack-Bündelung, ungewöhnliche Dateigrößen und Ausführung während der Installation.
Verschleierungs- und Analysefeindlichkeitsmerkmale, die Sie in den Beispielen sehen werden:
- Minimiertes Moduldiagramm mit numerischen Modul-IDs, spärlichen Kommentaren und abgeflachtem Kontrollfluss. Darüber hinaus, Diese Struktur macht eine manuelle Überprüfung extrem schwierig.
- Zeichenfolgen verbergen über Base64-Layer und Konstruktionshelfer. Zum Beispiel, Im Zusammenhang mit Exfiltrationsroutinen kommt es normalerweise zu wiederholten Base64-Kodierungen und -Dekodierungen.
- Dynamischer Versand - durch Konsolidierung, eval-Stilmuster und generierte Funktionskörper, wodurch Code sein Verhalten zur Laufzeit ändern kann.
- Betriebssystemfilterung die Ausführung unter Linux und macOS zu bevorzugen, insbesondere auf CI-Runnern und Entwickler-Laptops.
Aus funktionaler Sicht ist das Paket modular aufgebaut. Die Berichte beschreiben Module zur Betriebssystemerkennung, Dateisystem- und Git-Secret-Scans, Cloud-SDK-Zugriff, GitHub-API-Operationen und eine Propagierungs-Engine, die andere Pakete des Betreuers bearbeitet. Tatsächlich heben sowohl StepSecurity als auch ReversingLabs eine Funktion hervor, die Pakete mit dem bösartigen Hook automatisch aktualisiert.
Ausführung zur Installationszeit in Shai-Hulud: Wie npm-Pakete den Wurm auslösen
Der Angriff beginnt, wenn Postinstall führt Knoten aus Bundle.js. An diesem Punkt initialisiert und entpackt das Skript den Arbeitszustand im Speicher und bereitet so die Bühne für den vollständigen Betrieb des Wurms vor.
Entdeckung und Ernte
- Die Nutzlast erstellt einen Dump von process.env und durchsucht lokale Dateien nach Geheimnissen mit hoher Entropie und Token-Präfixen. Darüber hinaus erweitert sie die Abdeckung durch die Ausführung von TruffleHog.
- Es fragt Cloud-Metadaten-Endpunkte ab, um kurzlebige Anmeldeinformationen zu sammeln. Zum Beispiel ruft an
169.254.169.254auf AWS odermetadata.google.internalauf GCP treten häufig bei infizierten Wirten auf. - Folglich Alle gefundenen Anmeldeinformationen können sofort verwendet werden, um neue NPM-Pakete zu veröffentlichen oder GitHub-Workflows zu pushen.
Exfiltration
- Der Wurm erstellt ein neues GitHub-Repository mit dem Namen Shai Hulud und schreibt eine doppelte Base64-kodierte
data.jsonmit Plattformdetails, Umgebungsdumps und Geheimnissen. Wie man sieht, ist dieses laute Verhalten leicht zu erkennen, wenn die Verteidiger wissen, wo sie suchen müssen. - Es pflanzt auch einen GitHub Actions-Workflow ein, oft auf einem Zweig namens Shai-Hulud, das serialisiert
${{ toJSON(secrets) }}und postet die Daten an einen statischen Webhook. Darüber hinaus bleibt dieser Workflow bestehen, bis ihn jemand aktiv entfernt.
Fortpflanzung
- Mit jedem erkannten NPM-Token listet die Nutzlast alle Pakete auf, die dem kompromittierten Betreuer gehören. Anschließend ruft sie jedes Tarball ab, fügt bundle.js und einen Postinstall-Eintrag ein und veröffentlicht das Paket erneut.
- Infolgedessen können innerhalb weniger Stunden Dutzende infizierter Pakete auftauchen, wodurch sich der Explosionsradius im gesamten Ökosystem vervielfacht.
Persistenz und Exposition
Der Wurm hält bösartige Workflows aufrecht und macht in mehreren Fällen private Repos öffentlich mit einem "-Migration" Suffix. Insgesamt stellt dies sicher, dass der Angreifer einen sicheren Halt behält und das Risiko eines Datenverlusts maximiert wird.
Hinweis zur Tastenerkennung
Diese ungewöhnliche Verwendung von ${{ toJSON(secrets) }} in Aktions-Workflows ist selten. Daher sind Teams sollten es während der Jagd als Indikator für ein starkes Signal betrachten.
Suchen Sie nach einem bereinigten Workflow-Muster
Diese ungewöhnliche Verwendung von zu JSON(Geheimnisse) in Aktionen ist bei diesem Vorfall ein deutlicher Indikator.
Pseudocode zur Verbreitung auf hoher Ebene (sicher, beschreibend)
async function propagate(token, owner) {
const pkgs = await npmApi.listPackages(owner, token);
for (const p of pkgs) {
const tgz = await npmApi.fetchTarball(p, token);
const modified = injectBundleAndPostinstall(tgz); // adds bundle.js + "postinstall"
await npmApi.publish(modified, token); // publishes new malicious version
}
}Analysten haben diese Schleife in großem Maßstab beobachtet, was den schnellen Anstieg von Dutzenden auf Hunderte infizierter Pakete erklärt.
Warum dies ein Wurm im Paket-Ökosystem ist
Ein Wurm ist Schadsoftware, die sich selbstständig verbreitet, ohne dass in jedem Schritt ein manueller Eingriff erforderlich ist. In Betriebssystemen nutzen Würmer üblicherweise Netzwerkschwachstellen aus, um sich von einem Rechner auf einen anderen zu übertragen. Im Gegensatz dazu agiert Shai-Hulud innerhalb der npm-Registrierung. Sein effizienter Weg führt über Wiederverwendung von Anmeldeinformationen.
Der Wurm nutzt gestohlene NPM-Publish-Token. Sobald er gültige Anmeldeinformationen erhält, veröffentlicht er infizierte Versionen unter anderen Paketen desselben Betreuers. Anschließend werden diese Pakete von ahnungslosen Entwicklern oder CI-Runnern installiert, und der Zyklus wiederholt sich.
Aus diesem Grund haben Sicherheitsanalysten, darunter Dunkles Lesenklassifizieren Shai-Hulud als selbstreplizierender Wurm Es handelt sich nicht um einen einfachen Trojaner oder einen Typosquatting-Vorfall. Der Unterschied ist wichtig: Ein Trojaner kompromittiert normalerweise einen Host, während ein Wurm seine Auswirkungen automatisch im gesamten Ökosystem verstärkt.
Kurzanleitung „So funktioniert’s“
Um Shai-Huluds Lebenszyklus zusammenzufassen, hier ist ein ConcisDie Aufschlüsselung der wichtigsten Schritte:
- Ein Paket mit Nachinstallation installiert ist und
bundle.jsausführt. - Die Nutzlast gibt Umgebungsvariablen aus, scannt Dateien und den Git-Verlauf, führt TrüffelSchweinund fragt Cloud-Metadatendienste ab. Folglich ist jedes gefundene Geheimnis sofort nützlich.
- Die Exfiltration erfolgt auf zwei Arten: Erstens durch die Erstellung eines öffentlichen Repos namens Shai Hulud mit einer doppelten Base64-kodierten
data.json; zweitens durch die Einrichtung eines GitHub Actions-Workflows, der${{ toJSON(secrets) }}zu einem Webhook. - Mithilfe eines gestohlenen NPM-Tokens veröffentlicht der Wurm alle anderen Pakete des kompromittierten Betreuers mit demselben bösartigen Hook erneut. Auf diese Weise vermehrt sich die Infektion schnell.
- Schließlich verfügt der Angreifer über mehr Geheimnisse, mehr Pakete, die er verbreiten kann, und Beharrlichkeit innerhalb von GitHub-Konten und -Repositories.
Wie man diese Art von Angriff praktisch vermeiden kann
Shai-Hulud ist ein Weckruf. Ein Wurm, der Token stiehlt und sich selbst neu veröffentlicht, ist kein zukünftiges Risiko, er ist live in der Ökosystem der NPM-Pakete heute. Um diese Art von Supply-Chain-Angriff, Teams benötigen Kontrollen, die programmierbar, automatisiert und direkt in CI/CD pipelines. Dies sind die gleichen Abwehrmaßnahmen, die Sie bereits mit Xygeni.
Stoppen Sie schlechte Artefakte am Gate
Sie sollten npm-Pakete und Tarballs scannen, bevor sie Entwickler oder CI-Jobs erreichen. Übergroße bundle.js Dateien, verdächtige Postinstallation hooksund Verschleierungsmarker dienen alle als frühe Warnsignale. Darüber hinaus sollten Abkühlungsphasen und fixierte Versionen in pipelines verhindert, dass neue, ungeprüfte Releases automatisch konsumiert werden.
Härten CI/CD standardmäßig
Guardrails in CI/CD sind unerlässlich. Sie lehnen Zusammenführungen oder Installationen ab, die neue Skripte oder Binärdateien einführen. Gleichzeitig blockieren sie Workflows, die Geheimnisse serialisieren oder externe Posts versuchen. Teams sollten außerdem Lockfile-only-Installationen verlangen (npm ci) über alle pipelines, damit Abhängigkeitssätze reproduzierbar und sicher bleiben.
Reduzieren Sie den Explosionsradius des Tokens
Geheimnisse dürfen nicht zu einzelnen Schwachstellen werden. Scannen Sie kontinuierlich Code, Konfigurationen und pipeline Ausgabe für offengelegte AnmeldeinformationenToken sollten einen engen Gültigkeitsbereich haben, eine kurze Lebensdauer haben und automatisch rotiert werden, wenn eine Gefährdung erkannt wird. Behandeln Sie grundsätzlich alle Token, die auf einem Host verwendet werden, der eine verdächtige Postinstallation ausgeführt hat, als kompromittiert.
Erkennen Sie das Verhalten von Würmern frühzeitig
Erkennung von Anomalien ist entscheidend. Beispielsweise können plötzliche Spitzen bei NPM-Veröffentlichungsereignissen, neue Workflows, die ohne Grund erscheinen, oder neue öffentliche Repos voller seltsam codierter Dateien auf Wurmaktivität hinweisen. Daher sollten Teams schnell Alarm schlagen und alle Betreuer oder Ausführenden isolieren, die diese Warnsignale aufweisen.
Schnelle Reparatur ohne Build-Unterbrechung
Geschwindigkeit und Sicherheit müssen Hand in Hand gehen. Automatisierte pull requests kann kompromittierte npm-Pakete durch geprüfte Versionen ersetzen. Darüber hinaus Erreichbarkeit und Ausnutzbarkeit Die Analyse stellt sicher, dass die Upgrades minimal und stabil bleiben. Schließlich werden betroffene CI-Runner aus sauberen Images neu erstellt, sobald die Gefährdung bestätigt ist, um eine weitere Ausbreitung des Angriffs zu verhindern.
Kompromissindikatoren (IoCs)
Bei der Analyse von Shai-Hulud sollten die Teams auf beides achten statische IoCs in Dateien und Verhaltens-IoCs in pipelines. Zusammen helfen diese Signale dabei, Infektionen frühzeitig zu erkennen und zu reagieren, bevor sich der Wurm weiter ausbreitet.
Statische IoCs
Die folgenden SHA-256-Digests stimmen mit den beobachteten bundle.js Proben:
- 46faab8ab153fae6e80e7cca38eab363075bb524edd79e42269217a083628f09
- 81d2a004a1bca6ef87a1caf7d0e0b355ad1764238e40ff6d1b1cb77ad4f595c3
- dc67467a39b70d1cd4c1f7f7a459b35058163592f4a9e8fb4dffcbba98ef210c
Achten Sie außerdem auf diese wiederkehrenden Muster:
- A
bundle.jsim Stammverzeichnis des Pakets. "postinstall": "node bundle.js"innerhalbpackage.json.- Repositories mit dem Namen Shai Hulud.
- GitHub-Workflows mit
${{ toJSON(secrets) }}.
Verhaltensbezogene IoCs
Über Dateisignaturen hinaus offenbart sich die Aktivität von Würmern durch ihr Verhalten. Beispiele:
- Plötzliche Ausbrüche von npm-Veröffentlichungsereignissen von einem Betreuer.
- Neue Workflows, die Daten an externe Endpunkte übertragen.
- Ausgehende POST-Anfragen, die von CI-Runnern ausgelöst werden.
- Kürzlich erstellte öffentliche Repos mit codierten Blobs.
Schnelle Jagden
# Find postinstall in package.json
grep -R --line-number '"postinstall"' --include="package.json" /path/to/archives
# Detect tarballs with bundle.js
find /path/to/tarballs -name "*.tgz" -print0 \
| xargs -0 -n1 -I{} sh -c 'tar -tf "{}" | grep bundle.js && echo "== {}"'
# Search workflows for toJSON(secrets)
grep -R --line-number "toJSON(secrets)" --include="*.yml" .github || trueFazit: Lehren aus Shai-Hulud
Die Angriff auf die Lieferkette von Shai-Hulud in npm-Paketen zeigt, wie fragil die heutige Software-Lieferkette geworden ist. Dieser Wurm fügte nicht nur Schadcode ein. Er stahl Token, versendete Daten und veröffentlichte sich anschließend automatisch neu. Dadurch verbreitete sich der Angriff innerhalb von Stunden statt Wochen.
Für Entwickler und DevOps-Teams sind die Lehren klar:
- Bei jeder Installation wird Code ausgeführt. Sogar ein gewöhnliches npm-Paket kann einen Postinstall-Wurm verbergen.
- Jeder Token hat einen hohen Wert. Einmal gestohlen, können sie zur weiteren Verbreitung von Schadsoftware verwendet werden.
- Jede pipeline muss überprüft werden. Ohne guardrails Bei Abhängigkeiten, Arbeitsabläufen und Geheimnissen kann ein Kompromiss schnell die Produktion beeinträchtigen.
Um Angriffe wie Shai-Hulud zu stoppen, sind daher automatische und einfach durchsetzbare Kontrollen erforderlich. Teams sollten npm-Pakete vor der Installation scannen, Lockfile-Builds verwenden, ungewöhnliche Veröffentlichungsaktivitäten erkennen und Token kurzlebig halten. Diese Schritte sind nicht länger optional. Stattdessen bilden sie die Grundlage für die Resilienz moderner pipelines.
Bei Xygeni sehen wir den Shai-Hulud-Angriff auf die Lieferkette als Warnung für das gesamte Open-Source-Ökosystem. Der nachhaltige Weg nach vorn besteht darin, die Sicherheit der Lieferkette direkt in den Entwicklungsprozess zu integrieren, an den Punkt, an dem Code, npm-Pakete und pipelines verbinden.
Nachfolgend finden Sie die vollständige Liste der npm-Pakete und -Versionen, die in Shai-Hulud als kompromittiert gemeldet wurden. Verwenden Sie sie, um Ihre Sperrdateien, Registrierungen und CI zu überprüfen pipelines für die Belichtung.
Liste der kompromittierten Pakete
📦 Vorschau kompromittierter npm-Pakete
| Paketname | Version | Datum der Veröffentlichung |
|---|---|---|
| JSON-Regel-Engine vereinfacht | 0.2.1 | 2025-09-14T17:58:51.203Z |
| Luftpilot | 0.8.8 | 2025-09-14T18:35:07.600Z |
| mcp-Wissensgraph | 1.2.1 | 2025-09-14T18:35:09.494Z |
| Luftchef | 0.3.1 | 2025-09-14T18:35:09.521Z |
| Sprungtor | 0.0.2 | 2025-09-14T18:35:09.651Z |
| tvi-cli | 0.1.5 | 2025-09-14T18:35:10.996Z |
| @thangved/Rückruffenster | 1.1.4 | 2025-09-14T20:31:38.479Z |
| @tnf-dev/api | 1.0.8 | 2025-09-14T20:31:39.547Z |
| @tnf-dev/js | 1.0.8 | 2025-09-14T20:31:41.251Z |
| @tnf-dev/mui | 1.0.8 | 2025-09-14T20:31:41.259Z |
| @tnf-dev/core | 1.0.8 | 2025-09-14T20:31:42.728Z |
| @teselagen/react-table | 6.10.20 | 2025-09-14T20:37:08.597Z |
| @hestjs/demo | 0.1.2 | 2025-09-14T20:45:52.348Z |
| @nexe/eslint-config | 0.1.1 | 2025-09-14T20:45:53.625Z |
| @hestjs/eslint-config | 0.1.2 | 2025-09-14T20:45:55.044Z |
| @nexe/config-manager | 0.1.1 | 2025-09-14T20:45:55.066Z |
| @nexe/logger | 0.1.3 | 2025-09-14T20:45:55.170Z |
| @hestjs/logger | 0.1.6 | 2025-09-14T20:45:55.197Z |
| @hestjs/Validierung | 0.1.6 | 2025-09-14T20:45:55.595Z |
| @hestjs/core | 0.2.1 | 2025-09-14T20:45:55.888Z |
➡️ Vollständige Liste der kompromittierten Pakete anzeigen
| Paketname | Version | Datum der Veröffentlichung |
|---|---|---|
| JSON-Regel-Engine vereinfacht | 0.2.1 | 2025-09-14T17:58:51.203Z |
| Luftpilot | 0.8.8 | 2025-09-14T18:35:07.600Z |
| mcp-Wissensgraph | 1.2.1 | 2025-09-14T18:35:09.494Z |
| Luftchef | 0.3.1 | 2025-09-14T18:35:09.521Z |
| Sprungtor | 0.0.2 | 2025-09-14T18:35:09.651Z |
| tvi-cli | 0.1.5 | 2025-09-14T18:35:10.996Z |
| @thangved/Rückruffenster | 1.1.4 | 2025-09-14T20:31:38.479Z |
| @tnf-dev/api | 1.0.8 | 2025-09-14T20:31:39.547Z |
| @tnf-dev/js | 1.0.8 | 2025-09-14T20:31:41.251Z |
| @tnf-dev/mui | 1.0.8 | 2025-09-14T20:31:41.259Z |
| @tnf-dev/core | 1.0.8 | 2025-09-14T20:31:42.728Z |
| @teselagen/react-table | 6.10.20 | 2025-09-14T20:37:08.597Z |
| @hestjs/demo | 0.1.2 | 2025-09-14T20:45:52.348Z |
| @nexe/eslint-config | 0.1.1 | 2025-09-14T20:45:53.625Z |
| @hestjs/eslint-config | 0.1.2 | 2025-09-14T20:45:55.044Z |
| @nexe/config-manager | 0.1.1 | 2025-09-14T20:45:55.066Z |
| @nexe/logger | 0.1.3 | 2025-09-14T20:45:55.170Z |
| @hestjs/logger | 0.1.6 | 2025-09-14T20:45:55.197Z |
| @hestjs/Validierung | 0.1.6 | 2025-09-14T20:45:55.595Z |
| @hestjs/core | 0.2.1 | 2025-09-14T20:45:55.888Z |
| @hestjs/cqrs | 0.1.6 | 2025-09-14T20:45:55.966Z |
| @hestjs/scalar | 0.1.7 | 2025-09-14T20:45:56.386Z |
| ng2-Datei-Upload | 7.0.3 | 2025-09-15T02:44:29.555Z |
| Kondensator-Benachrichtigungshandler | 0.0.2 | 2025-09-15T04:54:48.431Z |
| Kondensator-Plugin-Vonage | 1.0.2 | 2025-09-15T04:54:48.501Z |
| Kondensator-Plugin-HealthApp | 0.0.2 | 2025-09-15T04:54:48.704Z |
| KondensatorAndroidBerechtigungen | 0.0.4 | 2025-09-15T04:54:48.753Z |
| VoIP-Anrufkit | 1.0.2 | 2025-09-15T04:54:49.223Z |
| Kondensator-Plugin-iHealth | 1.1.8 | 2025-09-15T04:55:08.113Z |
| @art-ws/common | 2.0.22 | 2025-09-15T05:21:15.411Z |
| @art-ws/config-eslint | 2.0.4 | 2025-09-15T05:21:17.199Z |
| ngx-ws | 1.1.5 | 2025-09-15T05:21:17.514Z |
| @art-ws/slf | 2.0.15 | 2025-09-15T05:21:17.524Z |
| @art-ws/http-server | 2.0.21 | 2025-09-15T05:21:17.745Z |
| pm2-gelf-json | 1.0.4 | 2025-09-15T05:21:18.413Z |
| @art-ws/di | 2.0.28 | 2025-09-15T05:21:18.488Z |
| @art-ws/di-node | 2.0.13 | 2025-09-15T05:21:18.849Z |
| @art-ws/config-ts | 2.0.7 | 2025-09-15T05:21:19.408Z |
| @art-ws/db-context | 2.0.21 | 2025-09-15T05:21:19.814Z |
| @art-ws/openapi | 0.1.9 | 2025-09-15T05:21:19.969Z |
| @art-ws/web-app | 1.0.3 | 2025-09-15T05:21:20.383Z |
| @art-ws/ssl-info | 1.0.9 | 2025-09-15T05:21:20.927Z |
