Tor-projektet måtte den 23. september 2026 udsende en nødopdatering til hele sit netværk, efter en bølge af AI-genererede sårbarhedsrapporter afslørede alvorlige fejl i software, som millioner af mennesker verden over stoler på for at forblive anonyme online. Udviklerne kalder fænomenet “LLM report firehose”, altså en brandslange af rapporter produceret af sprogmodeller, og det er anden gang på under en måned, at det tvinger et akut sikkerhedsudspil frem. For danske og nordiske brugere, der benytter Tor til alt fra journalistisk kildebeskyttelse til at omgå censur, er sagen et konkret varsel om, at AI nu ændrer selve tempoet i sikkerhedsarbejdet bag privatlivsværktøjer.
Sagen rejser et spørgsmål, som resten af open source-branchen også kæmper med: Hvad gør man, når kunstig intelligens pludselig er i stand til at finde rigtige sikkerhedshuller i et tempo, som et lille, ofte frivilligt team slet ikke er bygget til at følge med i? Denne artikel gennemgår, hvad der faktisk skete, hvorfor Tor-sagen adskiller sig markant fra andre projekters erfaringer med AI-rapporter, og hvad det betyder for privatlivsbevidste brugere i Danmark og Norden.
Hvad skete der: Tor 0.4.9.13 og nødopdateringen den 23. september
Tor Project udsendte version 0.4.9.13 af kernesoftwaren, der driver hele Tor-netværket, den 23. september 2026. Udgivelsen indeholdt ifølge det officielle udgivelsesnotat “flere sårbarhedsrettelser med høj alvorsgrad, endnu en gang med udspring i LLM report firehose”, og udviklerne skrev direkte til brugerne: “Rettelserne påvirker alle Tor-komponenter: relæer, klienter og onion services. Vi anbefaler kraftigt at opdatere så hurtigt som muligt” (Tor Project, officiel sikkerhedsmeddelelse, gengivet af SecurityNews.ch).
Udgivelsen samlede ti sporede sårbarheder med interne TROVE-numre, Tors eget system til at katalogisere fejl parallelt med det CVE-system, resten af branchen bruger. Flere af fejlene blev vurderet som højalvorlige, og Tor-projektet valgte bevidst at tilbageholde de fulde tekniske detaljer i en uges tid efter udgivelsen for ikke at give angribere en opskrift, mens brugerne stadig var i gang med at opdatere. Det minder om, hvordan store softwarehuse som Microsoft og Google har håndteret kritiske zero-day-rettelser de seneste år, men er relativt usædvanligt for et lille, decentralt open source-projekt som Tor.
Sagen var ikke en isoleret hændelse. Allerede den 3. september 2026, da Tor annoncerede version 0.4.9.12, skrev projektet, at den store bølge af fejlrapporter skyldtes “LLM’er i et lukket loop, der analyserer C-kode”, ifølge gennemgangen af Tors udgivelsesarkiv. Tre uger senere kom den langt mere alvorlige opfølgning i form af 0.4.9.13, og udviklerne bekræftede, at det nu var anden gang, samme fænomen udløste en nødrettelse.
“LLM report firehose”: det nye begreb der forklarer bølgen
Begrebet “LLM report firehose” er ikke et etableret branchebegreb, men en formulering Tor-udviklerne selv har taget i brug for at beskrive en helt ny virkelighed: en konstant strøm af sårbarhedsrapporter, der er genereret eller kraftigt assisteret af sprogmodeller, som systematisk gennemgår Tors kildekode og finder mønstre, mennesker overser eller ikke har tid til at lede efter manuelt. De tilgængelige kilder afslører hverken, hvem der står bag rapporterne, det præcise antal indsendelser, eller hvor stor en andel der reelt er brugbare, men resultatet taler for sig selv: gentagne nødopdateringer på tværs af hele softwarepakken på under en måned.
Det, der gør Tor-sagen særlig interessant, er, at fænomenet her tilsyneladende producerer reelle, alvorlige fund, i modsætning til den bølge af værdiløse AI-rapporter, andre open source-projekter har kæmpet med siden 2025. Sekundære kilder citerer Tor-udviklere for at forvente sikkerhedsudgivelser hver anden til tredje uge, så længe strømmen af rapporter fortsætter i det nuværende tempo. Det er en markant acceleration i forhold til Tors historiske mønster, hvor større sikkerhedsudgivelser typisk har ligget med flere måneders mellemrum.
Tor Browser 16.0a12 og Arti 2.6.0: hele økosystemet opdateres
Nødopdateringen af kerneprotokollen kom ikke alene. Dagen før, den 22. september 2026, udgav Tor-udvikleren Giorgio Maone alfaversionen Tor Browser 16.0a12 til Android, Windows, macOS og Linux. Udgivelsen opdaterede den underliggende Tor-version til 0.4.9.12, hævede NoScript-udvidelsen til version 13.6.33.90101984 og rebasede browseren på Firefox 153.3.0esr, samtidig med en række build- og signeringsændringer. Browserversionen indeholdt altså endnu ikke rettelserne fra den efterfølgende 0.4.9.13-udgivelse, hvilket betyder, at brugere af Tor Browser skal holde øje med endnu en opdatering i den kommende tid.
Samtidig udkom Arti 2.6.0, Rust-implementeringen af Tor-protokollen, som projektet arbejder på for at afløse den ældre C-baserede kodebase på sigt, den 1. september 2026. Arti-teamet, ved udvikleren “gabi”, beskrev udgivelsen som en samling af “flere fejlrettelser og intern oprydning” uden at specificere, om nogen af rettelserne stammede fra den samme AI-drevne rapportstrøm som kernesoftwaren (Tor Project-forum). At både den gamle C-kodebase og den nye Rust-baserede afløser bliver opdateret parallelt, viser, at presset rammer hele Tor-økosystemet og ikke kun én, ældre komponent.
Tidslinje: Tors sikkerhedsudgivelser i september 2026
Nedenstående tabel samler de vigtigste udgivelser i den seneste bølge, som samlet demonstrerer, hvor komprimeret tempoet er blevet.
| Dato (2026) | Udgivelse | Komponent | Detaljer |
|---|---|---|---|
| 1. september | Arti 2.6.0 | Rust-implementering | Flere fejlrettelser og intern oprydning |
| 3. september | Tor 0.4.9.12 | Kerneprotokol | Annoncering nævner “LLM’er i lukket loop” som årsag til fejlbølge |
| 22. september | Tor Browser 16.0a12 | Browser (Android/Win/macOS/Linux) | Opdaterer Tor til 0.4.9.12, NoScript til 13.6.33.90101984, rebase på Firefox 153.3.0esr |
| 23. september | Tor 0.4.9.13 | Kerneprotokol (relæer, klienter, onion services) | Nødopdatering, 10 sporede TROVE-sårbarheder, flere med høj alvorsgrad |
Fire udgivelser på 23 dage, hvoraf mindst to var direkte relateret til den AI-drevne rapportbølge, er usædvanligt for et projekt, der historisk har udsendt sikkerhedskritiske opdateringer med længere mellemrum. Det efterlader både brugere og relæoperatører med en ny opgave: at holde styr på et markant hurtigere patch-tempo, end de fleste privatlivsværktøjer normalt kræver.
Curl-projektets AI-slop-krise: et advarselseksempel fra 2025
For at forstå, hvorfor Tor-sagen er bemærkelsesværdig, er det nødvendigt at kende forhistorien fra et andet centralt open source-projekt: curl, værktøjet der ligger under stort set alle moderne programmeringssprog og operativsystemers netværkskald. Curls grundlægger og chefudvikler Daniel Stenberg indledte i 2025 en offentlig kamp mod det, han kaldte “AI slop”, altså AI-genereret sludder forklædt som sikkerhedsrapporter.
I sit blogindlæg “Death by a thousand slops” fra 14. juli 2025 skrev Stenberg, at “den generelle tendens i 2025 har været langt mere AI-slop end nogensinde før (omkring 20 procent af alle indsendelser), da vi i gennemsnit har fået omkring to sikkerhedsrapporter om ugen” (Daniel Stenberg, curl-grundlægger, daniel.haxx.se). Han tilføjede, at kun omkring 5 procent af 2025-indsendelserne på det tidspunkt havde vist sig at være ægte sårbarheder, ned fra en historisk andel på over 15 procent i tidligere år.
Allerede i maj 2025 indførte curl-projektet en hård linje: “Vi udelukker øjeblikkeligt enhver, der indsender rapporter, vi vurderer som AI-slop,” sagde Stenberg dengang og tilføjede, at projektet på det tidspunkt aldrig havde modtaget en eneste gyldig fejlrapport genereret med AI (The Register). I januar 2026 beskrev han en enkelt uge, hvor curl modtog syv HackerOne-sager inden for 16 timer, hvoraf ingen viste sig at være reelle sårbarheder, og at projektet allerede havde talt 20 indsendelser i årets første 21 dage.
Tor vs. curl: sammenligning af AI-rapporternes kvalitet
Selvom begge projekter oplever en eksplosion i antallet af AI-relaterede rapporter, er der en afgørende forskel: hos curl var langt de fleste rapporter værdiløse, mens Tors nødopdateringer rent faktisk indeholdt reelle, alvorlige rettelser. Tabellen nedenfor sammenstiller de tilgængelige tal fra de to projekter.
| Mål | Curl (2025-2026) | Tor (september 2026) |
|---|---|---|
| Historisk gyldighedsrate før AI-bølgen | Over 15 % af rapporter bekræftet som sårbarheder | Ikke offentliggjort separat |
| Gyldighedsrate under AI-bølgen | Under 5 % i 2025 ifølge Stenberg | 10 af rapporterne endte som bekræftede TROVE-sårbarheder i én udgivelse |
| Rapportfrekvens | Cirka 2 rapporter om ugen i 2025, stigende til cirka én hver 18. time midt i 2026 | Flere sikkerhedsudgivelser inden for tre uger i september 2026 |
| Projektets reaktion | Automatisk udelukkelse af formodede AI-slop-afsendere, overvejelser om at afskaffe bug bounty-programmet | Fortsat behandling af rapporter, men med hastende offentlige sikkerhedsudgivelser |
| Delvis opfølgning i 2026 | 415 indsendelser registreret i én opgørelse, heraf 64 bekræftede sikkerhedsproblemer og 77 “informative”; resten, omkring 66 %, hverken sikkerhedsproblem eller almindelig fejl | Ikke en tilsvarende offentlig opgørelse tilgængelig |
Tallene fra curl viser et projekt, der reelt drukner i støj, mens Tor tilsyneladende står med det modsatte problem: en stigende mængde reelle fund, som stadig skal analyseres, testes og patches manuelt af et lille udviklerteam. Begge situationer er ressourcekrævende, men på hver sin måde, og det er netop den kombination, der gør AI-drevet sårbarhedssøgning til et af de mest omdiskuterede emner i sikkerhedsbranchen lige nu.
Hvorfor Tor er anderledes: når AI faktisk finder rigtige fejl
Forskellen mellem curls og Tors oplevelser understreger et vigtigt punkt om AI-drevet sikkerhedsforskning anno 2026: kvaliteten afhænger tilsyneladende meget af, hvilken kodebase og hvilke værktøjer der bruges til at generere rapporterne. Curls oplevelse med overvejende “slop” skyldtes til dels enkle, automatiserede prompts, der producerede plausible, men indholdsløse rapporter i massevis. Tors sagsbeskrivelse peger derimod på mere systematisk, “lukket loop”-analyse af C-kode, hvor sprogmodellen tilsyneladende har fundet reelle mønstre, mennesker ikke havde fanget.
Det er også værd at bemærke, at curl-projektet selv har rapporteret en vis udvikling i den anden retning i løbet af 2026, hvor en del af de AI-assisterede rapporter er blevet mere præcise og har hjulpet med at rette dusinvis af mindre fejl. Billedet er med andre ord ikke sort-hvidt: AI-værktøjer bliver bedre til at finde reelle problemer i kildekode, men det sker i et tempo, der udfordrer selv erfarne vedligeholdere, uanset om resultatet er støj eller substans.
Danmark og Norden: hvem bruger Tor, og hvorfor det betyder noget
Tor-netværkets sikkerhed er ikke kun et abstrakt spørgsmål for udviklere. Ifølge Tor Metrics’ seneste offentliggjorte landetal, opdateret 29. september 2026, lå Finland som et af de lande, der bidrager mest til det globale brugertal, med omkring 200.376 daglige brugere svarende til 6,48 procent af det samlede estimat, kun overgået af USA og Tyskland (Tor Metrics). Det gør Norden til en af de regioner, hvor Tor-netværket reelt bruges i stort omfang, ikke kun af aktivister og journalister, men også af almindelige brugere, der ønsker at undgå sporing.
Danmark bidrager samtidig til selve netværkets infrastruktur. Ifølge overvågningstjenesten OrNetStats, opdateret 7. september 2026, stod danske relæoperatører for omkring 9.525 Mbit/s trafik fordelt på 33 mellemrelæer og 14 exit-relæer, drevet af blandt andre Foreningen for DotSrc, Zencurity ApS, Telenor A/S og BornFiber Service (OrNetStats). Det betyder, at danske organisationer og virksomheder bogstaveligt talt er en del af den infrastruktur, som nu skal opdateres hastigt, hver gang en ny bølge af AI-fundne sårbarheder rammer.
For danske brugere, der bruger Tor Browser til at researche følsomme emner, kommunikere med kilder eller blot undgå kommerciel sporing, betyder den nye patch-hastighed konkret, at det ikke længere er nok at opdatere en gang imellem. Med sikkerhedsudgivelser hver anden til tredje uge er automatiske opdateringer eller faste, hyppige tjek nu en forudsætning for at bruge værktøjet sikkert.
Ekspertvurderinger: hvad sikkerhedsbranchen siger
Selve kernen i sagen er formuleret direkte af Tor-projektet i dets officielle sikkerhedsmeddelelse for version 0.4.9.13: “Denne sikkerhedsudgivelse indeholder flere alvorlige rettelser, endnu en gang med udspring i LLM report firehose” (Tor Project, forummeddelelse videresendt af Sam James, gengivet af SecurityNews.ch). Formuleringen “endnu en gang” er central, fordi den bekræfter, at fænomenet ikke var en engangshændelse, men et mønster, projektet allerede havde oplevet mindst én gang tidligere samme måned.
Tor-projektets egen anbefaling til brugerne var utvetydig: “Rettelserne påvirker alle Tor-komponenter: relæer, klienter og onion services. Vi anbefaler kraftigt at opdatere så hurtigt som muligt” (Tor Project, officiel sikkerhedsmeddelelse, SecurityNews.ch). Den type direkte, hastende sprogbrug er usædvanlig for et projekt, der normalt kommunikerer i et roligt, teknisk tonefald, og den understreger alvoren i situationen.
Fra curl-siden af historien er Daniel Stenbergs vurdering lige så markant. Han beskrev udviklingen som et kollaps i rapporternes brugbarhed: “Gyldighedsraten er faldet markant sammenlignet med tidligere år,” skrev han i sit blogindlæg, og konkluderede kort og kontant, at “ikke engang én ud af tyve var ægte” (Daniel Stenberg, curl-grundlægger, daniel.haxx.se). Sammenholdt med Tors erfaring viser de to citater tilsammen, hvor forskelligt AI-drevet sårbarhedssøgning kan ramme forskellige projekter, selv når begge beskriver samme underliggende teknologi.
Markedspåvirkning: pres på open source-sikkerhedsteams
Sagen har konsekvenser langt ud over Tor-projektet selv. Bug bounty-branchen, hvor virksomheder betaler for at få sikkerhedshuller rapporteret ansvarligt, står over for et grundlæggende problem: Når sprogmodeller kan generere store mængder plausible rapporter på minutter, mens et menneske skal bruge timer på at afgøre, om rapporten er ægte, vender den økonomiske ligning fra sikkerhedsteamets synsvinkel om. Curl-projektet overvejede i 2025 direkte at afskaffe sine kontante bug bounty-belønninger for at dæmme op for tilstrømningen af AI-genererede rapporter, ifølge The Register.
For privatlivsværktøjer som Tor, hvor koden er kritisk infrastruktur for ytringsfrihed og anonymitet i autoritære stater, er problemet dobbelt: Projektet kan hverken ignorere rapporterne, fordi nogle af dem beviseligt er ægte og alvorlige, eller behandle dem alle manuelt uden at bruge uforholdsmæssigt mange ressourcer på triage. Det tvinger i praksis små, ofte frivilligt drevne teams til enten at finde nye finansieringskilder til hurtigere responstid, eller acceptere et langsommere, mere udsat sikkerhedsniveau. Begge scenarier har direkte betydning for de millioner af brugere, der stoler på værktøjerne dagligt.
Historisk kontekst: Tor-sårbarheder før AI-æraen
Tor-netværket har eksisteret i over to årtier og har historisk håndteret sikkerhedsopdateringer i et langt roligere tempo end det, projektet oplever nu. Store, opsigtsvækkende sårbarheder, dem der ramte netværket i tidligere runder af almindelige, menneskefundne CVE’er, kom typisk med måneders mellemrum snarere end uger. Nedstrømsprojekter, der bygger på Tor-daemonen, som Whonix og Tails, har tidligere kæmpet med at følge med Tors patch-tempo, og tidligere CVE-bølger har krævet koordinerede rettelser på tværs af flere privatlivsdistributioner samtidig.
Det, der adskiller efteråret 2026 fra tidligere episoder, er ikke antallet af sårbarheder i sig selv, men hastigheden hvormed de bliver fundet og skal håndteres. Hvor en traditionel sikkerhedsgennemgang typisk krævede måneders forudgående forskning fra et menneskeligt team, kan sprogmodeller i dag scanne store kodebaser kontinuerligt og generere kandidatrapporter i realtid. Det ændrer grundlæggende, hvad det vil sige at “holde styr på” sikkerheden i et open source-projekt af Tors størrelse og kompleksitet.
Konkurrencesammenligning: hvordan andre privatlivsværktøjer håndterer patch-tempo
Tor er langt fra det eneste privatlivsværktøj, der bygger på store, komplekse kodebaser med et forholdsvis lille antal kernevedligeholdere. VPN-udbydere som Mullvad og Proton VPN driver egne, lukkede infrastrukturer, hvor opdateringer kan rulles ud centralt uden at afvente, at hver enkelt bruger selv installerer en ny klient, hvilket giver dem en strukturel fordel i tempo. Password managers som Bitwarden har tilsvarende centraliserede opdateringsmekanismer.
Tor-netværkets decentrale natur, hvor tusindvis af uafhængige relæoperatører og millioner af individuelle brugere selv skal opdatere deres software, gør det grundlæggende sværere at sikre hurtig, universel patching. Det er samme udfordring, Signal og andre krypterede beskedtjenester i mindre grad står over for, men Tors situation er forstærket af, at selve netværkets sikkerhed afhænger af, at et kritisk antal relæer opdaterer samtidigt for at undgå, at forældede noder bliver et svagt led, angribere kan udnytte til at deanonymisere trafik.
Hvad brugere og relæoperatører bør gøre nu
Tor-projektets anbefaling er enkel, men vigtig at følge bogstaveligt: Alle brugere af Tor Browser bør sikre sig, at de kører den nyeste tilgængelige version, og relæoperatører bør opdatere til 0.4.9.13 hurtigst muligt. Selve udgivelsesnotatet fra projektet illustrerer, hvor direkte anbefalingen er formuleret:
Changes in version 0.4.9.13 - 2026-09-23
This security release includes several high severity fixes,
once again originating from the LLM report firehose.
The fixes affect all Tor components: relays, clients,
and onion services.I praksis betyder det, at brugere bør aktivere automatiske opdateringer i Tor Browser, hvor muligt, og undgå at udskyde opdateringsprompts. Relæoperatører, herunder de danske organisationer der driver noder gennem netværk som DotSrc, bør overvåge Tor-projektets mailinglister og officielle blog tæt i den kommende periode, da yderligere sikkerhedsudgivelser med stor sandsynlighed er på vej inden for få uger, givet det nuværende tempo. Den officielle blog og udgivelseshistorik findes på Tor Projects blog.
Fremtidsudsigter: fem forudsigelser for AI og sårbarhedsforskning
- Hyppigere sikkerhedsudgivelser bliver det nye normale. Så længe “LLM report firehose”-fænomenet fortsætter, må Tor-brugere forvente sikkerhedsopdateringer hver anden til tredje uge snarere end få gange årligt.
- Flere open source-projekter indfører formelle AI-triage-processer. Efter curls og Tors erfaringer vil flere store projekter sandsynligvis oprette dedikerede, semi-automatiserede filtre til at adskille reelle AI-fund fra støj, før et menneske involveres.
- Bug bounty-økonomien ændrer sig. Flere projekter vil, som curl allerede har overvejet, enten sænke eller helt fjerne kontante belønninger for at modvirke incitamentet til at spamme AI-genererede rapporter ind for en hurtig gevinst.
- Decentrale netværk som Tor får et strukturelt handicap. Fordi opdateringer afhænger af, at tusindvis af uafhængige operatører og brugere selv installerer nye versioner, vil presset for automatiske opdateringsmekanismer stige yderligere.
- AI-assisteret kodeanalyse bliver et officielt værktøj snarere end kun en trussel. I takt med at flere projekter, ligesom dele af curls 2026-erfaring antyder, oplever at AI-rapporter bliver mere præcise over tid, vil flere sikkerhedsteams begynde at bruge de samme værktøjer proaktivt internt i stedet for kun at reagere på eksterne indsendelser.
Ofte stillede spørgsmål om Tor og AI-sårbarhedsrapporter
Hvad er “LLM report firehose”?
Det er den betegnelse, Tor-projektets udviklere selv har brugt om den store, vedvarende strøm af sårbarhedsrapporter, der bliver genereret eller assisteret af sprogmodeller, som systematisk analyserer Tors kildekode for fejl.
Er min anonymitet i fare, hvis jeg ikke opdaterer Tor Browser med det samme?
Tor-projektet har bevidst tilbageholdt de fulde tekniske detaljer om sårbarhederne i en periode for at begrænse risikoen for udnyttelse, men anbefaler kraftigt, at alle brugere opdaterer hurtigst muligt, da fejlene er vurderet som højalvorlige og påvirker relæer, klienter og onion services.
Hvilken version af Tor bør jeg bruge nu?
Tor-daemonen bør opdateres til version 0.4.9.13 eller nyere, mens Tor Browser bør opdateres til den seneste tilgængelige alfaversion eller stabile udgivelse, der inkluderer de tilhørende rettelser.
Hvorfor rammer AI-genererede rapporter nogle projekter hårdere end andre?
Det afhænger tilsyneladende af, hvilke metoder og modeller der bruges til at generere rapporterne. Curl-projektet har overvejende oplevet lavkvalitets “slop” fra simple, automatiserede indsendelser, mens Tor-sagen peger på mere systematisk kodeanalyse, der har fundet reelle, alvorlige fejl.
Hvad er Arti, og hvorfor er det relevant her?
Arti er Tor-projektets nye implementering af Tor-protokollen skrevet i programmeringssproget Rust, tænkt som en fremtidig afløser for den ældre C-baserede kodebase. At Arti også modtog en opdatering i samme periode, viser, at presset fra den øgede sårbarhedsstrøm rammer hele Tor-økosystemet, ikke kun den gamle kode.
Bruger danskere Tor i stort omfang?
Norden generelt, og især Finland, bidrager med en betydelig andel af Tor-netværkets daglige brugere ifølge Tor Metrics, og Danmark huser samtidig flere aktive relæoperatører, herunder organisationer som DotSrc og virksomheder som Zencurity og Telenor, der er en del af selve netværkets infrastruktur.
Kan almindelige brugere gøre noget for at hjælpe Tor-projektet med at håndtere AI-rapportbølgen?
Den mest direkte hjælp er at holde sin software opdateret og undgå at ignorere opdateringsprompts, samt, for tekniske brugere, at overveje at drive et relæ eller bidrage økonomisk til projektet, da hurtigere triage af sårbarhedsrapporter i sidste ende kræver flere menneskelige ressourcer.