En vill uke i cybersikkerhet: hvorfor EU AI-chatten vår holdt seg trygg gjennom de siste bruddene

tl;dr: Den tredje uken i oktober 2026 brakte en uvanlig bølge av sikkerhetshendelser i tech-bransjen, men DentroChat og dataene dine er trygge.

Hvis du følger sikkerhetsnyheter, føles denne uken som en flodbølge. Små varsler kommer hele tiden, men når så mange grunnleggende verktøy og skyplattformer rammes på få dager, er det, ærlig talt, WILD.

På mindre enn en uke rakk vi å få alt dette:

Hendelsen rundt sertifikatutstederen eMudhra: 8 mellomliggende CA-sertifikater under eMudhras emSign-rot viste seg å ha ekstremt svake private nøkler. Fordi nøklene kunne beregnes baklengs for å avlytte HTTPS-trafikk, måtte store nettlesere blokkere sertifikatene, eMudhra kunngjorde i dag at de forlater det globale SSL/TLS-sertifikatmarkedet helt (!), og det trengtes hastepatcher for uv, pip, Node.js, Bun, Go og Rust (!) for å fjerne den kompromitterte CA-en fra deres innebygde trust stores.
Kritiske CVE-er i sentral internettprogramvare: To uautentiserte remote code execution-sårbarheter ble patchet i PHP (CVE-2026-109618 og CVE-2026-109619), sammen med en kritisk buffer overflow i Google Brotli (CVE-2026-111497), en uautentisert RCE med høyeste alvor i GitLab (CVE-2026-110264) og Linux-kernel-sårbarheten “PwnEscape” (CVE-2026-99999).
LiteLLM supply chain-kompromittering: I går, 21. oktober, kapret angripere (igjen) LiteLLMs release-pipeline og dyttet en versjon med bakdør (v1.107.0) til PyPI og Docker Hub. Fordi den ondsinnede pakken hadde en startup-hook som kjørte automatisk hver gang Python startet, samlet den straks inn sky-legitimasjon og API-nøkler fra berørte servere.
Plattformbrudd hos Railway og Zeabur: Zeabur kunngjorde at de legger ned permanent etter et andre brudd som eksponerte 3,2 millioner poster med miljøvariabler fra 321 000 brukerkontoer. I går sa også Railway at en angriper hadde fått tilgang til og dekryptert kundenes miljøvariabler. Målet var interessant nok spesielt AI-inferensnøkler.
Store bedriftsbrudd: Angripere kom inn i Microsoft 365-kundetenants med stjålet backup-legitimasjon fra ConnectWise (SkyKick), og Capcom ble rammet av et brudd som påvirket 11,7 millioner brukerkontoer.

Er dette en “Cyberpocalypse”, eller våkner internettets immunforsvar?

Hvorfor dukker så mange gamle bugs opp samtidig i regex-kompilatorer, komprimeringsdekodere, minneallokatorer og kryptografiske oppsett?

Svaret er først og fremst at AI nå leser verdens kode. Sikkerhetsforskere og forsvarere (like mye som angripere) lar AI gå gjennom kildekoden i open source-biblioteker. Resultatet er at massevis av edge cases blir funnet, som menneskelige reviewers overså i 15 år. Selv de svake CA-nøklene hos eMudhra ble tydeligvis oppdaget med hjelp fra AI.

Noen kommentatorer kaller allerede uken for en “Cyberpocalypse”. Vi ser det heller slik: internettets immunforsvar våkner endelig og helbreder seg selv. De fleste av disse bugene har ligget i produksjonskode i årevis, og når de blir funnet, kan de endelig rettes.

Fordi jeg for alle de årene siden skrev bacheloroppgaven min ved TU Graz om tillitsmodellen og de strukturelle risikoene ved sertifikatutstedere, minnet eMudhra-kjeden som rullet videre til uv, pip, Node.js og Bun meg om hvorfor jeg valgte emnet den gangen. På internett tar tillit mange former og er et veldig komplekst system.

Hvor DentroChat står etter ukens hendelser

Hvis du bruker DentroChat til daglig arbeid og konfidensielle dokumenter, ble verken chattene eller filene dine berørt av noen av hendelsene. Fordi vi holder arkitekturen slank, er det meste av den rammede programvaren ikke engang en del av stacken vår, og det vi faktisk bruker, patchet vi med en gang:

CA-tillitsproblemet i uv, pip, Node.js og Bun: Kommandolinjeverktøy og runtimes har sin egen liste over betrodde sertifikatutstedere, så alt som stolte på eMudhras kompromitterte rotsertifikat, måtte oppdateres. DentroChat bruker verken uv eller pip på serverne sine. Webappen vår kjører derimot på Bun, så vi oppdaterte produksjonscontainere til Bun 1.4.4 (sammen med patchede Debian-systemsertifikater), som fjerner den kompromitterte eMudhra-roten helt.
LiteLLM (ond v1.107.0): Vi sender AI-forespørsler via en europeisk inferens-gateway (Cortecs), men vi bruker ikke Python-biblioteket LiteLLM eller Docker-bildene dets noe sted i stacken vår.
Railway, Zeabur og sky-deploy-plattformer: Vi hoster ikke på multi-tenant PaaS som Railway eller Zeabur, og vi lagrer heller ikke kundedata hos amerikanske hyperscalers eller i Microsoft-skyer. Som beskrevet på siden vår om Underdatabehandlere styrer vi deployments med vår egen selvhostede Coolify-instans som kjører direkte på de europeiske serverne våre. Ingen ekstern PaaS-leverandør sitter derfor på miljøvariablene eller deploy-hemmelighetene våre.
PHP, GitLab og applikasjonsavhengigheter: Vi kjører verken PHP eller selvhostet GitLab. I tillegg gikk vi gjennom og oppdaterte hele avhengighetstreet for både chatplattformen og nettstedet, og står nå på null kjente sårbarheter.

