Windows krijgt 416 bugfixes in grootste Patch Tuesday-ronde ooit

Microsoft repareert het hoogste aantal kwetsbaarheden ooit tijdens zijn maandelijkse Patch Tuesday-updateronde. Het lost niet minder dan 602 bugs op, waarvan 416 alleen al in Windows. Microsoft gaf eerder aan dat AI het bedrijf helpt om meer bugs te vinden. Die voorspelling lijkt nu uit te komen, hoewel het bedrijf AI nu niet noemt.

Microsoft repareert deze bugs in updates KB5101650 van Windows 11 en KB5099539 voor Windows 10-gebruikers met extended security updates. Microsoft heeft een recordaantal bugs gerepareerd in meerdere softwarepakketten. De meeste bugs zitten in Windows: 416.

Verder heeft Microsoft 82 bugs in Office en nog eens 46 in Edge verholpen.

Software	Aantal bugfixes
Azure	11
Defender	5
Developer Tools	27
Exchange Server	5
Microsoft Edge	46
Office	82
Other	5
SharePoint Server	17
SQL Server	8
Windows	416

Volgens Bleeping Computer gaat het in de meeste gevallen om privilege-escalationbugs. Daarbij kan een aanvaller hogere rechten krijgen op een systeem dan de bedoeling is. Daarnaast repareert de update van juli ook veel remotecode-executionbugs, die potentieel gevaarlijker zijn. Aanvallers kunnen daarmee code op een systeem uitvoeren.

Explosieve stijging

Het aantal gerepareerde bugs stijgt explosief ten opzichte van vorige maand en al helemaal vergeleken met vorig jaar. In juni repareerde Microsoft nog 200 bugs. In juli 2025 verhielp het bedrijf 137 kwetsbaarheden. Het is hoe dan ook met afstand de grootste patchronde van Microsoft ooit.

Hulp van AI-modellen

Microsoft geeft daarvoor geen specifieke verklaring. Tijdens Patch Tuesday komt alleen een KB-patch uit, zonder veel context. Toch is er een duidelijke verklaring voor de gigantische stijging: AI. Microsoft hintte daar eerder deze week al op. Toen gaf het bedrijf al aan dat het per Patch Tuesday-update meer patches wilde uitbrengen.

Dat komt doordat Microsoft inmiddels een eigen AI-model gebruikt, dat Windows en andere software scant op kwetsbaarheden. Andere software en medewerkers verifiëren deze vervolgens.

Kat-en-muisspel

AI-modellen zijn in de securitywereld in opkomst, omdat ze snel veel kwetsbaarheden kunnen vinden. Onder andere Claude Mythos en recente ChatGPT-modellen zijn vooral goed in het vinden van bugs. Daarmee is het decennia oude kat-en-muisspel tussen hackers en beveiligers in een stroomversnelling gekomen. Die eerste groep kan AI-modellen gebruiken om sneller en laagdrempeliger systemen binnen te dringen. Software- en beveiligingsbedrijven moeten daardoor deze tools ook vaker inzetten.

Vermoedelijk helpt Microsofts AI-inzet bij de explosieve stijging van bugfixes. Bron: Curly_Photo/Moment/Getty Images (Beeld ter illustratie)

Reacties (54)

[Mr.Monk]

Timing is niet handig. De bezetting op IT is laag, en Windows updates staan er nou niet bekend om dat dit geen gedoe oplevert.

[hottestbrain]

De timing van een patch release moet in mijn ogen altijd zijn: Zodra het klaar is.

Bewust lekken laten zitten moet de keuze van de beheerder zijn, die een patch ook gewoon kan uitstellen natuurlijk.

[Johnny E]

Uitdaging is dat beheerders traditioneel sterk risicomijdend zijn. Als we die lijn blijven volgen dan ben je als organisatie te lang kwetsbaar.

Ik ben veel meer van de lijn om zo snel mogelijk te patchen en te fixen wat er kapot gaat. Op lange termijn levert dat de meeste winst op. Je verlegt de focus dan naar het gezond houden van je installbase. Dit vraagt echt andere aanpak en alignment met bestuur van je organisatie

[hottestbrain]

Precies, de keuze is aan de organisatie om wel of geen risico te lopen.

[VHware]

Het punt is vooral de gevolgen van kapotte patches / onvoorziene zaken waar je als IT-organisatie dan mee te maken hebt.

[Sjaakys]

600 bugs / security issues open laten voor de vakantieperiode is wat mij betreft nog ernstiger. Aanvallen gebeuren vaak tijdens deze periode.

[PolarBear]

