Onderzoekers vinden derde vergelijkbare Linux-kernelbug in maand tijd

Opnieuw is er een bug ontdekt in de Linux-kernel die het mogelijk maakt ongeoorloofd adminrechten te krijgen op een systeem. Fragnesia, zoals de bug wordt genoemd, lijkt op Dirty Frag en Copy Fail, die eerder deze maand uitkwamen. Fragnesia treft dezelfde kernelmodules. Eerdere Dirty Frag-patches werken niet, maar mitigaties wel.

Dit nieuws in het kort

• Fragnesia is een bug die vrijwel alle Linux-distro's treft.
• Met Fragnesia is het mogelijk rootrechten te verkrijgen.
• De bug lijkt op Dirty Frag en Copy Fail, die eerder deze maand uitkwamen.
• Dezelfde mitigatie voor Dirty Frag werkt ook voor Fragnesia.

De bug wordt Fragnesia genoemd door de onderzoekers van V12, een securitybedrijf dat AI-agents gebruikt om kwetsbaarheden te vinden. De bug wordt getrackt als CVE-2026-46300.

Met de bug is het mogelijk rechten te verhogen. Een aanvaller die als gewone gebruiker op een systeem zit, kan er eenvoudig rootrechten mee krijgen. Het gaat om een logic-bug in het ESP-in-TCP-subsysteem van de Linux-kernel die het mogelijk maakt willekeurige bytes te schrijven naar een cache van wat normaal gesproken alleen-lezen-bestanden horen te zijn. Daardoor is het mogelijk het cachegeheugen te corrumperen en een shell met roottoegang te krijgen. Daarbij is, net als bij eerdere kernelexploits, geen race condition nodig.

De ontdekkers hebben een proof-of-concept online gezet, waardoor het relatief eenvoudig is de bug praktisch uit te buiten. Enigszins opvallend is dat de ontdekkers niet schrijven hoe hun responsible-disclosureproces is gelopen, en gezien de link met eerdere bugs lijkt het erop dat de bug pas recent is ontdekt en OS-makers dus weinig tijd kunnen hebben gehad om de bug te repareren. De bug treft vrijwel alle distro's, waarvan veel zoals Ubuntu en AlmaLinux inmiddels eigen blogs hebben schreven en in sommige gevallen alsnog een patch hebben doorgevoerd.

De bug is niet los te zien van Dirty Frag, een kernelbug die eerder deze maand in het nieuws kwam. Er zijn een paar verschillen; zo bestaat Dirty Frag uit twee verschillende bugs die aan elkaar moeten worden geregen en is Fragnesia slechts één bug. Tegelijkertijd zeggen de makers dat de bugs dezelfde kernelprocessen treffen.

Daardoor is dezelfde mitigatie als die voor Dirty Frag ook van toepassing op Fragnesia. Gebruikers die esp4, esp6 en rxrpc uitschakelen, zijn niet kwetsbaar. Volgens de ontdekkers zijn verder alle kernelversies kwetsbaar die vóór 13 mei van dit jaar uitkwamen.

Reacties (71)

[nielsdc]

Dit is geen logic-bug in het ESP-in-TCP-subsysteem, maar een bug in de netwerk core (skb_try_coalesce). Die verwijderd de shared frag vlag in sommige gevallen. ESP-in-TCP checkt die vlag en doet een in place decrypt als de vlag niet gezet is.

[HollowGamer]

Een reminder om dit niet te gaan testen op je (productie) machines! Test deze exploits gewoon in een VM (je kunt zelfs een clone maken van je huidige setup), want random scripts uitvoeren moet echt een no-go zijn (in mijn optiek dan).

Secureblue heeft deze al voor mij uitgezet, maar op Fedora CoreOS heb ik nog weinig activiteiten gezien. Hoe zit dit met CentOS en andere distros?

[Scribe]

Net voordat ik las zag ik bij Phoronix dat er weer een nieuwe vulnerability bijgekomen is... Mythos draait overuren

[d3vlin]

Voor de liefhebbers ook gelijk de vierde:
https://www.phoronix.com/news/Linux-ssh-keysign-pwn

