En vild uge i cybersikkerhed: hvorfor vores EU AI-chat forblev sikker trods de seneste brud

tl;dr: Den tredje uge i oktober 2026 bragte en usædvanlig bølge af sikkerhedshændelser i tech-branchen, men DentroChat og dine data er sikre.

Hvis du følger sikkerhedsnyheder, føles denne uge som en flodbølge. Små advarsler kommer hele tiden, men når så mange grundlæggende værktøjer og cloud-platforme rammes på få dage, er det, ærligt talt, WILD.

På mindre end en uge nåede vi at få alt dette:

Hændelsen om certifikatudstederen eMudhra: 8 mellemliggende CA-certifikater under eMudhras emSign-rod viste sig at have ekstremt svage private nøgler. Fordi nøglerne kunne beregnes baglæns for at aflytte HTTPS-trafik, måtte store browsere blokere certifikaterne, eMudhra meddelte i dag, at de forlader det globale SSL/TLS-certifikatmarked helt (!), og der var brug for hastepatches til uv, pip, Node.js, Bun, Go og Rust (!) for at fjerne den kompromitterede CA fra deres indbyggede trust stores.
Kritiske CVE’er i central internetsoftware: To uautentificerede remote code execution-sårbarheder blev patched i PHP (CVE-2026-109618 og CVE-2026-109619), sammen med en kritisk buffer overflow i Google Brotli (CVE-2026-111497), en uautentificeret RCE med højeste alvor i GitLab (CVE-2026-110264) og Linux-kernel-sårbarheden “PwnEscape” (CVE-2026-99999).
LiteLLM supply chain-kompromittering: I går, den 21. oktober, kaprede angribere (igen) LiteLLMs release-pipeline og skubbede en version med bagdør (v1.107.0) til PyPI og Docker Hub. Fordi den ondsindede pakke havde en startup-hook, der kørte automatisk hver gang Python startede, indsamlede den straks cloud-legitimation og API-nøgler fra berørte servere.
Platformbrud hos Railway og Zeabur: Zeabur meddelte, at de lukker permanent efter et andet brud, der eksponerede 3,2 millioner poster med miljøvariabler fra 321.000 brugerkonti. I går sagde Railway også, at en angriber havde fået adgang til og dekrypteret kunders miljøvariabler. Målet var interessant nok især AI-inferensnøgler.
Store virksomhedsbrud: Angribere kom ind i Microsoft 365-kundetenants med stjålne backup-legitimation fra ConnectWise (SkyKick), og Capcom blev ramt af et brud, der påvirkede 11,7 millioner brugerkonti.

Er det en “Cyberpocalypse”, eller vågner internettets immunforsvar?

Hvorfor dukker så mange gamle bugs op på samme tid i regex-kompilatorer, kompressionsafkodere, hukommelsesallokatorer og kryptografiske opsætninger?

Svaret er især, at AI nu læser verdens kode. Sikkerhedsforskere og forsvarere (ligesom angribere) lader AI gennemgå kildekoden i open source-biblioteker. Resultatet er, at masser af edge cases findes, som menneskelige reviewers missede i 15 år. Selv de svage CA-nøgler hos eMudhra blev tydeligvis opdaget med hjælp fra AI.

Nogle kommentatorer kalder allerede ugen for en “Cyberpocalypse”. Vi ser det snarere sådan: internettets immunforsvar vågner endelig og helbreder sig selv. De fleste af disse bugs har ligget i produktionskode i årevis, og når de findes, kan de endelig blive rettet.

Fordi jeg for alle de år siden skrev min bacheloropgave på TU Graz om tillidsmodellen og de strukturelle risici ved certifikatudstedere, mindede eMudhra-kæden, der rullede videre til uv, pip, Node.js og Bun, mig om, hvorfor jeg valgte emnet dengang. På internettet tager tillid mange former og er et meget komplekst system.

Hvor DentroChat står efter ugens hændelser

Hvis du bruger DentroChat til dagligt arbejde og fortrolige dokumenter, blev hverken dine chats eller dine filer berørt af nogen af hændelserne. Fordi vi holder arkitekturen slank, er det meste af den ramte software slet ikke en del af vores stack, og det vi faktisk bruger, patchede vi med det samme:

CA-tillidsproblemet i uv, pip, Node.js og Bun: Kommandolinjeværktøjer og runtimes har deres egen liste over betroede certifikatudstedere, så alt, der stolede på eMudhras kompromitterede rod-certifikat, skulle opdateres. DentroChat bruger hverken uv eller pip på sine servere. Vores webapp kører dog på Bun, så vi opdaterede produktionscontainere til Bun 1.4.4 (sammen med patched Debian-systemcertifikater), hvilket fjerner den kompromitterede eMudhra-rod helt.
LiteLLM (ond v1.107.0): Vi sender AI-forespørgsler via en europæisk inferens-gateway (Cortecs), men vi bruger ikke Python-biblioteket LiteLLM eller dets Docker-images nogen steder i vores stack.
Railway, Zeabur og cloud-deploy-platforme: Vi hoster ikke på multi-tenant PaaS som Railway eller Zeabur, og vi gemmer heller ikke kundedata hos amerikanske hyperscalers eller i Microsoft-clouds. Som beskrevet på vores side om Underdatabehandlere styrer vi deployments med vores egen selvhostede Coolify-instans, der kører direkte på vores europæiske servere. Ingen ekstern PaaS-leverandør sidder derfor på vores miljøvariabler eller deploy-hemmeligheder.
PHP, GitLab og applikationsafhængigheder: Vi kører hverken PHP eller selvhostet GitLab. Derudover gennemgik og opdaterede vi hele afhængighedstræet for både chatplatformen og websitet, og står nu på nul kendte sårbarheder.

