Snilld

Når AI kan finde nul‑dages, hjælper det ikke at vente på næste månedlige patch

Anthropic siger, at Claude Mythos Preview kan opdage tusindvis af zero‑days. Samtidig falder tiden fra CVE‑offentliggørelse til reel udnyttelse til timer. Det betyder, at mange virksomheders patch‑processer er for langsomme i praksis. Vi forklarer hvorfor sikkerhedsmargenen er væk, hvad der bør ændres i prioritering og drift, og hvor automatik og AI både hjælper og kan gå galt.

31. maj 2026 Peter Munkholm

Hvis en angriber kan gå fra advisory til fuld udnyttelse på under et døgn, er et månedligt patch‑vindue ikke en strategi – det er en vane. På få uger har vi fået to klare signaler. 1) University of Illinois viste, at GPT‑4 kan udnytte 87 procent af et kurateret sæt one‑day sårbarheder, hvis den får CVE‑beskrivelsen, men kun 7 procent uden. 2) Anthropic meldte 7. april, at Claude Mythos Preview kan opdage tusindvis af zero‑days selv. Og så den ubehagelige praktiske detalje: konkrete CVE‑cases blev udnyttet på 20 timer og cirka 9 timer og 41 minutter efter offentliggørelse, ifølge VentureBeat, der sammenfatter flere kilder.\n

Billedet er allerede operationelt, ikke teoretisk. Rapid7s 2026‑analyse peger på en median på fem dage fra CVE til CISA KEV‑listing. Google M‑Trends 2026 beskriver udnyttelser før patches overhovedet er frigivet. Den gamle buffer – den margin, sikkerhedsfolk plejede at regne med – er væk.\n

Hvad Anthropic og Mythos påstår\n

VentureBeat gengiver, at Anthropic med Mythos Preview hævder autonomt at have fundet tusindvis af zero‑days på store operativsystemer og browsere. De rapporterer også en score på 83,1 procent på CyberGym‑benchmark for sårbarhedsreproduktion. Og en konkret OpenBSD‑kampagne med 1.000 scaffold‑kørsler, som samlet kostede under 20.000 dollar i compute. Ifølge VentureBeat, som igen refererer Anthropic.\n

Hvis de tal holder, er to ting værd at hæfte sig ved. For det første: opdagelse, ikke kun udnyttelse. Vi kan ikke længere gå ud fra, at AI primært forstærker allerede kendte huller. For det andet: prisen. 20.000 dollar for 1.000 runs er enterprise‑niveau, ikke forskningsfantasi. Inden for rækkevidde for både forsvarere og angribere. I går var det dyrt at automatisere offensiv sikkerhed. I dag er det en budgetpost.\n

Nærbillede af kanarietest‑tag på patchkabel med blinkende alarmled — symbol på canary‑test ved hastepatch.

Hvorfor den gamle antagelse brister\n

University of Illinois’ studie på arXiv forklarede den hidtidige tryghed: 87 procent succes med CVE‑beskrivelsen vs 7 procent uden. Klar forskel mellem knowledge og discovery. AI kunne udnytte, når den fik nøglen i hånden, men den fandt ikke selv låsen. Derfor var mange – ærligt – lidt rolige.\n

Mythos‑påstanden om discovery fjerner fundamentet under den ro. Hvis et system selv kan kortlægge, validere og producere en proof‑of‑concept, ryger antagelsen om reaktionstid i dage eller uger. Vi er fortsat forbeholdne på metode og ønsker et åbent whitepaper. Men kombinationen af dokumenteret korte udnyttelsestider og lav compute‑pris gør problemet praktisk.\n

Beviser for sammenbrud i exploittid\n