Update: en de fix daarvoor is er ook al:
https://www.phoronix.com/news/Linux-7.0.8-Released

[Reactie gewijzigd door d3vlin op 15 mei 2026 18:59]

[sigio]

Yup, het gaat hard, ik heb het patchen maar geprobeerd een beetje te stroomlijnen met een ansible role. Deze fix zit er ook meteen in https://github.com/sigio/mitigations

[HollowGamer]

Opzicht ook positief, gelukkig komen deze upstream terecht en niet in de darknet.

Hopelijk worden updates z.s.m. uitgevoerd. System admins zijn niet zo happig op updates (generaliserend gezegd): 'Een nieuwe kernel update? Nee, te veel gedoe - we blokkeren de modules wel.'

Je kunt beide gewoon doen. Dan heb je een fix voor de exploits (dus ook openssh upgraden) en je schakelt onnodige modules/settings uit. Helaas gok ik dat veel eigenwijs zijn, en echt alleen het laatste doen (want nieuw - breekt altijd iets gedachte). Dit zie je vooral terug in de Debian mindset, waar zeker iets voor te zeggen is, maar misschien containers en VMs beter opties/toevoegingen kunnen zijn..

[Reactie gewijzigd door HollowGamer op 15 mei 2026 12:52]

[Zezura]

Nah, in mijn homelab doe ik liever

~ Apt upgrade.

Enige vervelende vind ik het overgaan naar een nieuwe versie van de distro, zoals naar Trixie. Daar houdt ik wel vaak mijn hart bij vast. Op zo’n moment kies ik er vaak voor om de setup opnieuw te installeren.

[himlims_]

De stappen goed volgen, mits geen rare configuratie gaat dat prima. Heb bakken gehad die van 8>9>10 etc zijn gegaan. Debian is best solide daar in

[GeroldM]

Het besturingssysteem, Ubuntu Server LTSin mijn geval, is inderdaad wel te migreren naar een nieuwe versie. De extra software voor de taak van de server, die overleeft de migratie over het algemeen niet. Is mijn ervaring ermee.

Vandaar dat ik altijd alle instructies, commando's en keuzes vastleg voor herinstallatie van de taak. En als we dan toch bezig zijn, installeer dan ook maar het nieuwe besturingssysteem, een verse start i.p.v. eventuele overgehevelde ellende met een migratie.

In het geval van Ubuntu Server LTS dien je elke 5 jaar je server opnieuw op te zetten. Is niet eens zo'n slechte interval om taken/zaken te beoordelen of ze wel/niet nodig zijn, uitgebreid moeten worden of juist het omgekeerde, enz. En ja, ik weet dat je 10 jaar ondersteuning af kunt kopen bij Canonical

Met de vastlegging van alle instructies is het heropzetten van een server wel een stuk makkelijker en in het overgrote deel ook simpel te automatiseren via scripts/Ansible i.p.v. dure AI tokens.

[Grompoe]

Is er fysieke toegang nodig of kan dit ook op afstand worden uitgevoerd?
Nu net 2 weken op Linux dus ben nog zoekende hoe alles werkt. Maar CachyOS heeft dagelijks updates dus dat werkt wel fijn

[Goldwing1973]

Op het moment dat je SSH open zet naar het internet en je iemand een account heb gegeven zodat die kan inloggen via SSH, dan zou iemand remote deze exploit kunnen gebruiken.

Staat je PC gewoon achter de router zonder open poorten naar het internet hoef je je geen zorgen te maken.

[Dreamvoid]

Je kan er tegenwoordig beter van uit gaan dat er minstens 1 apparaat op je lokale netwerk al deel is van een botnet. Een televisie, een telefoon, een speaker, een router, etc.

Het idee dat je achter een firewall veilig bent is al jaren achterhaald.

[Reactie gewijzigd door Dreamvoid op 15 mei 2026 12:50]

[Webgnome]

is het niet mogelijk om via via alsnog toegang te krijgen. Stel je hebt een nodejs omgeving en tijdens deploy worden packages geinstalleerd waarbij in 1 van de packages code zit die op de cli moet worden uitgevoerd dan zou het theoretisch toch kunnen om hier misbruik van te maken?