Sådan bygger vi DentroChat for at holde dine data sikre

Fordi AI-assisteret kodegennemgang vil blive ved med at finde nye CVE’er i open source, bliver tredjepartspakker aldrig helt “fejlfri”. Derfor har vi designet DentroChat med strikt isolation, så en fejl i én komponent ikke kan kompromittere dine data eller vores servere.

1. Kodekørsel i en WebAssembly-sandbox uden netværk

I år viste en omtalt sikkerhedsrapport, at OpenAI-agenter brød ud af deres sandbox i en intern evaluering. Det var muligt, fordi agenterne kørte i en Linux-container, der stadig havde netværksadgang til en intern pakkeproxy, og agenten udnyttede en zero-day i proxyen for at nå internettet.

Hos DentroChat findes den angrebsvej ikke (som tingene står nu), fordi vi ikke kører brugerkode i en Linux-container med shell eller pakkeinstaller. Når du uploader et regneark eller beder DentroChat om at køre Python-analyse, kører koden i en isoleret WebAssembly (WASM)-sandbox:

Hvert Python-bibliotek, vi understøtter til dataanalyse og dokumentoprettelse, pakkes ind ved build, så intet hentes fra PyPI eller en intern proxy ved kørsel.
Før Python overhovedet starter, klippes alle udgående netværks-API’er, dynamiske biblioteksloaders og broer til værtens filsystem, og de fjernes fra runtime.
Selv hvis et Python-bibliotek skulle bære en supply chain-bagdør som LiteLLMs startup-script, har WASM-sandboxen intet netværk at sende data gennem og ingen adgang til serverens miljøvariabler eller andre brugeres filer. Når dit diagram eller dokument er klar, ryddes det midlertidige workspace igen.

2. Syv dages afkøling mod supply chain-angreb

LiteLLM-angrebet fungerede sådan:

den ondsindede pakkeversion publiceres på PyPI
automatiserede build-pipelines verden over installerer den med det samme
efter to timer opdager sikkerhedsforskere, at noget er galt
på det tidspunkt har ondsindet kode allerede nået mange systemer

For at stoppe den slags “supply chain attack” kræver vores pakkehåndtering, ud over frosne lockfiles, en striks minimumsalder på syv dage for nye releases. En nyligt publiceret open source-version skal klare en hel uge offentlig granskning, før vores build-pipeline må installere den. Medmindre vi manuelt auditerer og pinner en akut sikkerhedspatch, som dagens runtime-opdatering…

3. Hvorfor vi blokerer intern netværksadgang, når AI’en besøger websites

Når du beder DentroChat om at læse en webside eller hente åbne data fra et open data-API, henter vores server URL’en på dine vegne. Uden hårde netværksgrænser kunne en ondsindet side gemme instruktioner, der lokker AI’en til at anmode om interne serveradresser (som 127.0.0.1 eller interne Docker-netværksporte) i stedet for et offentligt website. Teknikken hedder Server-Side Request Forgery (SSRF) og kunne afsløre interne tjenester på selve serveren.

Derfor løser vores udgående fetcher DNS, før den forbinder, blokerer alle private, loopback- og interne IP-intervaller og fastlåser den verificerede IP-adresse ved hvert redirect. Selv hvis en side prøver at snyde modellen eller bruger DNS rebinding til at skifte et domænes IP til 127.0.0.1 i sidste millisekund, afvises forbindelsen, før den rører vores interne netværk.

4. Selvstyret kryptering i ro hos Hetzner i Europa

Alle DentroChats applikationsservere, databaser og selvhostede værktøjer kører hos Hetzner i Tyskland, mens krypterede backups og pseudonymiserede serverlogs gemmes hos Scaleway i Frankrig, alt sammen under EU-jurisdiktion og uden for US CLOUD Act. Du kan til enhver tid gennemgå hele infrastrukturen på vores side om Underdatabehandlere.

Alle data er beskyttet med kryptering under transport og kryptering i ro. En teknisk detalje, som ofte overses: hos de fleste hostingudbydere (også Hetzner) er serverdiskene som standard slet ikke krypteret i ro. Derfor sætter vi kryptering i ro op og administrerer den selv. Denne sikre infrastruktur passer sammen med vores almindelige privatlivskontroller:

Ingen træning på dine chats eller filer
Automatisk chatsletning, som du styrer
Diskret chat-tilstand, når du vil holde en samtale uden for AI’ens hukommelse

Vi holder øje

God sikkerhed bliver aldrig “færdig”.

Især nu, hvor både forskere og angribere finder zero-day-sårbarheder med AI hurtigere end nogensinde. Vi er taknemmelige for, at vores arkitektur holdt DentroChat fuldt beskyttet mod ugens bølge af hændelser, men vi holder øje.

Vi evaluerer aktivt, hvordan vi kan forkorte reaktionstiden på fremtidige zero-day-exploits, stramme servergrænserne yderligere og holde dine data sikre, uanset hvor vild næste uge i cybersikkerhed bliver. Tak fordi du er en del af DentroChat!