Gebruikers van Red Hat Linux lopen gevaar door aanval via malafide npm-packages

Gebruikers van Red Hat Linux lopen gevaar door een hackaanval waarbij malafide npm-packages hun systemen kunnen infecteren. De aanvallers stelen inloggegevens voor toegang tot gevoelige informatie. Ze misbruikten daarvoor het officiële account van Red Hat voor npm-packages.

Meerdere npm-packages in het officiële npm-kanaal @redhat-cloud-services zijn voorzien van kwaadaardige code die automatisch wordt uitgevoerd bij elke installatie van een npm-package. Dit ontdekten IT-beveiligingsbedrijven Step Security en Aikido gisteren. Npm is een beheertool voor functionele stukken JavaScript-code, de zogeheten packages. Deze pakketten kunnen een volledige applicatie of app zijn, maar kunnen ook slechts componenten voor andere software zijn.

Deze hackaanval misbruikt de toeleveringsketen (supplychain) die veel ontwikkelaars gebruiken om hun eigen producten en diensten te maken. Het officiële Red Hat-account in de npm-repository geniet de status van een vertrouwde bron voor de stukken code. De malafide code in de 32 besmette npm-packages zit onder drie verhullingslagen die securityscanners om de tuin leiden.

Na activering steelt de malware inloggegevens voor diverse ontwikkelaars- en clouddiensten. Dit omvat GitHub Actions, Amazon Web Services, Google Cloud, Microsoft Azure, Kubernetes, HashiCorp Vault, CircleCI en npm zelf. Inloggegevens voor die diensten geven de aanvallers toegang tot gevoelige informatie.

Wormfunctionaliteit

De via Red Hat verspreide malware is ook een zogeheten worm: code die zichzelf kan repliceren en verder verspreiden. Het gebruikt daarvoor gestolen npm-toegangstokens en de ingebouwde mogelijkheid van npm om tweefactorauthenticatie te omzeilen. Hierdoor kan deze malware zelfstandig een backdoor implanteren in andere npm-packages. Deze wormfunctionaliteit laat geïnfecteerde computers weer andere systemen besmetten, zonder dat de aanvallers dit zelf of direct doen.

Het is nog niet duidelijk hoe de aanvallers toegang kregen tot het officiële npm-kanaal van Red Hat. Volgens Ars Technica is het bijna zeker dat de inloggegevens voor het npm-account van Red Hat zijn gecompromitteerd. Mogelijk is dat te danken aan een eerdere supplychainaanval. Red Hat bevestigt de aanval, meldt dat het de geïnfecteerde packages heeft verwijderd en dat het de zaak onderzoekt.

Aanvalsroute met lange aanloop

Step Security meldt dat alle geïnfecteerde packages uit het @redhat-cloud-services-kanaal komen vanaf de GitHub-repository RedHatInsights/javascript-clients, via de authenticatiemogelijkheid OpenID Connect van automatiseringstool GitHub Actions. Deze aanvalsroute wijst er volgens Step Security op dat de ontwikkelomgeving van Red Hat voor continue integratie en ontwikkeling (ci/cd) is gecompromitteerd. Dit zou dan een lange aanloop betekenen voor deze hackaanval die een flink bereik blijkt te hebben.

Tweakers heeft eerder een achtergrondverhaal over supplychainaanvallen via npm-packages gepubliceerd. Vorig jaar waren er diverse aanvallen via het krachtige en dus ook risicovolle systeem voor distributie en gebruik van stukken softwarecode.

Ontwikkelaar werkt aan code. Bron: Microsoft

Reacties (60)

[Solopher]

Waar worden deze NPM packages voor gebruikt dan? Want ik vind het nogal sensatie om te roepen dat: "Gebruikers van Red Hat Linux" hierdoor gevaar lopen.

Ik heb er een paar random uit het lijstje gepakt, maar als ik kijk naar 't weekly installs, dan is dit ~1000 installs, vind dit best wel weinig (nu is de week natuurlijk net begonnen), wanneer je bijv. kijkt bij lodash dan is dit ruim 153.432.504