[Defspace]

Zeker, als jij zelf (onbewust) malware code uitvoert dan ben je vatbaar. Sowieso zo snel mogelijk patchen dus of die modules uitschakelen.

[readefries]

Dit is ook een local privilege escalation, net als de andere twee.

[marktweakt]

Het is een 'privilege escalation' exploit waardoor je eerst al toegang moet hebben tot het systeem. Dat kan lokaal of remote zijn denk ik.

[Nickname55]

Zoals de anderen al schrijven: het kan via SSH toegang. Maar als je dat niet ingeschakeld hebt, of je hebt geen poorten open gezet in je router, dan zit je veilig. Waarschijnlijk staat de SSH server op CachyOS standaard uit.

Verder: voer geen scripts of commando's uit vanuit onbekende bron. Dat is sowieso nooit verstandig. Maar met zulke bugs al helemaal niet.

[Reactie gewijzigd door Nickname55 op 15 mei 2026 11:24]

[Erwin1985]

Dit is een serieus goede use-case voor AI agents. De source code bases van sommige projecten is zo groot geworden (net als het verloop van programmeurs) dat niemand meer als 1 persoon de code "in zijn hoofd heeft". LLM (?) modellen die een geavanceerde versie van static analysis doen kunnen een vervanging zijn hiervoor.

Voor wie geen c programmeur is: https://www.google.com/search?q=c+static+analysis

[Reactie gewijzigd door Erwin1985 op 15 mei 2026 10:46]

[MrFax]

Het nadeel van het bestaan van deze AI agents is wel dat het vinden van kwetsbaarheden heel veel last legt op de developers van al deze open source software, want AI agents zijn beter in het vinden van kwetsbaarheden dan het (bugvrij) dichten van kwetsbaarheden, en daardoor moet de software wel eerst weer volledig getest worden na zo'n fix. Dit kan niet volledig door AI worden overgenomen, wat zorgt voor een enorme druk op developers en testers.

[Reactie gewijzigd door MrFax op 15 mei 2026 11:07]

[MueR]

Om nog maar te zwijgen van alle "security researchers" die talloze PRs op je afschieten met LLM generated onzin, waar jij als maintainer tijd aan moet spenderen.

[dutchruler]

Jou job als 'maintainer' gaat sowieso veranderen. Dat gaat binnenkort echt niet meer met de hand.
Het wordt een kwestie van agent <--> agent in een vrijwel closed loop om de software zo te optimaliseren en efficient te maken dat jij als maintainer or developer de code straks vrijwel niet meer kan herkennen.

Ik zie dat in mijn eigen projecten al waar de AI dagen bezig is met 200k regels aangepast. En ja ik heb het nagelopen en het is stukken beter dan als ik het zelf had gedaan.

[Iced Maggot]

Daar zou ik nou niet zo blind op vertrouwen, zoals je stelt.

Goed dat je uw code hebt nagelopen. Review is mijn inziens altijd nodig. Je gaat zoiets toch niet blindelings inchecken en naar productie omgeving brengen.

[dutchruler]

Het gaat hier om in-house software en wordt gecoverd met unit tests en SIT tests.
En ja uiteraard kijk ik het wel na, maar de software is nu al veel te complex om dat puur handmatig te doen.

Je praat over meer dan een miljoen regels code.

[CAPSLOCK2000]

Daar zou ik nou niet zo blind op vertrouwen, zoals je stelt.

Goed dat je uw code hebt nagelopen. Review is mijn inziens altijd nodig. Je gaat zoiets toch niet blindelings inchecken en naar productie omgeving brengen.

Nee, niet blindelings maar pas als alle bots hun controles hebben gedaan en de code hebben goedgekeurd.

Doen die bots het beter dan professionele menselijke testers? Geen idee, die heb ik niet, ik heb alleen mijzelf. Ik weet zeker dat die bots beter programmeren en debuggen dan ik het zelf kan.

