Anmeldelsen landede den første april
Den 1. april 2026 sendte Adam Kues fra Assetnote, forskningsgrenen i Searchlight Cyber, ServiceNow en rapport, der beskrev en måde at køre kode på ServiceNow AI Platform helt uden adgangsoplysninger. Virksomheden reagerede hurtigt. I forskerholdets egen beretning om forløbet står der, at ServiceNow "udrullede stærke afbødninger til alle skyinstanser inden for 24 timer efter vores anmeldelse" og fulgte op med patches til de underliggende fejl i ugerne efter. Alle kunder på en instans hostet af ServiceNow var beskyttet ved begyndelsen af april, og ingen af dem behøvede at gøre noget eller så meget som vide det.
De kunder, der kører deres egne kopier, hørte intet før den 13. juli, hvor ServiceNow offentliggjorde sikkerhedsadvarslen KB3137947 og udsendte opdateringer til selvhostede installationer. Sårbarheden føres som CVE-2026-6875. ServiceNow, der optræder som sin egen CNA, tildelte den en CVSS 4.0-score på 9,5 ud af 10. Vektoren angiver høj angrebskompleksitet, men ingen rettigheder og ingen brugerinteraktion, og netop den kombination gør en instans, der kan nås fra internettet, interessant for nogen, der scanner i stor skala.
Mellem de to datoer ligger 103 dage. For et SaaS-selskab er det en velkørt koordineret offentliggørelse. For den del af kunderne, der selv driver platformen, er det et kvart år med en kritisk sårbarhed før autentificering, som leverandøren allerede havde lukket på sin egen bestand.
En sandbox, der indvilligede i at evaluere JavaScript
Sårbarheden sidder i sandboxen i ServiceNow AI Platform, det indeslutningslag, der skal lade platformkode køre uden at nå noget, den ikke bør nå. Indgangen er GlideRecord-API'et, som understøtter evaluering af JavaScript inde i forespørgselsfiltre. Brugerleveret input nåede frem til et addQuery-kald med præfikset javascript:, og platformen evaluerede det.
En sekundær sandbox skulle netop fange dette og blokere farlige funktioner. Forskerne kom uden om den med en gadget-kæde bygget af Object.clone og Class.create.constructor, som tilsammen giver vilkårlig funktionsudførelse under script includes. Den demonstrerede indgang var slutpunktet /assessment_thanks.do via parameteren sysparm_assessable_type, og intet af det krævede login.
Det, en angriber får ud af det, er ikke et fodfæste i en afkrog af produktet. Searchlights gennemgang beskriver udlæsning af data fra tabeller, oprettelse af administratorkonti og kørsel af shell-kommandoer på enhver konfigureret MID Server-proxy, som ifølge forskerne almindeligvis står inde i virksomhedernes interne netværk. MID Server er det led, der rækker tilbage ind i din bestand for at kortlægge aktiver og køre automatisering. Den er broen, og broen kan nås fra fejlen.
Hvem der reelt bar risikoen
Den sædvanlige indskydelse i europæiske bestyrelseslokaler er, at selvhosting er det forsigtige valg. Data bliver på eget jern, spørgsmålet om dataplacering besvares i én sætning, og man slipper for at give en tilsynsmyndighed et pinligt diagram. I regulerede brancher i EU, i den offentlige forvaltning, i banksektoren og blandt de større mellemstore koncerner er det den indskydelse, der forklarer, hvorfor en betydelig del af ServiceNow-bestandene ikke ligger i ServiceNows sky.
Denne sikkerhedsadvarsel vender det på hovedet. De kunder, der valgte leverandørens sky, var beskyttet i de første aprildage af en afbødning, de aldrig behøvede at bede om. De kunder, der valgte selv at drive den for at have kontrollen, bar en ikke-autentificeret fjernkørsel af kode gennem april, maj, juni og det halve juli, og de fik det først at vide, da rettelsen var klar til at blive sendt ud. Kontrol over installationen viste sig at betyde ejerskab over eksponeringsvinduet.
Intet af dette gør ServiceNows håndtering utilbørlig. At udrulle afbødninger til en bestand, man selv driver, er ganske enkelt hurtigere end at få patches ud til en bestand, man ikke driver, og at holde detaljerne tilbage, indtil kunderne kan handle, er gængs praksis snarere end tilsløring. Læren for den driftsansvarlige er snævrere og mere brugbar: "leverandøren har rettet det" og "vi er rettet" er to forskellige udsagn, og her lå der hundrede dage imellem dem.
Begge udsagn er sande på samme tid
I weekenden den 18. og 19. juli meldte trusselsefterretningsgruppen Defused om aktiv udnyttelse, hvor de første forsøg blev observeret fredag den 17. juli. ServiceNows sikkerhedsadvarsel oplyser mandag morgen stadig, at selskabet "ikke på nuværende tidspunkt har kendskab til udnyttelse mod ServiceNow-instanser". Læst side om side ligner det en leverandør, der er langsom til at indrømme noget.
Det er mere interessant end som så, og forklaringen er hele pointen i denne historie. De to parter måler på hver sin population. ServiceNow har direkte telemetri fra den bestand, selskabet selv hoster, og den bestand har været afbødet siden begyndelsen af april, så der bliver reelt ikke udnyttet noget dér. Defused iagttager trafik på tværs af internettet, og det er dér, de selvhostede instanser ligger. Den population, leverandøren ikke kan se, er præcis den, der stadig er upatchet.
Leverandørens sætning er altså korrekt og samtidig ubrugelig som risikoinput for dig. "Ingen bekræftet udnyttelse" fra en SaaS-leverandør er et udsagn om leverandørens egen bestand, medmindre der udtrykkeligt står andet. Driver du selv softwaren, er den eneste udnyttelsesstatus, der beskriver din situation, den, du selv udleder af dine egne logfiler.
Exploitten ventede ikke på et proof of concept
Defused var præcis omkring det, gruppen så. Nyttelasterne, meldte den, "rammer det samme pre-auth-punkt, som @SLCyberSec har dokumenteret (/assessment_thanks.do), men gadgetten til sandbox-udbrud når den samme primitiv til kodeudførelse ad en anden vej end deres offentliggjorte PoC". Angriberne genafspillede ikke forskernes exploit. De havde nået den samme primitiv uafhængigt, efter selv at have gjort arbejdet fra det samme udgangspunkt.
Den detalje river en planlægningsvane fra hinanden, som er udbredt i ændringsstyrede driftsorganisationer: at behandle offentliggørelsen af et proof of concept som det tidspunkt, hvor uret begynder at gå, og så patche i det næste vindue derefter. Her kom den uafhængige kapacitet samtidig med den offentlige analyse i stedet for efter den, og sikkerhedsadvarslen selv, den 13. juli, var den sidste pålidelige advarsel, nogen kom til at få.
Hvad du bør tjekke inden tirsdag
Begynd med release-familien, for navnene på rettelserne er ikke indlysende. De patchede versioner er Brazil EA og Brazil GA, Australia Patch 2, Zurich Patch 7b eller Zurich Patch 9 samt Yokohama Patch 12 Hot Fix 1b eller Yokohama Patch 13. Alt under den relevante grænse er sårbart, og en selvhostet instans, der ikke har haft et vedligeholdelsesvindue siden den 13. juli, er ikke blevet rettet af nogen på dine vegne.
Gå dernæst ud fra, at vinduet betød noget. Træk adgangslogfiler for /assessment_thanks.do og se særligt på parameteren sysparm_assessable_type. Gennemgå oprettelsen af administratorkonti i hele perioden og ikke kun de seneste fjorten dage, for sårbarheden giver en angriber mulighed for at oprette en. Gå så til dine MID Servers, kig efter uventet procesudførelse, og husk, at de værter står inde i det interne netværk og ikke foran det, hvilket er dét, der forvandler en platformfejl til et problem med sideværts bevægelse.
Finder du noget, er uret både regulatorisk og teknisk. For væsentlige og vigtige enheder i EU kræver NIS2 en tidlig varsling til dit nationale CSIRT inden for 24 timer efter, at du er blevet opmærksom på en væsentlig hændelse, og en fyldigere underretning inden for 72 timer. I Storbritannien, hvor NIS2 ikke gælder, er NCSC fortsat anmeldelseskanalen, og det er det samme bevisarbejde, der gør anmeldelsen værd at indgive.
Læs videre: En forespørgsel kunne kapre din WordPress-side | At patche SharePoint lukker ikke længere døren
