Rapporten kom in den första april
Den 1 april 2026 skickade Adam Kues på Assetnote, forskningsgrenen inom Searchlight Cyber, en rapport till ServiceNow som beskrev ett sätt att köra kod på ServiceNow AI Platform helt utan inloggningsuppgifter. Företaget agerade snabbt. I sin egen redogörelse för avslöjandet noterar forskarlaget att ServiceNow "rullade ut kraftfulla begränsningar på samtliga molninstanser inom 24 timmar efter vår rapport" och följde upp med patchar för de underliggande bristerna under veckorna därpå. Varje kund på en instans hostad av ServiceNow var skyddad redan i början av april, utan att behöva göra något eller ens veta om det.
Kunderna som driver egna kopior hörde ingenting förrän den 13 juli, då ServiceNow publicerade säkerhetsmeddelandet KB3137947 och släppte uppdateringar för självhostade installationer. Bristen förs som CVE-2026-6875. ServiceNow tilldelade den i rollen som egen CNA en CVSS 4.0-poäng på 9,5 av 10. Vektorn anger hög angreppskomplexitet men inga behörigheter och ingen användarinteraktion, och det är just den kombinationen som gör en instans nåbar från internet intressant för den som skannar i stor skala.
Mellan de två datumen ligger 103 dagar. För ett SaaS-bolag är det ett välskött samordnat avslöjande. För den del av kunderna som driver plattformen själva är det ett kvartal med en kritisk brist före autentisering som leverantören redan hade stängt i sitt eget bestånd.
En sandbox som gick med på att utvärdera JavaScript
Sårbarheten sitter i sandboxen i ServiceNow AI Platform, det inneslutande lager som ska låta plattformskod köra utan att nå sådant den inte får nå. Ingången är GlideRecord-API:et, som stöder utvärdering av JavaScript inuti frågefilter. Användarlevererad indata nådde ett addQuery-anrop med prefixet javascript:, och plattformen utvärderade det.
En sekundär sandbox skulle fånga precis detta och blockera farliga funktioner. Forskarna tog sig förbi den med en gadgetkedja byggd av Object.clone och Class.create.constructor, som tillsammans ger godtycklig funktionskörning under script includes. Den demonstrerade ingången var slutpunkten /assessment_thanks.do via dess parameter sysparm_assessable_type, och inget av det krävde inloggning.
Det en angripare får ut av detta är inte ett fotfäste i ett hörn av produkten. Searchlights genomgång beskriver utläsning av data ur tabeller, skapande av administratörskonton och körning av skalkommandon på alla konfigurerade MID Server-proxyservrar, som enligt forskarna vanligen står inne i företagens interna nät. MID Server är just den del som når tillbaka in i ditt bestånd för att kartlägga tillgångar och köra automatisering. Den är bron, och bron går att nå från buggen.
Vem som faktiskt bar risken
Den vanliga instinkten i europeiska styrelserum är att självhosting är det försiktiga valet. Data stannar på egen plåt, frågan om datalagringsplats besvaras i en enda mening, och man slipper ge en tillsynsmyndighet ett obekvämt diagram. I reglerade branscher inom EU, i offentlig förvaltning, i banksektorn och bland de större medelstora koncernerna är det den instinkten som förklarar varför en betydande del av ServiceNow-bestånden inte ligger i ServiceNows moln.
Det här säkerhetsmeddelandet vänder på saken. De kunder som valde leverantörens moln var skyddade under aprils första dagar av en åtgärd de aldrig behövde be om. De kunder som valde att driva plattformen själva, för kontrollens skull, bar en icke-autentiserad fjärrkörning av kod genom april, maj, juni och halva juli, och fick veta det först när rättningen var färdig att skickas ut. Kontroll över driften visade sig betyda ägarskap över exponeringsfönstret.
Inget av detta gör ServiceNows hantering otillbörlig. Att rulla ut begränsningar i ett bestånd man själv driver är helt enkelt snabbare än att få ut patchar till ett bestånd man inte driver, och att hålla inne detaljerna tills kunderna kan agera är gängse praxis snarare än mörkläggning. Lärdomen för den driftansvarige är snävare och mer användbar: "leverantören har rättat det" och "vi är rättade" är två olika påståenden, och den här gången låg hundra dagar emellan.
Båda påståendena är sanna samtidigt
Under helgen den 18 och 19 juli rapporterade underrättelsegruppen Defused aktivt utnyttjande, med de första försöken observerade fredagen den 17 juli. ServiceNows säkerhetsmeddelande uppger på måndagsmorgonen fortfarande att bolaget "för närvarande inte känner till något utnyttjande mot ServiceNow-instanser". Lästa sida vid sida ser det ut som en leverantör som är långsam att medge.
Det är mer intressant än så, och sammanjämkningen är hela poängen med den här historien. De två parterna mäter olika populationer. ServiceNow har direkt telemetri över det bestånd bolaget hostar, och det beståndet har varit skyddat sedan början av april, så där utnyttjas faktiskt ingenting. Defused iakttar trafik över hela internet, och det är där de självhostade instanserna finns. Den population leverantören inte kan se är exakt den population som fortfarande är opatchad.
Leverantörens mening är alltså korrekt och samtidigt oanvändbar som riskunderlag för dig. "Inget bekräftat utnyttjande" från en SaaS-leverantör är ett påstående om leverantörens eget bestånd, om inget annat uttryckligen sägs. Driver du programvaran själv är den enda utnyttjandestatus som beskriver din situation den du härleder ur dina egna loggar.
Exploiten väntade inte på någon proof of concept
Defused var tydlig med vad gruppen såg. Nyttolasterna, rapporterade den, "träffar samma pre-auth-sink som @SLCyberSec dokumenterat (/assessment_thanks.do), men gadgeten för sandbox-flykten når samma primitiv för kodkörning via en annan väg än deras publicerade PoC". Angriparna spelade alltså inte upp forskarnas exploit på nytt. De hade nått samma primitiv oberoende, efter eget arbete från samma utgångspunkt.
Den detaljen monterar ned en planeringsvana som är utbredd i ändringsstyrda driftorganisationer: att behandla en offentlig proof of concept som ögonblicket då klockan börjar gå, och patcha i nästa fönster därefter. Här kom den oberoende förmågan samtidigt med den offentliga analysen i stället för efter den, och säkerhetsmeddelandet den 13 juli var i sig den sista tillförlitliga varning någon skulle få.
Vad du bör kontrollera före tisdag
Börja med releasefamiljen, för namnen på rättningarna är inte självklara. De patchade versionerna är Brazil EA och Brazil GA, Australia Patch 2, Zurich Patch 7b eller Zurich Patch 9 samt Yokohama Patch 12 Hot Fix 1b eller Yokohama Patch 13. Allt under den aktuella gränsen är sårbart, och en självhostad instans som inte har haft något underhållsfönster sedan den 13 juli har inte blivit rättad av någon för din räkning.
Utgå därefter från att fönstret spelade roll. Ta fram åtkomstloggarna för /assessment_thanks.do och titta särskilt på parametern sysparm_assessable_type. Gå igenom skapandet av administratörskonton över hela perioden i stället för de senaste två veckorna, eftersom bristen låter en angripare skapa ett sådant konto. Gå sedan till MID-servrarna, leta efter oväntad processkörning, och kom ihåg att de värdarna står inne i det interna nätet i stället för framför det, vilket är det som förvandlar en plattformsbugg till ett problem med sidledes förflyttning.
Hittar du något är klockan lika mycket regulatorisk som teknisk. För väsentliga och viktiga verksamheter inom EU kräver NIS2 en tidig varning till nationell CSIRT inom 24 timmar efter kännedom om en betydande incident och en fylligare underrättelse inom 72 timmar. I Storbritannien, där NIS2 inte gäller, är NCSC fortsatt rapporteringsvägen, och det är samma bevisarbete som gör rapporten värd att lämna in.
Läs vidare: En begäran kunde kapa din WordPress-sajt | Att patcha SharePoint stänger inte längre dörren