Als ik in een kerncentrale of ziekenhuis zou werken dan zou ik meer mensen in de loop willen hebben, maar voor mijn eigen projectjes vertrouw ik grotendeels op bots. Ik geef richting en doe wat sanity checks en controleer de tests, maar ik ben gewoon niet goed genoeg om fouten sneller te vinden of op te lossen dan de AI. Als er wel iets fout gaat is het eigenlijk altijd efficienter om de AI naar de bug te laten zoeken.

Misschien zou iemand als ik geen software moeten schrijven en/of die niet op internet aansluiten, maar die trein is al lang en breed vertrokken.

[demianmonteverd]

Geen idee wat je doet, maar weet je zeker dat je het zelf niet beter zou hebben gedaan? Qua tempo kan ik er iets bij indenken hoor, daar niet van. Ben zelf al geruime tijd bezig met LLM's en alles eromheen (eerst lokaal alleen en nu lokaal en via SOTA modellen), maar heb eigenlijk nog geen output gezien waar ik van om ga vallen, wel veel slordige functies die elders al bestaan, etc.. Sterker, als je een beetje goed met die tools wil kunnen werken is het echt een zaak om goede plans op te stellen en enorme stukken voor te kauwen qua wat de tooling vaak noemt 'shape' (veel SOTA tooling reageert positief op dat woord trouwens, dus ik gebruik het ook vaker).

Kan ook een kwestie zijn van wat je maakt, stukjes powershell bijv. kan ik beter aan de LLM's overlaten aangezien ik niet bekend genoeg ben met de mogelijkheden/etc..

[dutchruler]

Dat was wellicht zo, maar nu met GPT 5.5 op xhigh en de goal optie in codex is het speelveld sterk veranderd.

Ik doe voornamelijk .NET en c# projecten en de code die nu geschreven wordt door de AI is gewoon uitstekend.

[demianmonteverd]

Bedankt voor je reactie. Heb 5.5 getest toen het uitkwam, maar het is nog steeds niet beter dan wat de wat meer ervaren developers zelf schrijven (of kunnen schrijven, zou meer van toepassing zijn). Een positieve uitzondering vond ik het werken met 5.5 in/met php, met name voor wp projecten.

De goal functionaliteit heb ik niet getest. Dus misschien moeten we dat nog een keer proberen.

[dutchruler]

Mijn ervaring is dat het meer afhangt van de vragen en tussentijdse sturing die je doet.
Ik merk dat het soms nog wel eens een zetje nodig heeft in een bepaalde richting of dat het nog niet altijd even goed is met het out-of-the-box denken.

Maar naar wat porren gaat het weer lekker. Ik kan als enkele developer zo meerdere agents tegelijk aansturen zonder het overzicht te verliezen en doe nu in een dag wat we zelf zeker meerdere maanden had geduurd.

[demianmonteverd]

Heb al vaker geschreven hoe ik prompts maak, komt erop neer dat voor grotere changes, het uitwerken waar en hoe de changes eruit moeten komen te zien, schets van de layouts van de code (plug voor tilth, mooie tool voor dat soort werk). En dan toevoegen van voorbeelden. Positieve voorbeelden werken vaak beter bij grotere changes. Dan splitsen in taken op disk. Maken van checklist. En dan prompt met verwijzing naar het doel, eerste eerste taak, de schets, voorbeelden en de checklist. Heb niet het idee dat het een skill issue is, maar ik zal het moeten accepteren dat mensen dat toch denken

[dutchruler]

Mijn ervaring is hoe minder details hoe beter.
De details zitten bij mij in de agent.md en de project documentatie.

Voor nieuwe functionaliteit toevoegen is het meestal een kwestie van gewoon vragen wat je wil. En wat ik daarna dan vaak doe is met codex de useBrowser skill of in claude cl Chrome playwright gebruiken voor front-end dingen en dan samen alles met de agent doorlopen. Beetje UAT maar dan met agents.

Werkt tot nu erg lekker voor mij zo.

[demianmonteverd]