Goed een bug is: als een gebruiker taal x gebruikt, obscure functie y aanzet én tegelijkertijd z doet gaat er iets mis, maar een bug is ook als je met netwerkpakket x een overflow op service y veroorzaakt kan je willekeurige code uitvoeren. Met andere woorden de ene bug is de ander niet en aantallen zeggen weinig. Sterker nog je kan bugs in code hebben die functioneel voor de gebruiker geen verschil maken.

[Rataplan_]

Dus omdat jij / jullie vakantie hebben moeten bugs maar niet gepatcht worden? Heel vreemde opvatting... voor sommige bugs ben ik zelfs van mening dat ze vaker out-of-band patches zouden moeten uitbrengen.

[Goldwing1973]

Volgens mij hebben de hackers de memo gemist dat je net op vakantie gaat en ze daarom ook maar even moeten wachten.

[Tom Vertommen]

beter samenzitten om tegelijkertijd op vakantie te gaan lijkt me

[youridv1]

Als een IT afdeling hier daadwerkelijk last van heeft, is het aan hen om dit soort patches gewoon tegen te houden in hun domein.

[Carlos0_0]

Dus iedereen die updates checked/ uitrolt mag tegelijk op vakantie, bijzonder slecht bedrijf is dat dan.
Updates horen gewoon door te gaan, zoiets moet niet gepauzeerd te worden.

Verder kan je de updates al eerder krijgen als preview update, dus kan er over langere tijd zelfs getest worden al.
Je hoeft het niet naar iedereen in 1 keer te pushen, je kan ook een paar laptops doen en die even monitoren of alles goed blijft gaan.

[Orangelights23]

Als iemand die werkzaam is in de informatiebeveiliging, is dit enorm interessant om te volgen. De wereld qua patch management is enorm aan het veranderen. Zo heeft het CERT uit India een tijd terug gemeld dat overheidsinstanties binnen 12 uur moeten patchen (bron), bijvoorbeeld. Ook het Britse NCSC communiceert actief over de golf aan kwetsbaarheden en dat er snel gepatcht moet worden (bron). Dit moet dan tegelijkertijd weer gecombineerd worden met het feit dat snel patchen niet altijd goed is, denken aan Shai Hulud (bron).

[xCake]

Yep, bij ons in de organisatie zijn we nu het process aan het veranderen zodat critical security tickets binnen één uur opgelost moeten worden... Het is een flinke taak om onze infrastructuur zo neer te zetten dat het daadwerkelijk mogelijk is.

[J_van_Ekris]

Hoe manage je het risico dat de patch de boel sloopt? Binnen een uur heb je nauwelijks tijd om een impact-assessment te doen, laat staan rapportages van anderen af te wachten hoe het bij hun ging. Dit is bijna blind indraaien van patches. Spannend....

[Johnny E]

Of je doet geen impact assessment en je accepteert dat er af en toe iets ‘kapot’ gaat. Liever dat dan een hack, dat kost nl nog veel meer.

Niet alles is kritisch, ik durf zelfs te stellen dat veruit de meeste systemen in een organisatie helemaal nul kritikaliteit hebben.

Daarnaast verschuift de aanpak van vooraf risico mijden naar zorgen dat je het risico, ook van patchen, snel kan mitigeren. In de Windows wereld heb je nu ook hotpatch, waarbij een update zonder reboot kan worden geïnstalleerd.

Dit gaat natuurlijk niet op voor de echt bedrijfs kritische systemen in bijv ziekenhuizen e.d. maar verder zorgt het echt voor voor een shift in denken

[xleeuwx]

En wat als de patch juist een lek bevat zoals en verleden ook vaker gebeurt is?

[oef!]

Er bestaat niet zoiets als zekerheid dus moet je terugvallen op gezond verstand. De kans dat een patch zonder lek is, is groter dan een patch met lek.

[Zenomyscus]

En wat als de patch juist een lek bevat zoals en verleden ook vaker gebeurt is?

Dan heb je nog een uur extra en kun je twee uur aan de gang.

[MarcMK2]

dan mitigeer je iig het eerste lek, zeker als dat een kritiek lek is en begin je daarna met het dichten van het nieuwe lek.

[Marve79]

Je hebt tegenwoordig ook virtual patching in firewalls, die kan gewoon de exploit code detecteren in het netwerkverkeer.

Maar buiten dat, hoeveel systemen zijn daadwerklijk met het internet verbonden dat je ze binnen het uur moet patchen? Lijkt mij nogal overdreven beleid. Het hangt toch puur van de severiteit af en het doelsysteem.

Kijk Netscaler updates installeer ik vaak binnen een dag. Maar een interne SQL server kan ook wel wachten tot de monhtly patching of het moet echt iets heel ernstigs zijn zoals Blaster ofzo destijds.

