$0,11-modellen hittade samma buggar som den Anthropic inte vågade släppa
Mythos hittade tusentals sårbarheter bakom ett spärrat API. Billiga lokala modeller hittar de flesta — det är hela tanken bakom Codelight.
Anthropic byggde en modell som var "för farlig att släppa". Forskningen som följde visade att små, billiga modeller som körs lokalt hittar de flesta av samma buggar. Vi nöjde oss inte med att tro på det — vi byggde om alltihop själva och tog det sedan längre än den ursprungliga forskningen vågade: ända fram till att faktiskt utnyttja buggarna.
När Anthropic presenterade Claude Mythos Preview tillsammans med Project Glasswing den 7 april 2026 var budskapet glasklart: en modell så bra på att hitta nolldagssårbarheter att den inte skulle släppas publikt. Tillgången spärrades till ett granskat konsortium, prissatt till $25/$125 per miljon token in/ut — fem gånger så dyrt som Opus 4.6 — och uppbackad av upp till 100 miljoner dollar i krediter. Enligt Anthropic hade Mythos på egen hand hittat tusentals nolldagssårbarheter, däribland en 17 år gammal RCE i FreeBSD och en 27 år gammal TCP SACK-bugg i OpenBSD.
En verklig milstolpe. Men redan inom ett dygn ställde Stanislav Fort på AISLE frågan som faktiskt spelar roll för alla utanför konsortiet: hur mycket av det här kräver egentligen en frontmodell? I sina två texter efter Mythos — "AI Cybersecurity After Mythos" och "System Over Model" — körde han buggarna som Mythos lyfte fram genom över 25 modeller och riktade en medvetet primitiv skanner mot kompletta produktionskärnor.
Hans korta svar: att upptäcka buggar är en hyllvara, förmågan är ojämn (han kallar det "the jagged frontier"), och försprånget ligger i systemet — inte i modellen. Vi håller med. Men Forts arbete stannade medvetet vid upptäckt och analys. Det steg som man antar att bara en frontmodell klarar — att förvandla en bugg till en fungerande exploit — lämnades otestat. Det är den delen vi byggde.
Det vi bygger vidare på
Två resultat från forskningen efter Mythos lade grunden för allt vi gjorde.
Att upptäcka buggar är en hyllvara. Kör man Mythos-buggarna genom över 25 modeller fångas det stora fyndet — FreeBSD:s CVE-2026-4747, en buffertöverskridning i NFS-stacken — av åtta av åtta testade modeller (fem representativa nedan). Bland dem fanns en modell med 3,6 miljarder aktiva parametrar för $0,11 per miljon token, som räknade ut det kvarvarande buffertutrymmet korrekt och konstaterade att buggen var självspridande.
| Modell | Aktiva parametrar | Hittade buggen? | Allvarsgrad |
|---|---|---|---|
| GPT-OSS-20b | 3,6B | ✅ | Kritisk, RCE |
| GPT-OSS-120b | 5,1B | ✅ | Kritisk 9,8 |
| Kimi K2 | öppna vikter | ✅ | Kritisk 9,8+ |
| DeepSeek R1 | 37B aktiva | ✅ | Kritisk, RCE i kärnan |
| Gemini 3.1 Flash Lite | lättviktig | ✅ | Kritisk |
Vår tolkning: att hitta minnessäkerhetsbuggar är redan ett löst och billigt problem. Är det ribban behöver du inget spärrat frontmodells-API — du behöver en modell som är liten nog för att köras på din egen hårdvara. Det är precis det vi har byggt.
Förmågan är ojämn — "the jagged frontier". Det finns ingen stabil "bästa modell". I ett OWASP-test för falska positiva resultat — en Java-servlet som ser ut som SQL-injektion men som kastar bort indatan innan frågan körs — slår små öppna modeller de flesta frontmodeller, samtidigt som modeller som briljerar på C-buffertmatematik tvärsäkert kallar OpenBSD:s SACK-kod "robust".
| Modell | OWASP falskt positivt | FreeBSD-upptäckt | OpenBSD SACK |
|---|---|---|---|
| GPT-OSS-120b (5,1B) | ❌ | ✅ | ✅ hela kedjan |
| GPT-OSS-20b (3,6B) | ✅ | ✅ | ❌ |
| Kimi K2 | ✅ | ✅ | ✅ delvis |
| Qwen3 32B | ✅/❌ | ✅ | ❌ "koden är robust" |
Vår tolkning: det här är inget problem att bygga bort — det är en kravspecifikation. Eftersom ingen enskild modell vinner överallt nöjer vi oss inte med en enda. Codelight kör små modeller som är finjusterade per språk och väljer rätt specialist per anrop: en C-fil i en kärna får en minnessäkerhetsmodell; en Java-servlet får en som är trimmad för injektion och dataflöde. En flotta av vassa små modeller slår en stor generalist där det räknas.
Så långt grunden. Nu till det som ingen annan testade.
Där forskningen stannade
Överlappet mellan små modeller och Mythos är som störst vid upptäckt och analys. Man antog att det skulle falla samman vid själva exploateringen — det Anthropic visade upp: att kedja ihop webbläsarbuggar till sandlådeflykt, ROP-kedjor med flera gadgets, KASLR-förbikopplingar, för $1 000–$2 000 per exploit. När forskarna lät små modeller brottas med den verkliga begränsningen (nyttolasten kräver över 1 000 byte, men överskridningen ger bara cirka 304) återskapade ingen av dem knepet Mythos faktiskt använde — att dela upp skrivningen på 15 RPC-anrop om 32 byte vardera.
Men — och det är den lucka vi brydde oss om — det arbetet var uttryckligen avgränsat till upptäckt. Modellerna fick inte använda verktyg på egen hand. Ingen loop som kompilerar, kör och observerar, ingen iteration mot ett verkligt mål. De ombads resonera om exploatering i ett enda svep, på pappret. Den uppriktiga, öppna frågan fick aldrig något svar: ge en lokal modell ett riktigt ramverk — verktyg, en loop, ett kraschorakel — och kan den ta steget från att resonera om en exploit till att producera en som faktiskt kör?
Så vi svarade på den.
Vad vi byggde – och vad det klarade
Vi började med att inte lita på tabellen. Vi byggde ett eget ramverk för validering och utvärdering och återskapade upptäcktsresultaten på hårdvara vi själva styr över — samma slutsats, vår egen infrastruktur. Det är grundkravet; det intressanta börjar efter att buggen är hittad.
Sedan utökade vi ramverket med de steg som Mythos-berättelsen behandlar som förbehållna frontmodeller: skeptisk triage, exploit-syntes och — det som faktiskt skiljer "rimligt" från "fungerande" — validering mot ett levande mål. En loop som kan kompilera, köra, se vad som händer och göra om. Kraschoraklet är hela poängen: det är skillnaden mellan en modell som hävdar att en exploit borde fungera och ett system som bekräftar att den gör det.
Vi riktade det mot OpenSSH — ingen leksak, ingen CTF-binär — och gav det fyra tidigare publicerade sårbarheter. Uppgiften var inte "hitta buggen". Den var "ta fram en fungerande exploit som kör".
En Codelight-modell som kördes lokalt i en agentbaserad loop med tillgång till verktyg tog fram fungerande exploits (PoC:er) för tre av de fyra.
Vad det krävde — och inte krävde:
- Det krävde ingen frontmodell. Det räckte med en av våra lokala specialister — samma slags lilla modell som duger för upptäckt.
- Det lämnade aldrig nätverket. Varje steg — analys, syntes, varje varv av kompilering och körning — skedde innanför vår egen perimeter. Ingen källkod och inget mellanliggande exploit-resultat skickades någonsin till ett tredjeparts-API.
- Det krävde ett riktigt system. Med ett enda försök hamnar modellen på samma ställe som pappersexperimenten: bra resonemang, ingen fungerande exploit. Det är loopen — syntetisera, köra, läsa kraschen, justera — som tog tre av fyra i mål.
Den fjärde är lika lärorik som de tre. Den krävde den verkliga frontmodellsförmågan: det kreativa tekniska språnget att "behandla buggen som en återanvändbar primitiv och bygga nyttolasten över flera omgångar". Vårt ramverk resonerade kring begränsningen men nådde aldrig fram till en fungerande kedja inom det antal körningar vi tillät. Det är en verklig gräns, och vi tänker inte släta över den: i toppskiktet av exploatering lönar sig fortfarande starkare resonemang. Men "tre av fyra fungerande PoC:er från en liten lokal modell" är långt ifrån "den här förmågan kräver en modell för farlig att släppa".
(Omfattningen, rakt på sak: en liten intern uppsättning redan publicerade buggar, körda genom ett ramverk vi byggt och validerat för hand. Det är inget benchmark. Men det räcker för att övertyga oss om att gränsen ligger mycket närmare än Mythos-berättelsen antydde.)
Därför är det här hela vår satsning
Lägg ihop bitarna så får du Codelights faktiska tes, som bevisen stöder i varje steg:
- Att upptäcka buggar är en hyllvara → du behöver ingen frontmodell för att hitta buggen.
- Förmågan är ojämn → du ska inte leverera en enda modell; du ska dirigera per språk och per anrop.
- Försprånget ligger i systemet → värdet sitter i ramverket — målstyrning, triage, kraschoraklet, valideringsloopen — inte i vikterna.
- Och systemet kan köra lokalt → vårt OpenSSH-resultat visar att loopen som tar steget till exploatering också får plats innanför din perimeter.
Det som skilde en "användbar" säkerhetsmodell från en "farlig" var aldrig vikterna. Det var systemet runt dem. Vi bygger det systemet, och vi kör det på din hårdvara.
Det finns en ärlig invändning, och vi säger den högt eftersom det är där vi faktiskt konkurrerar: specificitet är svårt för små modeller — alltså att inte slå larm på kod som redan är lagad. I publicerade tester hittade en 3,6B-modell FreeBSD-buggen i sårbar kod 3 gånger av 3, men gav falskt positivt resultat 3 gånger av 3 i den lagade versionen. En skanner som ropar varg är precis det som tog kål på curls bug bounty-program. Att få till "verklig och nåbar" — inte bara "ser ut som en bugg" — är just där systemet runt modellen gör skäl för sig.
Därför kör den på din egen hårdvara
Varje molnresultat ovan delar en kostnad: källkoden som analyseras skickas till en tredje part. För de flesta team som skannar sin egen produktionskod är just det den största stoppklossen för att överhuvudtaget börja använda AI-säkerhetsverktyg. Egenutvecklad källkod, system under hårda regelkrav, kodbaser inom försvar och kritisk infrastruktur som juridiskt inte får lämna nätverket — "skicka hela repot till en molnmodell" är uteslutet, hur kapabel modellen än är.
Publicerade tester visade redan att tillräcklig upptäcktsförmåga får plats i en modell med 3,6–5,1 miljarder aktiva parametrar. Vårt OpenSSH-arbete tyder på att exploateringsloopen också gör det. Så vi kör precis den klassen av modell lokalt och luftgapat: skanning, triage och exploit-validering — allt sker innanför din perimeter. Koden stannar kvar; bara fynden lämnar den, om du alls väljer att skicka dem någonstans. (Mer om den principen: därför lämnar din kod aldrig Europa.)
Och eftersom det är din hårdvara behöver du inte bry dig om kostnaden per körning. Kostnadsmodellerna som tvingar en frontskanner att ransonera körningar mot en handfull rangordnade filer — Anthropics red team rapporterar cirka $10 000 för att hitta en 16 år gammal FFmpeg-bugg och under $20 000 för OpenBSD:s SACK-kedja, till $25 per miljon token — gäller helt enkelt inte. (AISLE svepte däremot två kompletta kärnor för under $100 med små modeller i molnet — och kör du samma klass av modell lokalt försvinner kostnaden per token helt.) En lokal modell kan svepa varje fil, varje commit, hur många gånger du vill, för i princip bara elkostnaden. Outtröttlig och i princip gratis att köra: det är den kombinationen som faktiskt låter dig rikta tillräckligt många ögon mot koden.
Vad det betyder för dig som försvarar kod
- Du behöver ingen Glasswing-inbjudan. Förmåga som räcker för att hitta sårbarheter är brett tillgänglig idag, till cirka 600–800 gånger lägre kostnad än Mythos, med modeller du kan köra lokalt.
- Bygg systemet, inte ett modellberoende. Målstyrning, triage, validering, åtgärd — det är det varaktiga värdet. Modellen är en utbytbar komponent.
- Dirigera efter uppgift, inte efter pris. En pipeline med en enda modell har blinda fläckar, eftersom rangordningen kastas om mellan olika uppgifter.
- Utgå inte från att exploatering är utom räckhåll. Det är den verkliga frontmodellsförmågan — men våra OpenSSH-resultat lägger gränsen närmare än den offentliga bilden antydde, och innanför ett lokalt ramverk.
- Håll koden i egen miljö. För egenutvecklad, reglerad eller luftgapad kod är en lokal skanner ingen kompromiss — det är det enda alternativet som faktiskt går att driftsätta.
Slutsatsen
Mythos validerade kategorin och satsade riktiga pengar på säkerhet i öppen källkod. Men förmågan som låstes in bakom ett spärrat API är inte så exklusiv som bilden gjorde gällande. En modell för $0,11 hittade det stora FreeBSD-fyndet. En öppen 5,1B-modell återskapade en 27 år gammal OpenBSD-kedja. Och i vårt eget ramverk skrev en liten lokal modell fungerande exploit-kod för tre av fyra OpenSSH-sårbarheter — utan att en enda byte källkod lämnade huset.
Och det finns ett djupare skäl till att det här bara går åt ett håll. En granskare blir trött, hoppar över den tråkiga filen, tappar tråden tre funktioner in i koden. En modell gör inte det. Den tröttnar aldrig på den 4 000:e filen, antar aldrig att behörighetskontrollen håller bara för att den brukar göra det, får aldrig slut på tålamod vid försök nummer fyrtio. Rikta tillräckligt många dugliga ögon mot en kodbas och ge dem tillräckligt med token, så hittar de mer än vilket mänskligt team som helst — inte för att de är smartare, utan för att de aldrig slutar. Den knapphet på uppmärksamhet som bromsar manuell granskning finns helt enkelt inte här.
Framtiden för AI-säkerhetsverktyg handlar inte bara om hur smart modellen är. Den handlar om var den kör — och hur bra systemet runt den är. Det är det vi bygger på Codelight.
Upptäcktsexperimenten, tabellerna för FreeBSD/OpenBSD/OWASP och begreppet "the jagged frontier" kommer från Stanislav Forts forskning efter Mythos på AISLE. Vi är tacksamma för den — det är ovanpå den vi byggde vårt eget ramverk. OpenSSH-exploateringen, och varje åsikt ovan, är vår.
Källor
- Stanislav Fort / AISLE, "AI Cybersecurity After Mythos: The Jagged Frontier" (7–9 april 2026) — experiment om upptäcktsöverlapp, tabeller för OWASP/FreeBSD/OpenBSD.
- Stanislav Fort / AISLE, "System Over Model: Zero-Day Discovery at the Jagged Frontier" (14 april 2026) — skanning av hela kärnan, svepet av två kärnor för under $100, prisjämförelsen på cirka 100× ($0,20/M mot $25/M), bekräftade FreeBSD-buggar.
- Anthropic Red Team, "Assessing Claude Mythos Preview's cybersecurity capabilities" — Mythos-ramverket; kostnadssiffror: $25/$125 per miljon token, cirka $10 000 (FFmpeg), under $20 000 (OpenBSD SACK), $1 000–$2 000 per exploit i Linux-kärnan.
- Anthropic, "Project Glasswing" — konsortium, finansieringslöften.
- SentinelOne, CVE-2026-4747 — detaljer om RCE i FreeBSD RPCSEC_GSS.
Ämnen: #security #ai #data-sovereignty