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.

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

Door Tijs Hofmans

Nieuwscoördinator

15-07-2026 • 11:50

73

Submitter: topper007

Reacties (73)

Sorteer op:

Weergave:

Timing is niet handig. De bezetting op IT is laag, en Windows updates staan er nou niet bekend om dat dit geen gedoe oplevert.
Lage bezetting is geen reden. De timing is al jaren bekend. Je weet dat de 2de dinsdag van Juli en Augustus een update komt. Daar moet je op voorbereid zijn, zeker als je bedrijf nu onder de cbw valt.

Het is zelfs eerder zo dat deze timing niet meer houdbaar is. 1x per maand is veel te traag aan het worden. Microsoft moet bijna wel ook naar een 2 wekelijkse of misschien wel wekelijkse patch ronde gaan. De geruchten hierover doen al de ronde.

Wen dus maar vast aan dat idee, zeker ook omdat de cbw stuurt naar risico sturing (en daarmee ook risico sturing op patch installatie)

[Reactie gewijzigd door SunnieNL op 15 juli 2026 14:39]

Eigenlijk is die tweewekelijkse ronde er al met de tussentijdse preview waarvan ik nooit problemen heb ondervonden.
Dat is niet 2-wekelijks, want die tussentijdse review bevat groot deel van de patch tuesday er na. Die is voor het testen bedoelt, zodat je op patch tuesday niet tegen problemen loopt.

Dus uiteindelijk is die ook maandelijks.
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.
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
Het punt is vooral de gevolgen van kapotte patches / onvoorziene zaken waar je als IT-organisatie dan mee te maken hebt.
Dat is zeker een risico en daar moet je het gesprek zeker over voeren. De aandacht zou moeten verschuiven naar hoe je snel kunt herstellen van een fout in een patch dan naar het uitstellen van patches.

De winst is dan tweeledig, je bent eerder veilig en je wordtgedwongen je afhankelijkheden en processen beter in kaart te brengen en eerder te fixen. Ofwel, tech debt wordt minder.

Initieel is het waarschijnlijk ruk omdat er best veel tijd gaat zitten omdit goed neer te zetten en daar best iets mis kan gaan. Maar ja zonder wrijving geen glans.
Precies, de keuze is aan de organisatie om wel of geen risico te lopen.
De beheerder bepaalt dat niet, die voert uit en maakt geen beleid.
Sorry maar ik loop al >26 jaar rond in de IT en durf best te stellen dat de NL’se beheerder veel inbreng heeft in hoe het beleid wordt uitgevoerd. Uiteindelijk is er een beslisser, maar vaak is “een oog koning” en telt het advies of de mening van de beheerder zeer zwaar mee.
600 bugs / security issues open laten voor de vakantieperiode is wat mij betreft nog ernstiger. Aanvallen gebeuren vaak tijdens deze periode.
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.
We praten hier dan ook niet over bugs (want dat aantal wordt niet genoemd), we praten hier om het aantal CVE's dat opgelost is. Daadwerkelijke vulnerabilities. Waarvan tenminste 2 al worden misbruikt in het wild.
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.
Volgens mij hebben de hackers de memo gemist dat je net op vakantie gaat en ze daarom ook maar even moeten wachten.
beter samenzitten om tegelijkertijd op vakantie te gaan lijkt me
Als een IT afdeling hier daadwerkelijk last van heeft, is het aan hen om dit soort patches gewoon tegen te houden in hun domein.
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.
Nee joh, pas in augustus is het echt rustig en natuurlijk rond de kerst. De perfecte momenten voor verveelde jongelui om wat online rottigheid uit te gaan halen.

Je hoeft je niet te haasten met deze updates, maar je moet natuurlijk wel een goede planning hebben voor het hele jaar. Of, als eenmanszaak, de boel lekker uitzetten en in de zon gaan chillen.
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).
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.
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....
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
En wat als de patch juist een lek bevat zoals en verleden ook vaker gebeurt is?
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.
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.
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.
Iets wat niet van te voren bekend is.
In ieder geval geen reden om niet te patchen, wat de vraag irrelevant maakt.