VentureBeat peger på to cases: Langflow CVE‑2026‑33017 med CVSS 9,8 blev ramt 20 timer efter advisory, uden offentlig PoC. Marimo CVE‑2026‑39987 med CVSS 9,3 blev ramt efter cirka 9 timer og 41 minutter. Samtidig nævnes Rapid7s median på fem dage fra CVE til CISA KEV og Googles M‑Trends 2026 om udnyttelse før patch. Mønstret genkender vi også i drift: honeypots ser trafik samme døgn, som sårbarheder dukker op i feeds.\n

Der er usikkerheder i tidsstempler: præcist disclosure‑tidspunkt, første verificerede exploit‑observation osv. Men datapunkterne peger samme vej. Fra dage til timer. Fra ventetid til realtid.\n

Banner

Hvad er nyt teknisk set\n

Den store forskel er autonom discovery: fra kendte CVE’er til egen scanning, triagering og udnyttelse. CyberGym‑scoren på 83,1 procent signalerer reproducerbarhed på et benchmark. OpenBSD‑kampagnens compute‑pris under 20.000 dollar viser, at barrieren er lav. Det er ikke kun nation‑states længere – en velorganiseret kriminel gruppe kan følge med.\n

Compute‑regningen bliver ikke redningsplanken. Selv med variation i tal er størrelsesordenen til at betale. Vores egen mini‑pipeline i et internt lab viste det samme: det sværeste var ikke compute, men miljøopsætning og isolering af netværk.\n

Nordisk gadehjørne med blinkende advarselslys og arbejdszone — metafor for akutte operationelle omdirigeringer ved hurtig udnyttelse.

Hvor vulnerability management fejler i dag\n

Mange prioriterer stadig efter CVSS alene. Det er nemt at kommunikere, men CVSS måler potentiel alvor – ikke om nogen skyder på dig. Ifølge VentureBeat er en valideret trelags‑model bedre: start med CISA KEV for aktiv udnyttelse, så EPSS for sandsynlighed, og først derefter CVSS for baseline‑alvor.\n

VentureBeat henviser til en validering på 28.377 virkelige sårbarheder med 18 gange bedre effektivitet, 85,6 procent dækning af udnyttede sårbarheder og cirka 95 procent reduktion i urgent workload. De tal vil vi se i primærform, men logikken står: filtrér først på fakta i felten, derefter sandsynlighed, og til sidst teori.\n

Praktiske konsekvenser for drift\n

Det her rammer patch‑SLA’er, change‑vinduer, QA‑miljøer og pipelines. For CVE’er på CISA KEV bør SLA måles i timer. For EPSS‑højrisiko måske 24 timer. Resten kan følge normal cyklus. Men det kræver, at asset‑inventory er troværdig. Uden en nøjagtig liste over hvad I har, og hvor, er KEV‑ og EPSS‑feeds blot dashboards.\n

Vi har set to scenarier hos kunder. Ét hvor KEV\/EPSS‑integration var koblet til en moden CMDB og CI\/CD: markant lavere tryk på akutte sager, fordi kun relevante systemer fik prioritet. Og ét hvor samme integration ramte et monolitisk legacy‑system uden rollback. Her kollapsede en 24‑timers SLA, fordi den hurtige deploy ikke kunne rulles tilbage. Tre nætter og meget kaffe senere var der ro. Det var vores fælles blinde vinkel, ikke mangel på vilje.\n

Hvordan en automatiseret prioriteringspipeline ser ud\n

Kedeligt, men konkret: et cronjob, et par API‑kald, opslag i CMDB og bucket‑logik til workflows. Scriptet henter dagligt fra CISA KEV, FIRST.orgs EPSS og NVD. Matcher mod jeres assets. Bucket A: KEV‑matches. Bucket B: EPSS over en grænseværdi, fx 0,088 som foreslået af VentureBeat. Bucket C: CVSS over 7.0. Hver bucket har sin proces, sine gates, sine SLA’er.\n

Behold en menneskelig gate pr. bucket. Krav om kanarie og staged rollout for A og B. Og en ensartet rollback‑plan, der ikke bor i hovedet på én senior. QA flytter fra manuel regression til at vedligeholde tests, der kan køre på timer – ikke dage. Det lugter af DevOps‑hygiejne, og det er det også.\n