Ik heb trouwens ook al eens beheerders zien patchen terwijl ze al gehackt waren. Dan schiet het natuurlijk ook niet echt op

[demianmonteverd]

Het filteren op verkeer gaat belangrijker worden, fuzzing i.c.m. met tests ook, filtering op invoer voor alle tools. Formele verificatie van algorithmen (zoals met lean), etc.. Andere wereld, andere tools en prioriteiten.

[walteij]

Principe patch first, fix later. En gewoon een kwestie van risico's inschatten.

Hoe groot is de kans dat de patch echt de boel sloopt (relatief klein) en hoe groot is de kans dat het lek actief misbruikt wordt en je getroffen wordt (afhankelijk van het type organisatie redelijk klein tot extreem groot). Dus dan neem je het risico van een outage door een verkeerde patch voor lief tov een outage door een hack.
Daarnaast hoef je binnen dat uur niet direct alles gepatched te hebben, maar wel de front-facing spullen.

[dasiro]

stel die vraag eens aan crowdstrike klanten

[Vanderaatje]

Inderdaad wij noemen dat op werk.. niet lullen maar patchen 😇

[PolarBear]

Hoe manage je het risico dat de patch de boel sloopt?

Hoe manage dat je infrastructuur gehackt wordt terwijl je bezig met je impact-assessment en de rapportages van andere af te wachten?

[Olaf van der Spek]

Hoe manage je het risico dat de patch de boel sloopt?

Zorgen dat je met een druk op de knop terug kunt naar de vorige versie.

[supersnathan94]

Binnen een uur heb je nauwelijks tijd om een impact-assessment te doen

Met de komst van geavanceerde AI modellen moet je daar of wat van vinden, of gewoon accepteren dat het stuk gaan en fix-forward doen.

Ik ben zelf bezig met een systeem wat dit op push basis actief trieert en pro-actief al gaat kijken wat de impact is en hoe we daar dan verdere patches op maken als het nodig is. Dat is dan voor software dependencies, dus iets minder heftig dan voor grote pakketten zoals het OS en firewalls, maar wel een proces wat we dus opnieuw inrichten om dit veel sneller dan voorheen te kunnen doen.

[imqqmi]

Voor mitigatie hoef je niet altijd een patch te maken, uitzetten van bepaalde functionaliteit is ook een optie, of dichtzetten van een firewall port. Veel software dat met rolling upgrades werkt, werkt met feature flags. Als je de flags bijvoorbeeld in een database hebt zitten kun je dit makkelijk en snel aanpassen zonder een nieuwe versie of vorige versie te moeten uitrollen, wat gepaard kan gaan met database issues of dataverlies. Dan kun je iig de hacking stoppen en later met meer tijd en mankracht overdag de boel goed oplossen.

[jeroen3]

Krijg je nog wel nachtrust dan?

[bzuidgeest]

Niet alles is critical en hij hoeft het niet alleen te doen waarschijnlijk. De meeste IT orgs hebben daar gewoon standby diensten voor verspreid over het personeel. En als je goed ingericht bent is het niet meer dan een paar drukken op de knop en dan rolt het vanzelf uit.

[xleeuwx]

Dan nog is binnen 1 uur een oplossing uitgerold hebben ambitieus en zou bijna zeggen onmogelijk. stel het gebeurt om 2 uur snachts, iemand wordt wakker gebeld, en hij moet er een collega bij bellen want 4 ogen princiepe daarna gaan ze de patch klaarzetten en uitrollen en het liefst eerst nog op een test omgeving, dan is een uur zo voorbij.

Dit is dan nog een ideale scenario aangezien je er vanuit gaat dat beide collega's dan thuis zijn en in de buurt van een computer / laptop. Als het in de avond gebeurt dan kan het wezen dat je eerst 10 minuten bezig bent om bij een computer / laptop in de buurt te komen en in staat bent om iets te doen. Want iemand kan even de hond uitlaten zijn of even naar de supermarkt etc.

[bzuidgeest]

je er vanuit gaat dat beide collega's dan thuis zijn en in de buurt van een computer / laptop

Met een standby dienst is dat gewoon een verplichting voor die collega om klaar te staan in de buurt van een computer. Anders heeft het geen nut. Je krijgt er ook voor betaald daarom.

En we hebben het over kritieke lekken. Die gaan gewoon niet door test heen. Die mitigeer je zodat je de patch niet hoeft te doen (door bv firewall aanpassingen) of installeer je direct. Beter kapot en offline dan gehacked.

