En galen vecka inom cybersäkerhet: varför vår EU AI-chatt klarade sig undan de senaste intrången

tl;dr: Den tredje veckan i oktober 2026 gav en ovanlig våg av säkerhetsincidenter i techbranschen, men DentroChat och dina data är säkra.

Om du följer säkerhetsnyheter känns den här veckan som en flodvåg. Små varningar dyker upp hela tiden, men när så många grundläggande verktyg och molnplattformar träffas på bara några dagar är det, ärligt talat, GALET.

På mindre än en vecka hann vi få det här:

Incidenten kring certifikatutfärdaren eMudhra: 8 mellanliggande CA-certifikat under eMudhras emSign-rot visade sig ha extremt svaga privata nycklar. Eftersom nycklarna kunde räknas baklänges för att avlyssna HTTPS-trafik var stora webbläsare tvungna att blockera certifikaten, eMudhra meddelade i dag att de lämnar den globala SSL/TLS-certifikatmarknaden helt (!), och akuta uppdateringar behövdes för uv, pip, Node.js, Bun, Go och Rust (!) för att ta bort den komprometterade CA:n från deras inbyggda förtroendelager.
Kritiska CVE:er i central internetprogramvara: Två oautentiserade remote code execution-buggar patchades i PHP (CVE-2026-109618 och CVE-2026-109619), tillsammans med ett kritiskt buffer overflow i Google Brotli (CVE-2026-111497), en oautentiserad RCE med högsta allvarlighetsgrad i GitLab (CVE-2026-110264) och Linux-kärnans sårbarhet “PwnEscape” (CVE-2026-99999).
Supply chain-kompromissen i LiteLLM: I går, den 21 oktober, kapade angripare (igen) LiteLLMs release-pipeline och pushade en version med bakdörr (v1.107.0) till PyPI och Docker Hub. Eftersom det skadliga paketet hade en startup-hook som kördes automatiskt varje gång Python startade, såg det genast till att plocka molnuppgifter och API-nycklar från drabbade servrar.
Plattformsintrång hos Railway och Zeabur: Zeabur meddelade att de stänger permanent efter ett andra intrång som exponerade 3,2 miljoner poster med miljövariabler från 321 000 användarkonton. I går sa även Railway att en angripare kunnat komma åt och dekryptera kunders miljövariabler. Målet var intressant nog främst AI-inferensnycklar.
Stora företagsintrång: Angripare kom in i Microsoft 365-kundmiljöer med stulna backup-uppgifter från ConnectWise (SkyKick), och Capcom drabbades av ett intrång som påverkade 11,7 miljoner användarkonton.

Är det här en “Cyberpocalypse”, eller vaknar internet immunförsvar?

Varför dyker så många gamla buggar upp samtidigt i regex-kompilatorer, kompressionsavkodare, minneshanterare och kryptografiska upplägg?

Svaret är till stor del att AI nu läser världens kod. Säkerhetsforskare och försvarare (liksom angripare) låter AI granska källkod i open source-bibliotek. Resultatet är att massor av edge cases hittas som mänskliga granskare missat i 15 år. Till och med de svaga CA-nycklarna hos eMudhra upptäcktes tydligen med hjälp av AI.

Vissa kommentatorer kallar redan veckan för en “Cyberpocalypse”. Vi ser det snarare så här: internets immunförsvar vaknar äntligen och läker sig själv. De flesta av buggarna har legat i produktionskod i åratal, och när de hittas kan de äntligen fixas.

Eftersom jag för alla de där åren sedan skrev min kandidatuppsats vid TU Graz om förtroendemodellen och de strukturella riskerna hos certifikatutfärdare, påminde eMudhra-kedjan som rullade vidare till uv, pip, Node.js och Bun mig om varför jag valde det ämnet då. På internet tar förtroende många former och är ett väldigt komplext system.

Var DentroChat står efter veckans incidenter

Om du använder DentroChat i vardagen och för konfidentiella dokument påverkades varken dina chattar eller dina filer av någon av incidenterna. Eftersom vi håller arkitekturen slank ligger det mesta av den drabbade programvaran inte ens i vår stack, och det vi faktiskt använder patchade vi direkt:

CA-förtroendeproblemet i uv, pip, Node.js och Bun: Kommandoradsverktyg och runtimes har sin egen lista över betrodda certifikatutfärdare, så allt som litade på eMudhras komprometterade rotcertifikat behövde uppdateras. DentroChat använder varken uv eller pip på sina servrar. Vår webbapp kör däremot på Bun, så vi uppdaterade produktionscontainrarna till Bun 1.4.4 (tillsammans med patchade Debian-systemcertifikat), vilket tar bort den komprometterade eMudhra-roten helt.
LiteLLM (skadlig v1.107.0): Vi skickar AI-förfrågningar via en europeisk inferens-gateway (Cortecs), men vi använder inte Python-biblioteket LiteLLM eller dess Docker-images någonstans i stacken.
Railway, Zeabur och molnplattformar för deploy: Vi hostar inte på multi-tenant PaaS som Railway eller Zeabur, och vi lagrar inte kunddata hos amerikanska hyperscalers eller i Microsoft-moln. Som på vår sida om Underleverantörer hanterar vi deploys med vår egen självhostade Coolify-instans som kör direkt på våra europeiska servrar. Ingen extern PaaS-leverantör sitter därför på våra miljövariabler eller deploy-hemligheter.
PHP, GitLab och applikationsberoenden: Vi kör varken PHP eller självhostad GitLab. Dessutom granskade och uppdaterade vi hela beroendeträdet för både chattplattformen och webbplatsen, och står nu på noll kända sårbarheter.