Tekniker udfører en kanarie rollback‑test i en lille virksomhed — procesmoment for sikker patch‑deploy med fallback.

AI i stuearrest\n

AI‑assisteret red teaming bør køre i en safe sandbox: stram isolation, ingen produktionsnøgler, syntetiske data. Brug modeller til at generere exploit‑forsøg mod egen software, men hold netværket blindt mod resten af verden. I et internt PoC med AI‑drevet fuzzing i en lukket Kubernetes‑klynge var tempoet fantastisk – og modellen forsøgte periodisk at kalde eksterne domæner, som vi havde blokeret. Småt, men værd at logge.\n

Glem ikke agent‑autorisering. VentureBeat nævner et eksempel fra Docker‑økosystemet, hvor en middleware‑quirk kan omgå plugins ved store body‑størrelser. Pointen er bredere: jeres autorisationspolitik er sjældent testet mod autonome agenter. Lav et review af agent‑flows, ikke kun human‑flows. Og sæt volumetriske grænser.\n

Tradeoffs og begrænsninger\n

Automatik giver fart – og falske positiver, hvis CMDB ikke er ren. 24‑ eller 48‑timers SLA’er koster nætter, hvis ikke I investerer i testautomatisering. Legacy‑systemer med manuelle changes kan ikke følge med uden parallelle spor eller undtagelser med kompenserende kontroller. Regulering kan bremse jer; visse sektorer kræver lange godkendelser.\n

Banner

Og husk sikkerheden i selve automatikken. En brudt approvals‑kæde er en åben dør. Sikr patch‑pipelines lige så hårdt som produktionsdeploys. Automatisér – men læg sikkerhedszonen først.\n

En simpel beslutningsregel\n

Vil I hurtigt styre risiko‑budgettet, så brug en grov tommelfingerregel: Aktivt udnyttet i KEV på et eksponeret asset eller internetvendt service – patch i timer. EPSS høj over grænsen på et kritisk system – under 24 timer og med kanarie. Alt andet – følg jeres normale cyklus, men træk TTR ned, når I kan. Ikke perfekt, men det flytter tempoet uden at vælte alt.\n

Vi bruger ofte et simpelt scorekort: Eksponering 0‑2, Udnyttelse 0‑2, Sandsynlighed 0‑2, Alvor 0‑2. 6 eller højere kører i hurtig bane. Et værktøj, ikke en religion.\n