Ja een uur is zo voorbij. Maar het is zeker niet onmogelijk. en de 1 uur (die wij ook hebben) is alleen voor de aller kritiekste dingen. Die zijn zeldzaam. Voor veel kritieke lekken telt ook dat ze alleen van toepassing zijn als je op de machine kan aanmelden. Een server omgeven door firewalls waar niemand op mag aanmelden is het gewoon geen kritiek lek voor. Dan is er mitigatie en vervalt de uur deadline. word het een halve dag.

[Reactie gewijzigd door bzuidgeest op 15 juli 2026 13:25]

[Barsonax]

Klinkt alsof iemand dat geroepen heeft die dat zelf niet hoeft te doen. Voordat het door je review, build straat etc heen is ben je al door de tijd heen.

[Johan9711]

Dit word steeds meer een probleem. Ik verwacht dat de aandacht meer gaat verschuiven van patchen naar detectie van exploits omdat dat vaak realistischer is op korte termijn. EDR en MDR worden in deze veranderende AI wereld ineens veel belangrijker.

[telenut]

Probeer dat eens in een ziekenhuisomgeving...

[Orangelights23]

Of de OT, of kritieke infra. Genoeg industrieën waar dit een flinke uitdaging is. Er bestaat tooling en er is ook expertise, maar dat is niet goedkoop.

[Merik]

Met al die supply-chain aanvallen wordt de impact ook wel steeds merkbaarder, ook bij het algemeen publiek dat niet het vliegtuig op kan, of bij de politiek (de niet-technici)

Die categorie vind ik eigenlijk ook de meest zorgwekkende omdat er geen controle op is, achter elk stukje software zit een maintainer die ge-phisht kan worden, waarna bedrijven het risico lopen op malware bij updates, en het alle hens aan dek is.

[Kalief]

Deze updates zetten de standaardrechten op de systeemfolders zoals Favorites weer terug.

(Onhandig als je url's vanuit de Verkenner opent.)

[Globefrotter]

Opvallend dat Microsoft open is over het feit dat ze AI inzet om patches uit te brengen en dat het inmiddels de 'grootste ooit' zijn en dat ik van Apple niets hoor. Is mijn Mac zo veilig dat ik niet ongerust hoef te zijn of heeft Apple een andere strategie?

Mijn Win 10 machine is inmiddels van recente patches voorzien, op mijn Mac Studio zie ik niets vorrbij komen wat op 'patches' lijkt.....

[Tha Render_2]

Dan heb je de artikels waarschijnlijk gemist: Apple says it is releasing updates early in response to AI cybersecurity concerns | Reuters

[dehulk]

Hoeveel gaat deze update weer kapot maken... Afgelopen twee jaar met de introductie van ai om 30% van de code in de updates te laten schrijven en testen is het ruk. De ene out of band naar de andere.

[segil]

dat valt best mee.... in verreweg de gevallen zijn er geen problemen met patching. Slechts een klein aantal heeft last en vaak is dat ook nog eens in een specifieke situatie.
De reden waarom het veel lijkt, is omdat platforms als Tweakers daar veel aandacht aan besteden, waardoor het lijkt dat iedereen last heeft van de onbedoelde bugs. In de praktijk valt dat dus enorm mee.

[dehulk]

Nou dat ben ik totaal niet met je eens, met een volledig on-prem omgeving hebben we mega veel last van de brakke patches en het testen ervan...

[mocem]

Heb al jaren het idee dat Windows security technisch fundamenteel niet goed in elkaar zit.

[thomasv]

En dat staaf je op basis van onderbuikgevoel of? Het gebrek aan verdere bronnen en uitleg is vermoedelijk waarom je reactie op 0 staat.

[computerjunky]

Bwn benieuwd hoeveel problemen dit weer veroorzaakt. Succes gebruikers beta testers

Ik blijf nog lekker bij oude versies voorlopig.

[nutty]

Excel staat er niet bij, tewijl bij mij onlangs alle kleuren in de voorwaardelijke opmaak (formules) vanuit het niets waren verdwenen...

[Mars4i]

Je zou dus verwachten dat dit een korte piek in het aantal bugfixes geeft. Nieuw AI model scant bestaande code en vindt X bugs. Die worden hersteld. En de maand daarna zou je alleen bugs moeten vinden in nieuwe code. Dus dat zou veel minder bugs moeten geven. Of mis ik iets? Hebben ze misschien 10 duizend bugs gevonden en er pas een paar hersteld?

Ik neem ook aan dat verbeteringen in AI modellen ook niet zoveel nieuwe bugs zullen vinden, want de makkelijkst te vinden bugs hebben ze al gevonden met de oudere modellen.

[Martinspire]

Waarom bekruipt mij het idee dat 400 issues hiervan nonsense zijn, maar in theorie misbruikt kunnen worden en met een one-line aanpassing gefixed kunnen worden?