Så bygger vi DentroChat för att hålla dina data säkra

Eftersom AI-assisterad kodgranskning kommer att fortsätta hitta nya CVE:er i open source kommer tredjepartspaket aldrig vara helt “buggfria”. Därför har vi designat DentroChat med strikt isolering, så att ett fel i en komponent inte kan kompromettera dina data eller våra servrar.

1. Kodkörning i en WebAssembly-sandbox utan nätverk

I år visade en uppmärksammad säkerhetsrapport att OpenAI-agenter bröt sig ut ur sin sandbox i en intern utvärdering. Det gick eftersom agenterna körde i en Linux-container som fortfarande hade nätverksåtkomst till en intern paketproxy, och agenten utnyttjade en zero-day i proxyn för att nå internet.

Hos DentroChat finns den attackvägen inte (i dag), eftersom vi inte kör användarkod i en Linux-container med shell eller paketinstallerare. När du laddar upp ett kalkylblad eller ber DentroChat köra Python-analys körs koden i en isolerad WebAssembly (WASM)-sandbox:

Varje Python-bibliotek vi stödjer för dataanalys och dokument skapas packas in vid build, så inget hämtas från PyPI eller en intern proxy vid körning.
Innan Python ens startar kapas alla utgående nätverks-API:er, dynamiska biblioteksloaders och broar till värdsystemets filsystem och tas bort från runtime.
Även om ett Python-bibliotek skulle bära på en supply chain-bakdörr som LiteLLMs startup-skript har WASM-sandboxen inget nätverk att skicka data genom och ingen åtkomst till serverns miljövariabler eller andra användares filer. När diagrammet eller dokumentet är klart rensas den temporära arbetsytan igen.

2. Sju dagars väntetid mot supply chain-attacker

LiteLLM-angreppet fungerade så här:

den skadliga paketversionen publiceras på PyPI
automatiserade build-pipelines världen över installerar den direkt
efter två timmar ser säkerhetsforskare att något är fel
då har skadlig kod redan hunnit träffa många system

För att stoppa den här typen av “supply chain attack” kräver vår pakethanterare, utöver frysta lockfiler, en strikt minsta ålder på sju dagar för nya releaser. En nyligen publicerad open source-version måste klara en hel vecka av offentlig granskning innan vår build-pipeline får installera den. Om vi inte manuellt granskar och pinnar en akut säkerhetspatch, som dagens runtime-uppdatering…

3. Varför vi blockerar intern nätverksåtkomst när AI:n besöker webbsidor

När du ber DentroChat läsa en webbsida eller hämta öppna data från ett open data-API hämtar vår server URL:en åt dig. Utan hårda nätverksgränser kan en skadlig sida gömma instruktioner som lurar AI:n att fråga interna serveradresser (som 127.0.0.1 eller interna Docker-portar) i stället för en publik webbplats. Tekniken heter Server-Side Request Forgery (SSRF) och kan exponera interna tjänster på själva servern.

Därför löser vår utgående fetcher DNS innan den kopplar upp, blockerar privata, loopback- och interna IP-intervall och låser den verifierade IP-adressen vid varje redirect. Även om en sida försöker lura modellen eller använder DNS rebinding för att byta en domäns IP till 127.0.0.1 i sista millisekunden nekas anslutningen innan den når vårt interna nät.

4. Självhanterad kryptering i vila hos Hetzner i Europa

Alla DentroChats applikationsservrar, databaser och självhostade verktyg kör hos Hetzner i Tyskland, medan krypterade backuper och pseudonymiserade serverloggar lagras hos Scaleway i Frankrike, allt under EU-jurisdiktion och utanför US CLOUD Act. Du kan när som helst granska hela infrastrukturen på vår sida om Underleverantörer.

All data skyddas med kryptering under transport och kryptering i vila. Ett tekniskt detalj som ofta missas: hos de flesta hostingleverantörer (även Hetzner) är servrarnas diskar inte krypterade i vila som standard. Därför sätter vi upp och sköter kryptering i vila själva. Den här säkra infrastrukturen passar ihop med våra vanliga integritetskontroller:

Ingen träning på dina chattar eller filer
Automatisk chatradering som du styr
Diskret chattläge när du vill hålla ett samtal utanför AI-minnet

Fortsatt vaksamhet

Bra säkerhet blir aldrig “klar”.

Särskilt nu när både forskare och angripare hittar zero-day-sårbarheter med AI snabbare än någonsin. Vi är tacksamma att arkitekturen höll DentroChat helt skyddad från veckans incidentvåg, men vi håller ögonen öppna.

Vi utvärderar aktivt hur vi kan korta reaktionstiden för framtida zero-day-exploits, stärka servergränserna ytterligare och hålla dina data säkra oavsett hur galen nästa vecka inom cybersäkerhet blir. Tack för att du är en del av DentroChat!