[nullbyte]

Idd het is iets ongenuanceerd. Standaard Red Hat dnf/yum repositories die voor OS en Software updates gebruikt worden lopen door deze specifieke aanval geen gevaar. Met andere woorden, veruit de meeste Redhat servers ondervinden geen hinder van deze aanval.

[Reactie gewijzigd door nullbyte op 2 juni 2026 17:26]

[xxs]

Ik verwacht dat je vanuit RH niet eens support krijgt als je NPM packages geinstalleerd hebt staan. Bij mijn weten geeft RH alleen support op hun eigen packages + EPEL. Als beheerder zou het dan ook niet slim zijn om andere repositories te gebruiken.

[Reactie gewijzigd door xxs op 2 juni 2026 18:37]

[Bamboozled]

EPEL supporten ze toch zeker ook niet, is een community ding

[xxs]

Mijn account is niet meer actief bij RH maar ik meende toch echt dat systemen met EPEL wel RH support konden krijgen was maar kennelijk moet dat dan via een speciaal verzoek (RFE) Request Feature Enhancements.

Ik bedoel dus niet dat RH de EPEL packages support maar systemen die gebruik maken van EPEL.

[Reactie gewijzigd door xxs op 2 juni 2026 18:59]

[Bamboozled]

Precies een RHEL systeem is niet zomaar uit de support als daar EPEL packages op staan, alleen die packages worden niet gesupport. Dus er kan iets aan de hand zijn wat niets met EPEL te maken heeft en dan word je gewoon geholpen. Je uploadt nu een handig SOS report en dan zien ze de metrics van je systeem, scheelt tijd en heen en weer mailen.

[Reactie gewijzigd door Bamboozled op 2 juni 2026 19:03]

[rachez]

Voor zover ik weet heeft EPEL geen RH support. Volgens mij zelfs weleens positives op gezien voor malware (not sure). Ik zou het niet gebruiken op productie.

[telenut]

Dank voor deze info. Behalve de standaard updates gebeuren er op onze servers weinig dingen zonder aankondiging denk ik

[bdevriendt]

Het gaat over npm packages die gebruikt worden om via typescript/javascript cloud services te beheren van Red Hat. Als je toevallig de vulnerable packages geinstalleerd hebt tijdens CI/CD workflow of op je ontwikkel pc loop je gevaar om via de post install van NPM malware te installeren.

Deze attack vector wordt al maanden misbruikt. Ik vraag mij af wanneer Microsoft eindelijk eens post install scripts niet meer default gaat uitvoeren en npm op het niveau van yarn en pnpm gaat brengen qua security.

[jaenster]

Microsoft is niet de eigenaar van node

[bdevriendt]

Node niet. Npm wel

Wikipedia: npm

Node heeft hier ook niks mee te maken, de post install functionaliteit zit in npm.

[jaenster]

Gelukkig beweegt alles richting pnpm waarbij dit wel fatsoenlijk word gedaan + waar packages minimaal x tijd oud moeten zijn. Nog niet bij default maar wel veel gebruikt al

[WK100]

Dit heeft `npm` intussen ook al eventjes via `min-release-age`: https://gist.github.com/mcollina/b294a6c39ee700d24073c0e5a4e93104

[Rhizix]

npm gebruiken is echt vragen om problemen.
Iedere fatsoenlijke dev zit gelukkig al op pnpm

[Solopher]

Ja, ik ben helaas bekend* met deze attack vector (Shai-Hulud), maar waar ik op doelde, het zijn niet alle gebruikers van Red Hat Linux die nu opeens kwetsbaar zijn.

Pagina vanuit Red Hat zelf: https://access.redhat.com/security/vulnerabilities/RHSB-2026-006

Voor mensen die iets met GitHub Actions doen, is het verstandig om Zizmor te gebruiken om je Actions te hardenen, voor publishers is het verstandig om het nieuwe "npm stage" te gebruiken; https://docs.npmjs.com/cli/v11/commands/npm-stage

