Vandaag draait alles om gestolen sleutels en wachtwoorden. Een besmette npm-package van Tensorlake laat een zelfverspreidende worm los die inloggegevens en tokens van ontwikkelaars en CI-omgevingen buitmaakt, aanvallers halen via een gepatcht Zimbra-lek authenticatiesleutels en mailboxen weg, en in de AI-component LMCache zit een kritiek lek waarvoor nog geen patch bestaat.
- Besmette npm-package van Tensorlake verspreidt Shai-Hulud-worm die inloggegevens steelt en zich nestelt in Claude Code- en VS Code-projecten
- Aanvallers misbruiken Zimbra-lek via SMTP om webshells te plaatsen en authenticatiesleutels te stelen
- Kritiek lek in LMCache laat ongeauthenticeerde aanvaller code uitvoeren, een patch ontbreekt nog
Besmette npm-package van Tensorlake verspreidt Shai-Hulud-worm die inloggegevens steelt en zich nestelt in Claude Code- en VS Code-projecten
| Kwetsbaarheid | Supply-chain-aanval: kwaadaardige code in een officiële npm-release met een preinstall-hook die een zelfverspreidende, inloggegevens stelende worm uitvoert – npm-package tensorlake (TypeScript-SDK van Tensorlake), versie 0.5.144 |
| Actief misbruikt | Ja, de besmette versie is op npm gepubliceerd en is onderdeel van de bredere Shai-Hulud-campagne |
| Patch beschikbaar | Geen patch nodig of mogelijk: de besmette versie is van npm verwijderd. Wie hem heeft geïnstalleerd, moet hem verwijderen en alle bereikbare inloggegevens vervangen |
Hoe wordt de aanval uitgevoerd?
Volgens The Hacker News werd op 7 oktober kwaadaardige code naar de hoofdtak van de Tensorlake-repository gepusht onder de naam van een maintainer, waarna de reguliere releasepijplijn de besmette versie zelf op npm publiceerde. Bij installatie start een preinstall-hook een versluierde loader die met de Bun-runtime een worm uitvoert. Die verzamelt inloggegevens uit lokale bestanden, CI-omgevingen, Kubernetes en Vault, waaronder npm-, GitHub- en AWS-tokens, SSH-sleutels, .env-bestanden en cryptowallets, en stuurt ze weg. De worm verspreidt zich door andere pakketten opnieuw te publiceren, met geldige Sigstore-provenance, en door valse GitHub Actions-workflows te plaatsen. Daarnaast schrijft hij bestanden naar .claude/settings.json en .vscode/tasks.json in bereikbare repositories, zodat de code opnieuw draait zodra iemand het project opent in Claude Code of VS Code. De analyse komt van onder meer Socket en StepSecurity.
Wat kan het gevolg zijn?
Het gevaarlijke zit in de combinatie van diefstal en verspreiding. Met een buitgemaakt GitHub- of npm-token kan de worm via een legitieme account verdere pakketten besmetten, waardoor klanten en collega’s van de eerste slachtoffers ook worden geraakt. De zogeheten hostage token-monitor controleert bovendien of het gestolen GitHub-token nog geldig is en voert bij intrekking een door de aanvaller aangeleverde handler uit, die waarschijnlijk een destructieve routine start. Intrekken van tokens is dus noodzakelijk, maar moet na het isoleren van het systeem gebeuren. Voor MSP’s met eigen scripts, automatiseringen of klantprojecten in Node.js is dit relevant omdat een enkele npm install op een beheerdersmachine genoeg kan zijn om toegang tot meerdere klantomgevingen te verliezen.
Wat moeten IT-beheerders nu doen?
Zoek in package-lock-bestanden en CI-logs naar tensorlake 0.5.144 en verwijder die versie. Isoleer getroffen systemen eerst, trek daarna alle tokens en sleutels in die daar bereikbaar waren (npm, GitHub, AWS, SSH, Vault, Kubernetes), en controleer repositories op onverwachte commits, nieuwe workflows en onbekende .claude/settings.json- of .vscode/tasks.json-bestanden. Overweeg daarnaast om installatiescripts van npm-pakketten standaard uit te zetten in CI en op beheerdersmachines.
Aanvallers misbruiken Zimbra-lek via SMTP om webshells te plaatsen en authenticatiesleutels te stelen
| Kwetsbaarheid | Ongeauthenticeerde OS-commando-injectie via een geprepareerd SMTP-verzoek, alleen te misbruiken wanneer het optionele pakket zimbra-snmp is geïnstalleerd en SNMP-meldingen zijn ingeschakeld – Zimbra Collaboration Suite, versies vóór 10.1.20 |
| CVE-nummer | CVE-2026-73570 |
| CVSS-score | 8,9 |
| Actief misbruikt | Ja, de kwetsbaarheid staat in de CISA-catalogus van actief misbruikte kwetsbaarheden; Microsoft beschrijft aanvallen bij organisaties in meerdere regio’s en sectoren |
| Patch beschikbaar | Ja, Zimbra 10.1.20 of hoger (uitgebracht in juli 2026) |
Hoe kan de kwetsbaarheid misbruikt worden?
Een aanvaller hoeft niet in te loggen en niemand hoeft ergens op te klikken: een speciaal opgebouwd SMTP-verzoek volstaat om commando’s uit te voeren met de rechten van het Zimbra-serviceaccount. The Hacker News schrijft op basis van onderzoek van Microsoft dat er tussen de patch in juli en de openbare bekendmaking in augustus al is gescand en misbruik is gemaakt. Aanvallers plaatsten JSP-webshells, zetten reverse shells op, verhoogden hun rechten via een aangepaste sudo-PAM-configuratie en zorgden met cron, systemd en memfd_create voor blijvende toegang. Daarna haalden ze de authenticatiesleutels en mailboxgegevens van de server op.
Wat kan het gevolg zijn?
Wie de pre-auth-sleutels en het geheim voor tweestapsverificatie van Zimbra in handen krijgt, kan zich als gebruiker aanmelden zonder wachtwoord en de beveiliging op tweede factor omzeilen. Microsoft zag bovendien dat aanvallers het vertrouwen tussen Zimbra-clusterknooppunten en een bestaande SSH-identiteit gebruikten om naar andere nodes door te schuiven, en dat op één server recente mailboxback-ups in een archief werden klaargezet voor uitvoer naar Azure. Voor MSP’s die Zimbra hosten of beheren, betekent dit dat een gepatchte server nog steeds gecompromitteerd kan zijn als de aanval vóór de update plaatsvond, en dat opgeschoonde webshells niet genoeg zijn zolang de sleutels niet zijn vernieuwd.
Wat moeten IT-beheerders nu doen?
Breng alle internetgerichte Zimbra-servers in kaart, controleer of het pakket zimbra-snmp is geïnstalleerd en update naar 10.1.20 of hoger. Kan dat nog niet, verwijder dan zimbra-snmp, schakel SNMP-meldingen uit en beperk SMTP- en SNMP-toegang tot vertrouwde hosts. Bewaar logs voordat ze roteren, zoek naar onverwachte JSP-bestanden, cron-regels, SSH-sleutels en systemd-units, onderzoek alle onderling vertrouwde nodes en vernieuw na afhandeling de Zimbra-sleutels en servicegegevens. SPF, DKIM en DMARC helpen hier niet, en een schone testuitslag bewijst niet dat een server niet eerder is gecompromitteerd.
Kritiek lek in LMCache laat ongeauthenticeerde aanvaller code uitvoeren, een patch ontbreekt nog
| Kwetsbaarheid | Ongeauthenticeerde remote code execution in de multiprocess-server wanneer die aan een bereikbaar netwerkadres is gekoppeld – LMCache (cachinglaag voor LLM-inferentie), versies 0.3.9 t/m 0.5.5, de 0.5.6-release candidates en de ontwikkeltak |
| CVE-nummer | CVE-2026-105192 |
| CVSS-score | 9,8 (score van JFrog) |
| Actief misbruikt | Nee, er is geen misbruik gemeld |
| Patch beschikbaar | Nee, er is geen gefixte versie en LMCache heeft geen beveiligingsadvies gepubliceerd |
Hoe kan de kwetsbaarheid misbruikt worden?
De fout is ontdekt door Yuval Moravchick van het beveiligingsonderzoeksteam van JFrog, dat het lek op 7 oktober openbaar maakte. The Hacker News meldt dat elke host die de LMCache-server kan bereiken, daarop zonder inloggegevens code kan laten draaien. Het risico geldt dus vooral voor installaties waarbij de server niet alleen op localhost of een vertrouwd clusternetwerk luistert.
Wat kan het gevolg zijn?
LMCache wordt gebruikt om LLM-diensten sneller te maken en draait vaak op dure GPU-servers met toegang tot modellen, data en cloudgegevens. De officiële containerimages draaien het proces als root, waardoor een geslaagde aanval direct tot volledige controle over de container kan leiden. Een extra probleem is dat het advies van JFrog beheerders geen manier geeft om te zien of een server al is aangevallen. Voor MSP’s die AI-workloads voor klanten hosten of inrichten, is dit een voorbeeld van hoe snel experimentele AI-tooling met te ruime netwerkrechten een route naar de rest van de omgeving wordt.
Wat moeten IT-beheerders nu doen?
Controleer of LMCache met de multiprocess-server in gebruik is en zorg dat die niet aan een bereikbaar netwerkadres is gekoppeld, maar alleen aan localhost of een afgeschermd clusternetwerk. Firewallregels verkleinen het risico, maar nemen het niet weg, omdat elke host die kan verbinden code kan uitvoeren. Draai de container waar mogelijk niet als root en volg de repository van LMCache voor een gefixte release.