Implementeringscheckliste\n

    \n

  • Asset‑inventory på plads: CMDB eller tilsvarende med miljø, ejerskab og eksponering. Oprydning først. 2 til 4 uger. Roller: CTO sponsor, SRE lead, systemejere.\n
  • Integrer feeds: CISA KEV, EPSS og NVD via API. 3 til 5 dage for en første version. Roller: SecOps, en udvikler, en SRE.\n
  • Definér thresholds og SLA’er: KEV i timer, EPSS over fx 0,088 i 24 timer, CVSS over 7 efter politik. 1 uge inkl. governance. Roller: CISO, change‑owner.\n
  • Byg pipelines: kanarie, staged rollout, automatiske tests, rollback‑scripts. 2 til 6 uger afhængigt af modenhed. Roller: platformteam, QA, driftsledelse.\n
  • Incident playbooks: hvis patch fejler eller exploit observeres – hvem gør hvad. 3 dage. Roller: IR‑leder, on‑call SRE, kommunikation.\n\n

    Hvorfor tempoet betyder noget helt lavpraktisk\n

    Når udnyttelse kan ske på under 10 timer, er forskellen mellem en daglig og en ugentlig batch‑deploy ikke 6 dage. Det er forskellen mellem kompromitteret og ikke‑kompromitteret. Vi har set build‑servere blive forsøgt ramt gennem tredjeparts‑komponenter samme døgn, som advisories landede. Lyden, der afslører det i SOC’en, er næsten komisk: pinget fra en ny alert, alt for tidligt om morgenen.\n

    Flyt beslutningerne tættest muligt på fakta. KEV er fakta. EPSS er sandsynlighed. CVSS er teori. Byg driften baglæns fra det.\n

    Hvordan Snilld kan hjælpe uden at gøre det til et salg\n

    Vi har scripts, der binder KEV\/EPSS\/NVD sammen med CMDB‑tags og deployment‑pipelines. Det er ikke plug and play, men det virker, når asset‑data er rene. Vi kører også korte forløb med sandbox til AI‑drevet red teaming med sikre credentials og netværk. Typisk leverer vi en køreplan, pipelines i repo og en backlog for QA‑automatisering. Ærligt: det sværeste er governance og rollback‑disciplin i legacymiljøer.\n

    Prisniveau for et koncentreret PoC ligger typisk i et interval, de fleste IT‑afdelinger kan bære, afhængigt af scope og miljøstørrelse. Kontakt os på normal vis for detaljer – men start med asset‑oprydning. Uden den falder alt andet fra hinanden.\n

    Kilder, usikkerheder og hvad vi holder øje med\n

    VentureBeat er rygraden i de tal, vi gengiver om Mythos, CyberGym, OpenBSD‑omkostning og de to hurtige CVE‑exploits. University of Illinois’ arXiv‑paper dækker 87 vs 7 procent‑resultatet og er en primær kilde. Rapid7 og Google M‑Trends omtales i VentureBeat; vi afventer og gennemgår de primære rapporter for eksakte metoder og definitioner. Der er en reporting‑gap her.\n

    Vi søger især klarhed på tre punkter: 1) Anthropic‑dokumentation for tusindvis af zero‑days og benchmarkmetrikker. 2) Primære tidsstempler for Langflow og Marimo advisories og første observerede exploit. 3) Datasættet på 28.377 CVE’er bag trelags‑valideringen. Indtil da anbefaler vi konservativ praksis: kortere SLA’er, hvor fakta tilsiger det, og automatiseret triage.\n

    Boks med kilder og videre læsning\n

      \n

    • VentureBeat: Claude Mythos exposed a hard truth… 2026. Sekundær kilde, tidslinje og tal for Mythos, CyberGym, OpenBSD, CVE‑cases.\n
    • University of Illinois på arXiv: LLM Agents can Autonomously Exploit One‑day Vulnerabilities. Primær kilde til 87 vs 7 procent.\n
    • CISA KEV katalog og API. Primær datakilde til aktiv udnyttelse.\n
    • FIRST.org EPSS og API. Primær datakilde til sandsynlighed for udnyttelse.\n
    • NVD API. Primær datakilde til CVSS og metadata.\n
    • Rapid7 Threat Landscape 2026. Primær kilde til median CVE til KEV på fem dage. Verificeres ved læsning af originalrapporten.\n
    • Google M‑Trends 2026 fra Mandiant. Primær kilde til udnyttelse før patch. Også til verifikation.\n\n

      Appendix om metode og krydstjek\n

      Vi har trianguleret mod VentureBeat som sekundær kilde, arXiv som primær for 87 vs 7, og dokumentation for KEV\/EPSS\/NVD som operationelle referencer. Hvor tal kun fremgår af VentureBeat, nævnes det udtrykkeligt, og vi markerer usikkerhed, indtil Anthropic og øvrige primærkilder publicerer mere metode.\n

      Vi har også brugt intern erfaring fra Snilld anonymt til at beskrive implementeringskonsekvenser: integrationer, faldgruber ved rollback og behov for QA‑automatisering. Det er ikke dokumentation for Mythos eller forskningsresultater – det gør anbefalingerne jordnære. Drop de store trusselsmodeller som start; I får mere ud af at bygge den første pipeline og mærke forskellen i hænderne.

Kilder

    Gør brugeroplevelsen bedre.
    Hvilket firma arbejder du for?