Slik bygger vi DentroChat for å holde dataene dine trygge

Fordi AI-assistert kodegjennomgang vil fortsette å finne nye CVE-er i open source, blir tredjepartspakker aldri helt “feilfrie”. Derfor har vi designet DentroChat med streng isolasjon, slik at en feil i én komponent ikke kan kompromittere dataene dine eller serverne våre.

1. Kodekjøring i en WebAssembly-sandbox uten nettverk

I år viste en omtalt sikkerhetsrapport at OpenAI-agenter brøt ut av sandkassen sin i en intern evaluering. Det var mulig fordi agentene kjørte i en Linux-container som fortsatt hadde nettverkstilgang til en intern pakkeproxy, og agenten utnyttet en zero-day i proxyen for å nå internett.

Hos DentroChat finnes ikke den angrepsveien (slik ting står nå), fordi vi ikke kjører brukerkode i en Linux-container med shell eller pakkeinstaller. Når du laster opp et regneark eller ber DentroChat kjøre Python-analyse, kjører koden i en isolert WebAssembly (WASM)-sandbox:

Hvert Python-bibliotek vi støtter for dataanalyse og dokumentoppretting pakkes inn ved build, så ingenting hentes fra PyPI eller en intern proxy ved kjøring.
Før Python i det hele tatt starter, klippes alle utgående nettverks-API-er, dynamiske biblioteksloadere og broer til vertsfilssystemet, og de fjernes fra runtime.
Selv om et Python-bibliotek skulle bære en supply chain-bakdør som LiteLLMs startup-skript, har WASM-sandboxen intet nettverk å sende data gjennom og ingen tilgang til serverens miljøvariabler eller andre brukeres filer. Når diagrammet eller dokumentet ditt er klart, tømmes det midlertidige arbeidsområdet igjen.

2. Syv dagers avkjøling mot supply chain-angrep

LiteLLM-angrepet fungerte slik:

den ondsinnede pakkeversjonen publiseres på PyPI
automatiserte build-pipelines over hele verden installerer den med en gang
etter to timer oppdager sikkerhetsforskere at noe er galt
da har ondsinnede kode allerede rukket mange systemer

For å stoppe den typen “supply chain attack” krever pakkehåndteringen vår, i tillegg til frosne lockfiler, en streng minimumsalder på syv dager for nye releases. En nylig publisert open source-versjon må klare en hel uke offentlig gransking før build-pipeline-en vår får installere den. Med mindre vi manuelt auditerer og pinner en akutt sikkerhetspatch, som dagens runtime-oppdatering…

3. Hvorfor vi blokkerer intern nettverkstilgang når AI-en besøker nettsider

Når du ber DentroChat lese en nettside eller hente åpne data fra et open data-API, henter serveren vår URL-en på dine vegne. Uten harde nettverksgrenser kunne en ondsinnet side gjemme instruksjoner som lokker AI-en til å be om interne serveradresser (som 127.0.0.1 eller interne Docker-nettverksporter) i stedet for et offentlig nettsted. Teknikken heter Server-Side Request Forgery (SSRF) og kunne avsløre interne tjenester på selve serveren.

Derfor løser den utgående fetcheren vår DNS før den kobler til, blokkerer alle private, loopback- og interne IP-intervaller og låser den verifiserte IP-adressen ved hver redirect. Selv om en side prøver å lure modellen eller bruker DNS rebinding for å bytte et domenes IP til 127.0.0.1 i siste millisekund, avvises tilkoblingen før den når det interne nettverket vårt.

4. Selvstyrt kryptering i ro hos Hetzner i Europa

Alle DentroChats applikasjonsservere, databaser og selvhostede verktøy kjører hos Hetzner i Tyskland, mens krypterte backups og pseudonymiserte serverlogger lagres hos Scaleway i Frankrike, alt under EU-jurisdiksjon og utenfor US CLOUD Act. Du kan når som helst gå gjennom hele infrastrukturen på siden vår om Underdatabehandlere.

Alle data er beskyttet med kryptering under transport og kryptering i ro. En teknisk detalj som ofte overses: hos de fleste hosting-leverandører (også Hetzner) er serverdiskene som standard ikke kryptert i ro. Derfor setter vi opp kryptering i ro og administrerer den selv. Denne sikre infrastrukturen passer sammen med de vanlige personvernkontrollene våre:

Ingen trening på chattene eller filene dine
Automatisk chatsletting som du styrer
Diskret chat-modus når du vil holde en samtale utenfor AI-minnet

Vi holder øye

God sikkerhet blir aldri “ferdig”.

Spesielt nå som både forskere og angripere finner zero-day-sårbarheter med AI raskere enn noen gang. Vi er takknemlige for at arkitekturen vår holdt DentroChat fullt beskyttet mot ukens bølge av hendelser, men vi holder øye.

Vi vurderer aktivt hvordan vi kan forkorte reaksjonstiden på fremtidige zero-day-exploits, stramme servergrensene ytterligere og holde dataene dine trygge uansett hvor vill neste uke i cybersikkerhet blir. Takk for at du er en del av DentroChat!