Ik denk dat je dan in een project werkt waar je de code al in een structuur hebt die 'begrepen' is door de LLM, zodat de LLM dan gewoon zijn werk kan uitzoeken aan de hand van de bestaande patronen of wellicht lijkt je structuur veel op wat er in de trainingsdata veel voorkomt, waarschijnlijk hetzelfde als waarom 5.5 wel goed ging met wordpress.

[dutchruler]

Niet echt. Dit is een zelf geschreven front en back end app waar ik al meer dan 4 jaar mee bezig ben.
En ik moet zeggen dat de sinds december vorig jaar er echt grote stappen zijn gemaakt dat ik meer functionaliteit en stabielere software heb in 6 maanden dan in die 4 jaar eerder.

[Transportman]

Maar wat gaat dat op termijn voor projecten betekenen? Hoe gaan we maintainers gemotiveerd houden om betrokken te blijven als alle code toch door AI geschreven wordt? Nieuwe mensen trekken om projecten te ondersteunen? Ik denk dat heel veel projecten, zowel OSS als closed source bedrijven, het deksel nog wel op de neus gaan krijgen als ze nu vol op AI gaan inzetten.

[dutchruler]

Waarom zou je maintainers gemotiveerd willen houden als het toch door AI wordt gedaan.
De enige afweging zou moeten zijn. Zijn maintainers kwalitatief nog steeds beter dan AI. Zodra dit nee is kan je die maintainer tak wel afhakken.

Ik denk dat er wel nog een kleine groep over zal blijven als gatekeeper's om te zorgen dat er niet te veel rare dingen gebeuren, maar dit zal nog maar een fractie zijn van de mensen die nu nodig zijn.

Opensource zal ook gaan veranderen hierdoor, want de AI kan toch vrijwel alles depersonalized maken voor de klant.

[batjes]

nvm

[Reactie gewijzigd door batjes op 15 mei 2026 14:27]

[FreezeXJ]

What is created by LLM can be handled by LLM.

Keurig laten analyseren door een eigen agent, en alleen als die er iets in ziet gaat een mens er tijd aan besteden. Anders autoreply 'our AI decided your AI sucks', en klaar.

[uiltje]

Wat is dat nou weer voor onzin? Het vinden van een bug, het verifiëren ervan en het er uit halen van een bug zijn echt fundamenteel verschillende dingen en dit gaat ook over verschillende gedeelten van de software. Soms zal een LLM het kunnen, soms niet, en dat geldt voor alle drie.

[Reactie gewijzigd door uiltje op 15 mei 2026 14:43]

[CAPSLOCK2000]

Wat is dat nou weer voor onzin? Het vinden van een bug, het verifiëren ervan en het er uit halen van een bug zijn echt fundamenteel verschillende dingen en dit gaat ook over verschillende gedeelten van de software. Soms zal een LLM het kunnen, soms niet, en dat geldt voor alle drie.

Het is helemaal geen onzin maar gewoon een moderne werkwijze. Het klopt dat LLMs niet alles vinden, maar dat doen mensen ook niet.

Als mens kun je gewoon niet op tegen de hoeveelheid werk die een LLM kan verzetten, of het nu klopt of niet. Als de mens overwelmt wordt door teveel meldingen dan zullen de meldingen op een of andere manier geprioritiseerd moeten worden. Een LLM kan daar prima bij helpen. Die LLM zal ook fouten maken, maar dat is beter dan meldingen helemaal negeren. Als het echt dringend is kan de melder ook aandringen om nog een tweede keer naar een bug te kijken.

Met mail (spam) doen we het al heel lang zo. Dat is verre van foutloos ("kijk eens in je spam" is niet voor niets een gevleugelde uitspraak) maar het is een werkbaar compromis.

[uiltje]

Ik reageer op een uitspraak dat als een LLM wat kan vinden dat het ding het ook op kan lossen.

[dasiro]

Niemand verplicht je om software opensource te maken tenzij je er zelf voor kiest, bvb door andere OSS software te gebruiken. Als je iets met de wereld deelt, dan is het logisch dat de wereld er ook op reageert.

[Eusebius]