Goed changemanagement heeft altijd een rollback
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 :+
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.
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.
stel die vraag eens aan crowdstrike klanten :+
Appels en peren, Crowdstrike was geen Microsoft update, en gebruikte een methode die eigenlijk alle beveiligings- en beschermingsmechanismen om dit te voorkomen bewust omzeilde, waardoor inderdaad er een zeer hoge impact was.

Bedenk daarbij dat een product als crowdstrike meerdere keren per week (misschien zelfs per dag) updates uitbrengt, die niet te blokkeren waren, maar volautomatisch uitgerold werden, dus zonder goedkeuring van de organisatie waar crowdstrike in gebruik was.

Windows updates zijn, mits goed ingericht, niet te installeren zonder eerst goedkeuring te leveren, hopelijk nadat de CVE's en de KB artikelen gelezen zijn die worden meegeleverd, zodat je een gezonde inschatting kunt doen van risico en mogelijke impact.
Inderdaad wij noemen dat op werk.. niet lullen maar patchen 😇
Dan krijgen we echt iets als
vroeger was alles beter
Als een update weer eens iets neerhaalt.
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?
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.
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.
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.
Krijg je nog wel nachtrust dan?
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.
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.
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]

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.
Opgelost of opgepakt? Gaat jullie infra echt plat als er binnen 1 uur geen oplossing beschikbaar is (aka je schakelt de omgeving uit ivm security issue?). Verder neem ik aan dat een bug in app niet direct een heel groot issue is? Neem aan de je wel meerdere maatregelen hebt om te voorkomen dat het misgaat. Wat als een critical issue een applicatie niet globaal bekend is, wel misbruikt wordt?
Probeer dat eens in een ziekenhuisomgeving...
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.
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.
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.
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.....
Deze updates zetten de standaardrechten op de systeemfolders zoals Favorites weer terug.

(Onhandig als je url's vanuit de Verkenner opent.)
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.
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.
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...
Euh, dan zou ik eerder je installatie/configuratie en hardware eens tegen het licht houden als je serieus zoveel problemen hebt. Kan natuurlijk altijd een keer wat misgaan, maar als het echt vaak voorkomt.

[Reactie gewijzigd door friket op 15 juli 2026 15:12]

Heb al jaren het idee dat Windows security technisch fundamenteel niet goed in elkaar zit.
En dat staaf je op basis van onderbuikgevoel of? Het gebrek aan verdere bronnen en uitleg is vermoedelijk waarom je reactie op 0 staat.
Bwn benieuwd hoeveel problemen dit weer veroorzaakt. Succes gebruikers beta testers }>

Ik blijf nog lekker bij oude versies voorlopig.
Ik merkte gister al wel meer stutters in games die ik voorheen niet had, zal misschien is proberen die update weer terug te draaien en zien wat er gebeurd
Excel staat er niet bij, tewijl bij mij onlangs alle kleuren in de voorwaardelijke opmaak (formules) vanuit het niets waren verdwenen...
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.
Het patchen van een bug kan mogelijk leiden tot het creëren van een of meerdere nieuwe bugs. :-)
Misschien doet een AI aan zelfbehoud. Dus expres nieuwe bugs creëren bij de bugfixes en nieuwe code, zodat hij zelf nuttig blijft en voort blijft bestaan ;)
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?
Met een fatsoenlijk dichtgetimmerd systeem / netwerk zijn de meeste van deze 'fixes' sowieso al niet toereikend en ben je voor de 95% al 'protected'.

Het gaat hier vooral om het gros van de generale computergebruikers waarvan vele windows services en components wagenwijd openstaan. Denk aan veel in en outbound (lokale) toegang, en veel outbound (internet).

[Reactie gewijzigd door Marctraider op 15 juli 2026 15:45]


Om te kunnen reageren moet je ingelogd zijn