[peterpaulk]

Ik werk bij redhat.. quote uit artikel.

Based on current findings, no actions from customers are required.

Laten we afwachten vwb er geüpdatet wordt en wat mijn collegas vinden.

[whiner]

gelukkig heeft iedereen een virusscanner tegenwoordig. "/s"

[Reactie gewijzigd door whiner op 2 juni 2026 15:01]

[lenwar]

Pfff

Ik werk zakelijk met Red Hat, maar ik heb (vooral wat oudere collega's) die het maar onzin vinden dat we antimalware en andere beveiligingssoftware hebben draaien op onze Linux-omgevingen.

[nullbyte]

Hoog tijd voor een SANS cursusje voor een update betreffende Cybersecurity voor de ouwelui

[Reactie gewijzigd door nullbyte op 2 juni 2026 17:15]

[DLSS]

Waarom vinden ze dat? Is Linux zo veilig van zichzelf?

[lenwar]

Inderdaad. Ze hebben het idee dat 'Linux veilig is', dat 'er per definitie niks kan gebeuren' en het alleen maar zonde van de resources is. (Een beetje de houding van 10 jaar geleden toen er nog vrij weinig malware voor Linux was.)

Het zijn een beetje dezelfde soort mensen die niet geloven dat Apple op MacOS standaard antimalware en andere zaken meelevert. (Apple houdt het alleen stil voor de gebruiker, maar Gatekeeper en Xprotect draaien natuurlijk gewoon netjes op alle MacOS-systemen ). N.B. Niks ten nadele van Apple in deze hè? Gewoon een observatie.

[MindUnboxed]

Geen enkel systeem is in die zin veilig maar je hebt onveilig en dan komt er een hele tijd niks en dan komt Windows. Natuurlijk is het naïef om te denken dat je Linux niet te hacken valt. Linux wordt al gehackt zolang het bestaat. Simpel zat. Maar dat neemt niet weg dat Linux natuurlijk wel inherent veel robuuster in elkaar zit. Zoals altijd: context matters..

[DLSS]

Windows is natuurlijk altijd de beste target geweest (want het grootste by far).

Is het niet zo dat, nu linux flink aan het groeien door de opstelling van Valve, het gewoon een betere target aan het worden is voor criminelen?

Met andere woorden het loont steeds meer om er malware voor te ontwikkelen?

[batjes]

Jazeker. Hetzelfde met die Signal phishing, het is een teken dat er wat te halen valt.

En dat gedoe over Linux is zo veilig moet toch al sinds Anonymous achterhaald zijn? Nadat er massaal linux servers gehacked werden om mee te ddossen.

[DLSS]

Ik vraag me of het uiteindelijk niet even erg wordt als Windows als Linux doorgroeit.

[batjes]

Het zal een beetje gelijk worden vermoed ik. Windows heeft als voordeel dat het al 30 jaar een primair doelwit is en is daarmee 'battle hardened'. Terwijl Linux die dans grotendeels ontgaan is en dat kan wel eens pijn doen wanneer Linux het primaire doelwit wordt.

Maar Linux is open source en goed gemanaged, waardoor er ook snel en adequaat kan worden gereageerd.

[MindUnboxed]

Linux is natuurlijk al decennia enorm groot. Op de desktop niet maar wel als je alle systemen op 1 hoop gooit. De attack surface van Linux is gigantisch. Dus nee dit gaat nu niet zomaar verschuiven.

[nullbyte]

De attack surface van Linux is gigantisch

LOL Want? Waar zijn je argumenten...

[Heroic_Nonsense]

Linux is in dit geval interessanter omdat er erg veel servers zijn die draaien op dat OS. Zeker op Red Hat met een enterprisesupportcontract.

[jrswgtr]

De grootste markt voor Linux is die van de servers. Nu steeds meer dingen in de "cloud" gebeuren wordt dat een steeds groter doelwit.

[SuperDre]

Windows ansich is tegenwoordig al lang niet meer zo onveilig, gaat relatief op met Linux. Gelukkig komt windows tegenwoordig ook met een relatief goede antimalware/virus software.

[MindUnboxed]

Leg dan eens uit waarom ik bijv op een centraal beheerde en zogezegd compleet dicht getimmerde Windows 11 laptop gewoon een executable kan downloaden en uitvoeren? Linux staat het uitvoeren van code niet eens toe tenzij expliciet toegestaan. En waarom moet je als Windows-thuisgebruiker het halve internet afstruinen om aan je software te komen, met alle risico's van dien? Windows heeft in de basis sinds Windows 95 geen enkele ontwikkeling meer doorgemaakt. De telkens nieuwe cosmetische lagen zijn daarin niet relevant. Windows is een rommel met de oneindige variatie aan installers, drivers en applicatie UI's.

Plus dat het natuurlijk geen openbare broncode is waardoor de veiligheid in hoge mate afhangt van geheimzinnigheid (security through obscurity). De inbreker die niet weet dat er een sleutel onder de deurmat ligt waardoor het goed gaat zolang het goed gaat. Als de broncode van Windows 11 zou uitlekken dan zijn de rapen gaar. Een dergelijk systeem kan nooit op gelijke voet komen met openbare software. Dat is op gebied van security al heel lang zo maar nu begint Windows zelfs achter te lopen in praktische bruikbaarheid.

Windows 11 met al zijn toeters en bellen stuit op steeds meer weerstand. Als je een tijdje een bekendere Linux distro gebruikt met een dito relatief grote desktop environment dan kom je er vrij snel achter hoeveel robuuster alles in elkaar zit. De logische opbouw is bijna stuitend als je dat naast Windows legt. En ik zeg dat als relatief late overstapper. Ik ben opgegroeid met Windows.

[SuperDre]

Wat een ongelooflijke kolder, vooral 'windows heeft sinds windows 95 geen enkele ontwikkeling meer doorgemaakt', daarmee maak je jezelf compleet belachelijk. Zeker omdat de huidige windows niets te maken heeft met Windows 95, maar Windows NT als verre basis heeft, wat echt compleet anders was als W95.

Ook dat je het halve internet moet afstruinen om je software te krijgen, dat is bij linux ook niet anders, want niet alles zit in die 'betrouwbare' repositories waarvan we ook al regelmatig lezen dat er weer een zoveelste aangetast is met malware. En je gaat dan al zeggen, als je 1 van de bekendere distros + desktop, dus je moet dan eerst nog goed uitzoeken welke geschikt is voor jou, en de keuze welke distro is gigantisch.

En dan aankomend op source beschikbaar, ja, een scriptkiddie heeft de uitgebreide source nodig, een serieuze hacker/malwareschrijver heeft genoeg aan decompilers, en zelfs dankzij AI kan die van gedecompileerde binaries zeer leesbare code maken, inclusief uitleg. En omdat iets opensource is betekent dat niet meteen dat fouten sneller gevonden worden, maar al helemaal niet dat ze ook eerder opgelost worden.

[MindUnboxed]

De Windows NT kernel is ouder dan Windows 95. En als je verder belangrijke kernwoorden uit quasi-citaten van mijn reactie weglaat dan moet je ook geen woorden als 'kolder' bezigen.

Ik haal al mijn software op Kuntuntu uit de standaard repo's dan wel PPA dan wel een officiële repo van Microsoft of andere partijen. Of de officiële Docker kanalen van dit soort partijen op een Linux server. Ik doe niet aan losse installers of standalone executable pakketten terwijl je op Windows geen andere keuze hebt dan deze twee zaken. De Windows Store tel ik niet mee want daar zit veel te weinig 3rd party software in.

Je verhaal over script kiddies slaat kant noch wal. Script kiddies die even de broncode van een compleet OS inclusief de kernel gaan doorspitten. Geloof je het zelf?

[SuperDre]

Ik doe niet

Juist JIJ doet niet. En die repositories is in principe ook niets meer dan een installer, en je noemt dan zelf al verschillende repositories, daarmee, dus niets anders dan losse installaties van officiele bronnen binnenhalen. En ook via powershell, of een vergelijkbare gui, kun je op windows ook je software uit repositories halen. Dat lang niet iedereen het doet is een ander verhaal. Zit de software niet in je favoriete packagemanager dan zul je op linux ook rond moeten gaan zoeken. En we hebben al lang gezien de laatste tijd dat packagemanagers geen garantie voor veilige software betekent.

En mbt 'scriptkiddies', of ze dat doen us een ander verhaal, maar die hebben wel de originele broncode nodig om de code te begrijpen omdat die het resultaat van decompiled binaries niet begrijpen. Maar zoals ik al zei, dankzij AI is dat tegenwoordig ook geen probleem meer, want die kan wel leesbare code/documentatie van cryptische decompiled binaries maken (eigen ervaring van compleet onleesbare/onduidelijke code en dat AI daar gewoon documentatie van maakte alsof het bijna gewoon het ontwerpdocument was, I was flabbergasted van het resultaat).

[MindUnboxed]

Uiteraard "ik". Ik spreek alleen voor mezelf en dat is nogal evident. Een repo is natuurlijk iets heel anders dan van een willekeurige website een executable downloaden en starten. Een repo koppel je eenmalig in met een server certificaat en dat kun je ook vanuit je eigen documentatie doen. Na een verse installatie heb ik op deze manier helemaal geen browser nodig om alle software te downloaden en installeren. En eenmaal ingesteld dan lopen alle packages mee met de centrale package manager. Een update-rondje is voor mij een simpele apt update ; apt upgrade -y en dan is binnen 20 s alles weer up-to-date. Serverside gebruik ik graag Docker en dan haal je met een paar commando's nieuwe images op en deploy je die vervolgens waarna elke container een paar tellen offline is dan weer online en up-to-date. Dit kun je ook scripten en dan ben je met een enkel commando klaar. Kind kan de was doen en het scheelt een lastig Windows serverpark met dito dure support als je een wat grotere organisatie bent. Plus dat je zeker met VM's in een pure Windows omgeving Windows op Windows moet stapelen (Windows clients op een Windows VM backbone). Serverside is Linux in meerdere opzichten gewoon unmatched.

Ja Windows heeft tegenwoodig ook een package manager. Die is echter maar halfbakken want blijft afhankelijk van al die losse installers en het bestaat voornamelijk in user space. Een package manager op GNU/Linux is diep verweven met systemspace en zit er ook al decennia in. Een package manager zit in de ontwerpfilosofie van de meeste distro's. Bij Windows is het maar een after-thought. En inderdaad, niet veel mensen gebruiken die in Windows want het voordeel is in de praktijk niet zo groot. Daarbij blijf je met een groot aantal bronnen van al je software zitten terwijl je in GNU/Linux alle door de distro ondersteunde packages van een enkele server downloadt. Dat zijn dus ook alle ondersteunde 3rd party packages. En het werkt dan natuurlijk ook gewoon 100% in een terminal. Dus je hoeft geen GUI te gebruiken maar het kan wel als je daar behoefte aan hebt en dat werkt ook prima.

De grote grap is dat zelfs Microsoft's eigen software op een Linux bak veel makkelijker installeert. Voor een eenvoudige SQL Server installatie op Windows moet je een halve cursus doen. Of je haalt de Docker image op uit de officiele Microsoft repo en dan kies je 1 keer welk licentiemodel je hebt en de boel draait in een paar minuten. Heel Microsoft Azure draait notabene op Linux-bakken (Azure Linux om precies te zijn). En hier laat ik het bij want overtuigen is mijn doel niet. FOSS heeft zichzelf in de praktijk allang bewezen en vooroordelen en de hang naar Windows blijven nu eenmaal hardnekkig. Het is wat het is. Ik doe er mijn voordeel mee en dat is voor mij genoeg. Soms gooi ik een lijntje hierover uit en dan kunnen anderen ermee doen wat ze willen. Ieder z'n ding.

[fenrirs]

Linux staat het uitvoeren van code niet eens toe tenzij expliciet toegestaan.

Wat een bullshit. Er is geen verschil tussen dubbel klikken in windows of een foutscript.sh aanklikken een een willekeurige filemanager

[MindUnboxed]

Je zal toch eerst dat script execute rechten moeten geven met een chmod +x of een vinkje in je file manager. Dat gebeurt niet vanzelf.

[asing]

Wat @Pendora ook al aangeeft. Noem eens een Linux AV scanner die realtime scant? Er zijn er maar een paar. De meeste alleen "enterprise". Voor homelab gebruik is er eigenlijk alleen ClamAV, wat alleen op commando scant en imo ook niet zo denderend is. BitDefender en avast hebben bijvoorbeeld ook een scanner, maar alleen voor bedrijven. Ook Microsoft Defender draait op Linux, mits je de Linux machine aan Intune koppelt. Ik meen dat je dan ook beperkt bent tot Ubuntu, misschien is het tegenwoordig beter.

Uiteindelijk is de enige tool die ik erop had staan rkhunter, maar ook die moet je zelf aftrappen.

[lenwar]

Ik zou het ook niet weten, maar je hebt inderdaad in elk geval ClamAV.

Maar ja. Zoek is op willekeurige plaatsen en je vind overal de houding 'dat het niet nodig is'. Dus zakelijk gezien is het moeilijk om daar tussen te gaan zitten. En dan wordt het al helemaal lastig als relatief veel Linux-gebruikers het 'het moet financieel gratis zijn'-motto aanhouden. (n.b. Ik zeg niet dat 'alle Linux-gebruikers' dat per se willen.) Dus ik kan me voorstellen dat er weinig commerciële bedrijven zijn die daar in willen.

[_JGC_]

Vraag is dan vooral hoeveel linux malware zo'n scanner vindt. Dat stukje code dat aan xz-utils was toegevoegd had geen malware scanner kunnen vinden bijvoorbeeld.

[xxs]

Ik heb 30 jaar in 'het vak' gezeten en ik heb werkelijk nog nooit een Linux engineer gesproken die een dergelijke houding had. Maar ja n=1.

[Bamboozled]

Ik weet dan niet waar jij rondliep maar overal waar ik kwam waren ze aanwezig. En ik werk nog niet eens 30 jaar.

[Yoshi]

Het gaat hier over Red Hat, dus idd enterprise niveau, daar bestaan er best wel wat. Al is het maar om te voldoen aan bepaalde regels die opgelegd worden en waar een auditor aan te pas komt.

[Caelorum]

Wat @Pendora ook al aangeeft. Noem eens een Linux AV scanner die realtime scant? Er zijn er maar een paar. De meeste alleen "enterprise". Voor homelab gebruik is er eigenlijk alleen ClamAV, wat alleen op commando scant en imo ook niet zo denderend is.

Is ClamOnAcc (Archlinux doc link) niet hiervoor?

The clamonacc daemon registers for file access notifications from the Linux kernel and in response, submits scans to the clamd scanning daemon for a verdict. On-Access is only available on Linux systems. On Linux, On-Access requires a kernel version >= 3.8. This is because it leverages a kernel api called fanotify to block processes from attempting to access malicious files. This prevention occurs in kernel-space, and thus offers stronger protection than a purely user-space solution.

Zie ook https://docs.clamav.net/manual/OnAccess.html

[Reactie gewijzigd door Caelorum op 2 juni 2026 15:56]

[xxs]

Trellix, overigens hoef je niet per se realtime te scannen als je een fatsoenlijke NextGen firewall gebruikt.

[Reactie gewijzigd door xxs op 2 juni 2026 18:31]

[mocem]

De scanners waar ik mee werk kosten je bijna de helft van je performance. Wat een troep is het. Zodra er een beetje load op de systemen komt parkeert de boel. Mij niet bellen over trage responsetijden

[satya]

In linux omgevingen is het al dan niet realtime opvolgen van gedrag belangrijker, iets wat met Wazuh prima te doen is en je een volwaardige SIEM/MDR omgeving biedt met weinig impact en een malware scanner in zich heeft.

[RiDo78]

Ook Microsoft Defender draait op Linux, mits je de Linux machine aan Intune koppelt. Ik meen dat je dan ook beperkt bent tot Ubuntu, misschien is het tegenwoordig beter.

Dat werkt tegenwoordig wel beter, ook op Red Hat based machines kun je die troep installeren. En ja, troep... je hebt minimaal 4 Gb RAM nodig om het te laten draaien, en dan moet je verder niet veel met je VM doen. Bovendien gaat het wdavdaemon proces regelmatig over de zeik waardoor de hele machine zo traag wordt als wat.

[rachez]

Hoho, 2GB is al voldoende voor die troep, moet je verder alleen niet veel doen ..

[asing]

Jullie gebruiken al het woord troep. Dat zegt genoeg denk ik. Ik heb het jaren geleden een keer getest en was ook niet onder de indruk. Het is denk ik meer om dat stukje markt alvast in te nemen en je ISO gelukkig te houden met de gedachte dat je Linux machine wordt beschermd door een product van Microsoft wat gehost en gemanaged wordt in de Microsoft Cloud. Pun definately intended

Ik had ook zoiets van : ik wil gewoon AV hebben op mijn linux laptop. Er was ooit een goede, gratis scanner. Comodo. Ooit, want ondersteunde distro's zijn oa Fedora 17 en Ubuntu 12.04. Sophos had blijkbaar ooit ook wat maar dat was al obsolete voor ik ernaar zocht.

Er is dus eigenlijk niks fatsoenlijks wat gewoon los te koop is en niet gericht op Enterprise.

[xxs]

Zijn die collega's gebruikers of beheerders?

[Bamboozled]

Je kan ook zelf niet vatbaar zijn en wel besmette packages serveren, wat meestal op 1 of andere manier gebeurt met Linux. Denk aan Satellite repos en pulp cache. Dat type beheerder wat jij omschrijft heb ik echt een broertje dood aan. Dat doet liever te weinig dan teveel.

[Reactie gewijzigd door Bamboozled op 2 juni 2026 18:46]

[satya]

Voor dat wat onder mijn verantwoordelijkheid valt heb ik er een plugin van Wazuh op draaien om de omgeving in de gaten te houden. Goed voor het in en overzicht van de omgeving.

[Polderviking]

De malafide code in de 32 besmette npm-packages zit onder drie verhullingslagen die securityscanners om de tuin leiden.

[lenwar]

Het is mij niet helemaal duidelijk wat hiermee bedoelt wordt. In het artikel wordt gesproken over dat het ergens in de CI/CD-pipelines verkeerd gaat. Bedoelen ze scanners die daar de boel in de gaten houden, of scanners op het systeem zelf. Ik verwacht alleen het eerste.

[Pendora]

Ik denk dat je "/s" mist. Ik verwacht het aantal virusscanners op Linux vrij laag.

[Martinspire]

En je hebt ook een boel mensen die denken dat ze het allemaal wel beter weten en niks gebruiken. Sure de kans dat je hem niet nodig hebt is 99,99%, maar voor die 0,01% dat je toch niet zit op te letten of niet bekend met hoe iets werkt, gaat het al snel heel hard.

Zeker nu advertenties met de meest gore praktijken worden toegepast en AI allerlei lekken aan het ontdekken is, moet je toch echt wel een paar extra maatregelen nemen om te zorgen dat je niet zomaar slachtoffer bent. Vooral als je dus dingen beheert en belangrijke zaken op je machine doet, is session-hijacking echt wel een legitieme aanvalsvector.

[Reactie gewijzigd door Martinspire op 2 juni 2026 17:32]

[fuzzyIon]

Nee gelukkig qubesos

[lvdgraaff]

offtopic:
Mooie stock foto van Microsoft van iemand die duidelijk Mac OS X gebruikt. Beeldscherm op stapel boeken is ook mooi detail.