Komen we op een gegeven moment niet op een punt dat je nieuwe code eerst door een LLM haalt en voor publicatie / bij beta al op mogelijke fouten wordt gewezen? Net zoals een spell checker in Word je allerlei suggesties geeft en je woorden kunt negeren, toevoegen of verbeteren.

[SunnieNL]

Dat punt en die tools bestaan al even. Die worden ook geüpdatet en uitgebreid met dezelfde llm van de tools die deze gaten vinden.

Of iedereen er voor wilt betalen is een ander ding.

Testen verschuift ook deels naar developers. Die doe de tests eerst op feature niveau. Software Testers en security testers doen dat vervolgens op het gehele product.

[Reactie gewijzigd door SunnieNL op 15 mei 2026 12:35]

[demianmonteverd]

Het kan zeker geen kwaad om de code ook nog een keer door een LLM te halen in een andere sessie. En nog beter idee om je prompts / plans eerst uitgebreid te laten analyseren door LLM's om gaten op te sporen in je prompt. Dat is enorm belangrijk voor het juiste gebruik van LLM's omdat deze geen kennis hebben van de omgeving waarin je de software gaat gebruiken. De reasoning traces lezen is soms ook een goed idee als je twijfelt aan een plan, kun je meteen zien waar iets de mist in zou kunnen gaan, helaas kost dit wel tijd natuurlijk.

[david-v]

Tja, hoe minder je test hoe minder bugs je gaat vinden. Als je teveel test krijgt je developers team het heel druk met bugs oplossen. Dit is niet anders maar dan security bugs. Ik zie het niet als een nadeel maar juist als een wakeup call dat er meer gedaan moet worden aan security bugs, anders blijven we achter de feiten lopen. Als je test straat goed is ingericht met unittests, regressietesten, statische en dynamische code tests dan heb je een stuk minder handmatig testwerk. AI kan niet alleen de bugs vinden maar ook suggesties geven voor het oplossen hiervan. AI eenzijdig inzetten, of het nou voor coderen is of voor het vinden van (security) bugs lijkt me geen goeie strategie.

[GeroldM]

Hebben de personen die de huidige LLMs hebben zitten trainen dan niet de verkeerde keuze gemaakt door zich te richten op veel computer code i.p.v. kwalitatieve code, zoals je die tegenkomt in de (militaire) luchtvaart, apparaten in ziekenhuizen enz?

Software die hardware aanstuurt welke niet mag falen, i.p.v. alles en iedereen op GitHub? Want dat staat vol met net zoveel uitstekende code als met frot.

Met eerdergenomende soort software kun je zeker zijn dat code gesaniteerd is en niet op hol slaan als deze onverwachte/incorrecte input moeten verwerken.

Dat nivo had dan op ieders codebase in GitHub losgelaten kunnen worden en had het een sterke indicatie geweest welke projecten daar uberhaupt de moeite waard zijn en welke niet.

Dan was security ook een minder groot probleem geweest. In mijn gedachtengang tenminste.

[slowdive]

Voor de toekomst betekend dat dat developers security echt serieus moeten gaan nemen, eventueel ondersteund door ai. Anders doen onethische hackers dat wel (niet in de toekomst, maar nu).

"Security first" lijkt me een gepast credo voor developers. Functionaliteit is dus ondergeschikt aan veiligheid. Voor fysieke tools vinden we dat overigens heel gewoon.

Niemand wil geëlektrocuteerd worden door de broodrooster, hoe lekker de toast ook is.

[blackSP]

Noblesse oblige.

Als jij, of je team/bedrijf de (te grote/complexe) code base niet volledig onder controle hebt en AI, of een persoon, kwetsbaarheden ontdekt zal je aan de bak moeten. Feature dev stop, probleem oplossen. Klinkt makkelijker gezegd dan gedaan natuurlijk maar ik ben als C programmeur ondertussen blij met AI als co-developer, bug en leak finder en fixer. Ik gebruik een mix van Gemini 3.1 Pro, Qwen 3.6 lokaal en eventueel een derde model om AI fixes te valideren waarna ik alles test, overgebleven of issues analyseer, oplossingen bedenk en de resultaten weer door m'n AI proces haal.

[Vogel666]

Vind je?

