De melding kwam binnen op 1 april

Op 1 april 2026 stuurde Adam Kues van Assetnote, de onderzoekstak van Searchlight Cyber, ServiceNow een rapport waarin hij beschreef hoe je zonder enige inloggegevens code kunt draaien op het ServiceNow AI Platform. Het bedrijf schakelde snel. In het eigen verslag van de disclosure noteert het onderzoeksteam dat ServiceNow "binnen 24 uur na onze melding sterke mitigaties heeft uitgerold op alle cloudinstanties", waarna in de weken erna patches volgden voor de onderliggende problemen. Iedere klant op een door ServiceNow gehoste instantie was begin april beschermd, en niemand van hen hoefde er iets voor te doen of er zelfs maar van te weten.

De klanten die hun eigen kopieën draaien hoorden niets tot 13 juli, de dag waarop ServiceNow advisory KB3137947 publiceerde en updates uitbracht voor self-hosted omgevingen. Het lek staat geregistreerd als CVE-2026-6875. ServiceNow trad op als eigen CNA en gaf het een CVSS 4.0-score van 9,5 op 10. De vector noteert een hoge aanvalscomplexiteit, maar geen rechten en geen gebruikersinteractie, en juist die combinatie maakt een vanaf internet bereikbare instantie interessant voor wie op schaal scant.

Tussen die twee data liggen 103 dagen. Voor een SaaS-bedrijf is dat een keurig gecoördineerde disclosure. Voor dat deel van de klanten dat het platform zelf draait, is het een kwartaal lang een kritiek lek vasthouden dat vóór authenticatie misbruikt kan worden en dat de leverancier op zijn eigen landschap allang had gedicht.

Een sandbox die JavaScript wilde evalueren

De kwetsbaarheid zit in de sandbox van het ServiceNow AI Platform, de laag die platformcode geïsoleerd moet laten draaien zodat die niets bereikt wat buiten bereik hoort te blijven. Het instappunt is de GlideRecord-API, die JavaScript-evaluatie binnen queryfilters ondersteunt. Invoer van de gebruiker kwam terecht in een addQuery-aanroep met het voorvoegsel javascript: ervoor, en daar werd die door het platform geëvalueerd.

Een tweede sandbox was bedoeld om precies dit op te vangen en gevaarlijke functies te blokkeren. De onderzoekers kwamen er langs met een gadgetketen van Object.clone en Class.create.constructor, die samen willekeurige functie-uitvoering tijdens script includes opleveren. Het gedemonstreerde instappunt was het endpoint /assessment_thanks.do via de parameter sysparm_assessable_type, en voor niets daarvan was een login nodig.

Wat een aanvaller daarmee in handen krijgt is geen voetje tussen de deur in een uithoek van het product. De analyse van Searchlight beschrijft het uitlezen van tabellen, het aanmaken van beheerdersaccounts en het draaien van shell-commando's op alle geconfigureerde MID Server-proxy's, die, zoals de onderzoekers opmerken, meestal binnen de interne netwerken van bedrijven staan. De MID Server is het onderdeel dat teruggrijpt in uw eigen landschap om assets te ontdekken en automatisering uit te voeren. Het is de brug, en die brug is vanaf de bug bereikbaar.

Wie het risico werkelijk droeg

In Europese bestuurskamers geldt zelf hosten doorgaans als de voorzichtige keuze. De data blijft op eigen ijzer staan, de vraag over dataresidentie is met één zin beantwoord, en u hoeft een toezichthouder geen ongemakkelijk schema voor te leggen. In gereguleerde sectoren in de EU, bij de overheid, in het bankwezen en bij de grotere Mittelstand-groepen verklaart dat gevoel waarom een flink deel van de ServiceNow-omgevingen niet in de cloud van ServiceNow draait.

Deze advisory zet dat op zijn kop. Wie voor de cloud van de leverancier koos, was in de eerste dagen van april beschermd door een mitigatie waar hij nooit om had hoeven vragen. Wie het uit oogpunt van controle zelf ging draaien, droeg een niet-geauthenticeerd lek voor code-uitvoering op afstand door april, mei, juni en de halve maand juli heen, en kreeg het pas te horen toen de fix klaar was om uit te leveren. Controle over de uitrol bleek in de praktijk eigenaarschap van het blootstellingsvenster te betekenen.