Ik denk dat AI juist een groot aantal van dit soort exploit mogelijkheden gaat toevoegen in de code.

Want als het werkt is het voldoende...lijkt het AI devies.

Zo lang AI zich in één vragenlijn van 15 minuten nog nog een keer of 8 moet ver-excuseren dat het zojuist onzin uitgekraamd heeft, zie ik nog niet echt waarom iemand er iets mee te maken wil hebben.

[Reactie gewijzigd door Vogel666 op 15 mei 2026 14:44]

[fedaykin]

Ik heb me niet heel ver ingelezen in de technieken achter deze vunerabilities, weet een low level tweaker of dit soort problemen vaker opgelost kunnen worden met stukken kritieke code over te brengen naar Rust?

[Stetsed]

Hey, lokale linux/rust tweaker.

Nee, de meeste van dit soort bugs zouden niet zijn opgelost omdat ze geen memory bugs zijn, maar logic bugs. Dit betekent dat het niet zoals veel exploits die je ziet en die rust voorkomt bijvoorbeeld buffer-overflow, maar dat het gewoon puur de logica is die fout is. (Dit geldt teminste voor Copy Fail en Dirty Frag, ik heb me nog niet ingelezen naar deze exploit).

Rust kan dit soort dingen ook niet voorkomen, dat kan geen enkele taal eigenlijk. Het is eigenlijk alsof je in een web app de hele database opvraagt en die aan de user laat zien, het maakt niet uit in welke taal je het doet, als de logica hetzelfde is zal het dezelfde problemen hebben.

Dit is ook waarom ze zo gevaarlijk zijn, want het is vaak niet nodig zoals met veel memory vulnerabilities dat je de kans loopt wanneer je in de kernel speelt dat je de machine bijvoorbeeld crasht. Wat het veel makelijker maakt om onbekend te blijven. En het betekent ook dat ze veel consistenter zijn

[Reactie gewijzigd door Stetsed op 15 mei 2026 10:59]

[zenlord]

Geen idee of deze problemen zich met Rust niet zouden stellen, maar het ziet er naar uit dat SE Linux aanzetten minstens 3 van de 4 deze maand gerapporteerde vulnerabilities onklaar zou maken: https://etbe.coker.com.au/2026/05/15/debian-selinux-ssh-keysign-pwn/ (minstens op Debian Trixie)

Of Mythos nu eerder mythe is of ons werkelijk schrik moet doen krijgen, laat ik in het midden, maar ik heb alvast beslist om SE Linux op al m'n servers te implementeren.

[svennd]

Enkel in strict mode dan, want de vorige 2 gingen vlotjes met selinux aan. Uiteraard helpt selinux, en zeker bij chains van exploits is er kans dat selinux ingrijpt. (deze vereisen allemaal een lokale user)

[deadinspace]

9 december 2025: CVE-2025-64669 (MS informatie):

Improper access control in Windows Admin Center allows an authorized attacker to elevate privileges locally.

10 februari 2026: CVE-2026-21250 (MS informatie, tweakers.net artikel):

Untrusted pointer dereference in Windows HTTP.sys allows an authorized attacker to elevate privileges locally.

17 februari 2026: CVE-2026-26119 (MS informatie):

Improper authentication in Windows Admin Center allows an authorized attacker to elevate privileges over a network.

4 april 2026: CVE-2026-27910 (MS informatie):

Improper handling of insufficient permissions or privileges in Windows Installer allows an authorized attacker to elevate privileges locally.

15 april 2026: RedSun (geen CVE-registratie):

RedSun is a zero-day local privilege escalation (LPE) vulnerability in Microsoft Defender. It allows a low-privileged user to gain full SYSTEM-level access on Windows without any kernel exploit or administrator interaction. What makes RedSun especially dangerous is that it weaponizes a trusted, always-on security component. Most enterprise environments have Defender running continuously, making the attack surface universal across unpatched Windows fleets.

Inmiddels stilletjes gepatcht door MS, maar MS weigert een officiele CVE-registratie of aankondiging te maken. Meer details op deze blog of in de comments van dit tweakers.net artikel (ctrl-F redsun).

12 mei: CVE-2026-35433 (MS informatie):

Improper input validation in .NET allows an unauthorized attacker to elevate privileges locally.

12 mei: YellowKey unpatched ((nog) geen CVE-registratie, tweakers.net artikel):

Een vrijgegeven hacktool maakt het mogelijk om de BitLocker-versleuteling van Windows te omzeilen en toegang tot opgeslagen gegevens te krijgen. [...] Daarbij stelt deze hacker dat het een bewuste backdoor in Windows lijkt te zijn.

12 mei: GreenPlasma unpatched ((nog) geen CVE-registratie, tweakers.net artikel):

Naast YellowKey geeft Nightmare-Eclipse nog een zerodaykwetsbaarheid in Windows vrij. Deze heet GreenPlasma en hiervoor is geen exploitcode om er misbruik van te maken. Het gaat om een manier om vanuit het account van een gewone gebruiker op Windows de verregaande systeemrechten te verkrijgen. Deze verhoging van privileges kan meer macht opleveren dan een beheerdersaccount heeft.

Ik hoop dat je Patch Tuesday in de gaten houdt, met je goed ontwikkelde systeem

[Reactie gewijzigd door deadinspace op 15 mei 2026 12:33]

[maurict]

Bij Linux komen worden deze ontdekkingen mede gedaan omdat het open-source is (en AI modellen goed zijn in code scannen).

Mijn verwachting is dat binnen geringe tijd ook grote (en mogelijk nog veel ernstigere) problemen in Windows gevonden gaan worden d.m.v. AI. Het duurt alleen wat langer omdat het closed-source is. Tegen die tijd zijn de grootste problemen in Linux al lang opgelost

[SunnieNL]

Microsoft zal een van de vendors zijn die toegang heeft tot Mythos. Dus deze worden al gevonden en afgehandeld. De vraag is of Microsoft er open in gaat zijn of ze gaat weergeven als 'security fixes' in de maandelijkse releases, zoals apple dat doet.

[Arxonis]

Dan volg je het nieuws rond dit onderwerp zeer slecht. Heel vaak spreekt men over dit.

Gewoon omdat de de marketing zeer goed is om een mooi beeld te behouden rond deze producten betekend het niet dat achter het gordijn er alles even mooi uit ziet.

[mbovenka]

Ik hoop dat dat sarcasme is...

[HollowGamer]

Misschien heeft hij de recente BitLocker exploit nog niet gelezen?

[PolarWolf]

Mja, want Yellow Key en Ghostlock bestaan niet?
Don't put your mouth into motion unless your brain is in gear.

Also: troll.

[Tralapo]

De blog van Ubuntu beschrijft een methode om de modules uit te schakelen en daarna een check of ze nog geladen zijn. Ik heb die check als eerste uitgevoerd op mijn Ubuntu Servers en ze geven allemaal aan NOT LOADED, zonder de modificatie. Standaard lijken deze dus al niet geactiveerd te zijn?

[Delishizu]

Klopt, de modules esp4 en esp6 worden gebruikt voor IPsec dus als je dat niet gebruikt worden ze niet geladen.

[witteveder]

Ik voorzie een wapenwedloop voor het inzetten van AI tools om bugs in software te vinden. Aan de ene kant staan de onderzoekers die bugs zoeken om zo software zo veilig mogelijk te maken en aan de andere kant de 'onderzoekers' die deze bugs willen ontdekken en exploiteren voor allerlei vervelende doeleinden.

[uiltje]

Die wapenwedloop is al een jaar of wat geleden gestart hoor, daar heb je geen glazen bol meer voor nodig.

[keejoz]

Het artikel hier spreekt over Ubuntu, maar andere bronnen (oa Reddit) zeggen dat Ubuntu en Debian niet standaard kwetsbaar zijn vanwege AppArmor.


Uiteraard snap ik dat als Ubuntu dit zelf op hun website deelt dat het waarschijnlijk wel het geval is, maar toch vind ik het bizar.

[Reactie gewijzigd door keejoz op 15 mei 2026 10:51]