Niets hiervan maakt de aanpak van ServiceNow verkeerd. Mitigaties uitrollen op een landschap dat u zelf beheert gaat nu eenmaal sneller dan patches uitleveren aan een landschap dat u niet beheert, en de details van een advisory achterhouden tot klanten kunnen handelen is staande praktijk en geen doofpot. De les voor de beheerder is smaller en bruikbaarder: "de leverancier heeft het opgelost" en "wij zijn opgelost" zijn twee verschillende uitspraken, en hier zat er honderd dagen tussen.

Beide uitspraken zijn tegelijk waar

In het weekend van 18 en 19 juli meldde de threat-intelligencegroep Defused actief misbruik, met de eerste pogingen op vrijdag 17 juli. De advisory van ServiceNow stelt maandagochtend nog altijd het bedrijf "op dit moment geen weet heeft van misbruik tegen ServiceNow-instanties". Naast elkaar gelegd oogt dat als een leverancier die traag is met toegeven.

Het ligt interessanter, en die verklaring is waar dit verhaal om draait. De twee partijen meten verschillende populaties. ServiceNow heeft directe telemetrie op het landschap dat het zelf host, en daar liggen sinds begin april mitigaties, dus daar wordt werkelijk niets misbruikt. Defused kijkt naar verkeer over het hele internet, en daar staan juist de self-hosted instanties. De populatie die de leverancier niet kan zien is precies de populatie die nog ongepatcht is.

De zin van de leverancier klopt dus, en is tegelijk waardeloos als risico-invoer voor u. "Geen bevestigd misbruik" uit de mond van een SaaS-aanbieder is een uitspraak over het eigen landschap van die aanbieder, tenzij er uitdrukkelijk iets anders bij staat. Draait u de software zelf, dan is de enige misbruikstatus die uw situatie beschrijft de status die u uit uw eigen logs haalt.

De exploit wachtte niet op de proof of concept

Defused was precies over wat het zag. De payloads, zo meldde de groep, "raken dezelfde pre-auth sink die @SLCyberSec heeft gedocumenteerd (/assessment_thanks.do), maar het sandbox-escape-gadget bereikt dezelfde primitieve voor code-uitvoering langs een andere weg dan hun gepubliceerde PoC". Aanvallers speelden de exploit van de onderzoekers dus niet na. Ze waren zelfstandig bij dezelfde primitieve uitgekomen en hadden vanaf hetzelfde startpunt hun eigen werk gedaan.

Dat detail haalt een planningsgewoonte onderuit die veel voorkomt bij organisaties met strak wijzigingsbeheer: het verschijnen van een publieke proof of concept behandelen als het startschot en pas in het eerstvolgende venster daarna patchen. Hier kwam de zelfstandige aanvalscapaciteit gelijk op met de publieke analyse in plaats van erna, en de advisory van 13 juli was de laatste betrouwbare waarschuwing die er nog zou komen.

Wat u voor dinsdag moet controleren

Begin bij de releasefamilie, want de namen van de fixes spreken niet voor zich. De gepatchte versies zijn Brazil EA en Brazil GA, Australia Patch 2, Zurich Patch 7b of Zurich Patch 9, en Yokohama Patch 12 Hot Fix 1b of Yokohama Patch 13. Alles onder de betreffende grens is kwetsbaar, en een self-hosted instantie die sinds 13 juli geen onderhoudsvenster heeft gehad, is door niemand namens u gerepareerd.

Ga er vervolgens van uit dat dat venster ertoe deed. Haal de toegangslogs van /assessment_thanks.do op en kijk specifiek naar de parameter sysparm_assessable_type. Loop het aanmaken van beheerdersaccounts na over de hele periode in plaats van over de laatste twee weken, want het lek stelt een aanvaller in staat er zelf een aan te maken. Ga daarna langs de MID Servers, zoek naar onverwachte procesuitvoering, en houd in gedachten dat die hosts binnen het interne netwerk staan en niet ervoor, want dat is wat een platformbug verandert in een probleem van laterale beweging.

Vindt u iets, dan tikt de klok net zo goed juridisch als technisch. Voor essentiële en belangrijke entiteiten in de EU eist NIS2 binnen 24 uur na kennisname van een significant incident een vroege waarschuwing aan uw nationale CSIRT en binnen 72 uur een uitgebreidere melding. In het Verenigd Koninkrijk, waar NIS2 niet geldt, loopt de melding nog steeds via het NCSC, en het is hetzelfde bewijswerk dat zo'n melding de moeite waard maakt.

Lees hierna: Een verzoek kon uw WordPress-site kapen  |  SharePoint patchen sluit de deur niet meer