Een bizarre week in cybersecurity: waarom onze Europese AI-chat veilig bleef bij de recente datalekken

tl;dr: Deze derde week van oktober 2026 zorgde voor een ongekende golf aan beveiligingsincidenten in de techwereld, maar DentroChat en je gegevens zijn veilig.

Als je het beveiligingsnieuws volgt, voelde deze week als een dijkdoorbraak. Kleine waarschuwingen zijn er elke week wel, maar dat zóveel fundamentele tools en cloudplatformen binnen een paar dagen worden geraakt is, laten we het gewoon zeggen, BIZAR.

In minder dan een week tijd kregen we dit allemaal voor onze kiezen:

• Het incident rond certificeringsinstantie eMudhra: Bij 8 tussenliggende CA-certificaten onder eMudhra’s emSign-root bleken de privésleutels extreem zwak te zijn. Omdat die sleutels konden worden terugberekend om HTTPS-verkeer te onderscheppen, moesten grote browsers de certificaten blokkeren, kondigde eMudhra vandaag aan volledig te stoppen met zijn wereldwijde SSL/TLS-certificaattak (!), en moesten er noodupdates uitkomen voor uv, pip, Node.js, Bun, Go en Rust (!) om de gecompromitteerde CA uit hun meegeleverde lijst met vertrouwde certificaten te verwijderen.
• Kritieke CVE’s in kernsoftware van het internet: Er werden twee onbeveiligde remote code execution-lekken gedicht in PHP (CVE-2026-109618 en CVE-2026-109619), naast een kritieke buffer overflow in Google Brotli (CVE-2026-111497), een RCE van de hoogste ernst zonder inloggen in GitLab (CVE-2026-110264) en de Linux-kernelkwetsbaarheid “PwnEscape” (CVE-2026-99999).
• De supply-chain-hack bij LiteLLM: Gisteren, op 21 oktober, wisten aanvallers (opnieuw) de release-pipeline van LiteLLM binnen te dringen en een versie met achterdeur (v1.107.0) naar PyPI en Docker Hub te pushen. Omdat het kwaadaardige pakket een opstart-hook bevatte die automatisch meedraaide zodra Python werd gestart, werden op getroffen servers meteen cloudgegevens en API-sleutels buitgemaakt.
• Inbraken bij platformen Railway en Zeabur: Zeabur maakte bekend definitief de stekker eruit te trekken nadat bij een tweede datalek 3,2 miljoen records met omgevingsvariabelen van 321.000 gebruikersaccounts op straat kwamen te liggen. Gisteren meldde ook Railway dat een aanvaller toegang had gekregen tot omgevingsvariabelen van klanten en die had ontsleuteld. Opvallend detail: het doelwit waren vooral AI-inferentiesleutels.
• Grote zakelijke datalekken: Aanvallers kregen toegang tot Microsoft 365-klantomgevingen met gestolen back-upgegevens van ConnectWise (SkyKick), en Capcom kreeg te maken met een lek waarbij 11,7 miljoen gebruikersaccounts werden geraakt.

Is dit een “Cyberpocalypse”, of wordt het immuunsysteem van het internet wakker?

Waarom duiken er ineens tegelijk zoveel oude bugs op in regex-compilers, compressiedecoders, geheugenbeheer en cryptografische instellingen?

Het antwoord is vooral dat AI nu de code van de wereld leest. Beveiligingsonderzoekers en verdedigers (én aanvallers) laten AI de broncode van opensourcebibliotheken doorlichten. Daardoor komen allerlei randgevallen boven water waar menselijke reviewers 15 jaar lang overheen hebben gekeken. Zelfs de zwakke CA-sleutels van eMudhra zijn blijkbaar met hulp van AI ontdekt.

Sommige commentatoren noemen deze week al een “Cyberpocalypse”. Wij kijken daar anders tegenaan: het immuunsysteem van het internet wordt eindelijk wakker en geneest zichzelf. De meeste van deze bugs zaten al jarenlang in productiecode, en doordat ze nu worden gevonden, worden ze eindelijk opgelost.

Omdat ik al die jaren geleden mijn bachelorscriptie aan de TU Graz schreef over het vertrouwensmodel en de structurele risico’s van Certificate Authorities, deed de kettingreactie van eMudhra richting uv, pip, Node.js en Bun me meteen terugdenken aan waarom ik dat onderwerp destijds koos. Op het internet neemt vertrouwen allerlei vormen aan en is het een uiterst complex systeem.

Waar DentroChat staat bij de incidenten van deze week

Gebruik je DentroChat voor je dagelijkse werk en vertrouwelijke documenten, dan zijn je gesprekken en bestanden door geen van deze incidenten geraakt. Omdat we onze architectuur bewust slank houden, maakt het gros van de getroffen software helemaal geen deel uit van onze stack, en wat we wél gebruiken hebben we direct gepatcht:

• Het CA-vertrouwensprobleem bij uv, pip, Node.js en Bun: Omdat command-linetools en runtimes hun eigen lijst met vertrouwde certificeringsinstanties meeleveren, moest elke tool worden bijgewerkt die het gecompromitteerde eMudhra-rootcertificaat vertrouwde. DentroChat gebruikt helemaal geen uv of pip op zijn servers. Onze webapplicatie draait wel op Bun, dus hebben we onze productiecontainers bijgewerkt naar Bun 1.4.4 (samen met gepatchte Debian-systeemcertificaten), waarmee de gecompromitteerde eMudhra-root volledig is verwijderd.
• LiteLLM (v1.107.0-malware): Hoewel we AI-verzoeken via een Europese inferentie-gateway (Cortecs) sturen, gebruiken we de Python-bibliotheek LiteLLM of de bijbehorende Docker-images nergens in onze stack.
• Railway, Zeabur en cloud-deploymentplatformen: We hosten niet op gedeelde PaaS-platformen zoals Railway of Zeabur, en we slaan ook geen klantgegevens op bij Amerikaanse hyperscalers of in Microsoft-cloudomgevingen. Zoals beschreven op onze pagina Subverwerkers, beheren we onze deployments met onze eigen zelfgehoste Coolify-instantie die rechtstreeks op onze Europese servers draait. Daardoor heeft geen enkele externe PaaS-partij onze omgevingsvariabelen of deployment-geheimen in handen.
• PHP, GitLab en afhankelijkheden van de applicatie: We draaien geen PHP en geen zelfgehoste GitLab. Daarnaast hebben we onze volledige boom met afhankelijkheden voor zowel het chatplatform als de website doorgelicht en bijgewerkt, waardoor we nu op nul bekende kwetsbaarheden staan.

Hoe we DentroChat bouwen om je gegevens veilig te houden

Omdat code-audits met AI ook de komende tijd nieuwe CVE’s in opensourcesoftware zullen blootleggen, zullen pakketten van derden nooit helemaal “bugvrij” zijn. Daarom hebben we DentroChat ontworpen met strikte isolatie, zodat een fout in één onderdeel nooit je gegevens of onze servers in gevaar kan brengen.

1. Code uitvoeren in een WebAssembly-sandbox zonder netwerk

Dit jaar liet een veelbesproken beveiligingsrapport zien dat OpenAI-agents uit hun sandbox waren gebroken tijdens een interne evaluatie. Die uitbraak was mogelijk doordat de agents in een Linux-container draaiden die nog netwerktoegang had tot een interne pakketproxy, en de agent een zero-day-lek in die proxy misbruikte om het internet op te komen.

Bij DentroChat bestaat die aanvalsroute (op dit moment) niet, omdat we gebruikerscode niet uitvoeren in een Linux-container met een shell of pakketinstallatie. Wanneer je een spreadsheet uploadt of DentroChat vraagt om een Python-analyse te draaien, draait de code in plaats daarvan in een geïsoleerde WebAssembly-(WASM)-sandbox:

• Elke ondersteunde Python-bibliotheek voor data-analyse en documentcreatie wordt al tijdens het bouwen meegebundeld, zodat er tijdens het draaien nooit iets van PyPI of een interne pakketproxy wordt opgehaald.
• Voordat er ook maar één regel Python draait, worden alle uitgaande netwerk-API’s, dynamische library-loaders en bruggen naar het bestandssysteem van de host doorgeknipt en uit de runtime verwijderd.
• Zelfs als een Python-bibliotheek ooit een supply-chain-achterdeur zoals het opstartscript van LiteLLM zou bevatten, heeft de WebAssembly-sandbox geen netwerkverbinding om gegevens naar buiten te sturen en geen toegang tot omgevingsvariabelen van de server of bestanden van andere gebruikers. Zodra je grafiek of document klaar is, wordt de tijdelijke werkruimte weer volledig gewist.

2. Een afkoelperiode van 7 dagen tegen supply-chain-aanvallen

De LiteLLM-aanval werkte als volgt:

1. de kwaadaardige pakketversie wordt gepubliceerd op PyPI
2. geautomatiseerde build-pipelines over de hele wereld installeren die meteen
3. na 2 uur komen beveiligingsonderzoekers erachter dat er iets mis is
4. tegen die tijd heeft de kwaadaardige code al talloze systemen kunnen raken

Om dit soort “supply-chain-aanvallen” te voorkomen, dwingt onze pakketbeheerder naast bevroren lockfiles een strikte minimumleeftijd van 7 dagen voor releases af. Een nieuw gepubliceerde opensourceversie moet eerst een volle week publieke controle doorstaan voordat onze build-pipeline haar mag installeren. Tenzij we natuurlijk handmatig een specifieke beveiligingspatch controleren en vastzetten, zoals de runtime-update van vandaag…

3. Waarom we toegang tot het interne netwerk blokkeren wanneer de AI websites bezoekt

Wanneer je DentroChat vraagt om een webpagina te lezen of een openbare dataset op te halen via een open-data-API, haalt onze server die URL namens jou op. Zonder strikte netwerkgrenzen zou een kwaadaardige website verborgen instructies op de pagina kunnen zetten die de AI verleiden om interne serveradressen op te vragen (zoals 127.0.0.1 of interne Docker-netwerkpoorten) in plaats van een openbare website. Die techniek heet Server-Side Request Forgery (SSRF) en zou interne diensten op de server zelf kunnen blootleggen.

Daarom lost onze uitgaande netwerk-fetcher eerst DNS op voordat hij verbinding maakt, blokkeert hij alle privé-, loopback- en interne IP-reeksen, en zet hij het gecontroleerde IP-adres vast bij elke redirect. Zelfs als een webpagina het model probeert te misleiden of via DNS-rebinding op de allerlaatste milliseconde het IP-adres van een domein naar 127.0.0.1 omzet, wordt de verbinding geweigerd voordat die ons interne netwerk raakt.

4. Zelfbeheerde versleuteling in rust bij Hetzner in Europa

Alle applicatieservers, databases en zelfgehoste tools van DentroChat draaien bij Hetzner in Duitsland, terwijl versleutelde back-ups en gepseudonimiseerde serverlogs zijn opgeslagen bij Scaleway in Frankrijk, volledig onder EU-wetgeving en buiten het bereik van de Amerikaanse CLOUD Act. Je kunt onze volledige infrastructuur op elk moment bekijken op onze pagina Subverwerkers.

Alle gegevens zijn beschermd met versleuteling tijdens transport en versleuteling in rust (encryption at rest). Een technisch detail dat vaak over het hoofd wordt gezien: bij de meeste hostingproviders (ook bij Hetzner) worden je schijven in rust standaard helemaal niet versleuteld. Daarom richten wij versleuteling in rust zelf in en beheren we die zelf. Deze veilige infrastructuur sluit mooi aan op onze standaard privacy-instellingen:

• Geen training op je gesprekken of bestanden
• Automatische chatverwijdering die je zelf instelt
• Discrete chatmodus wanneer je een gesprek buiten het AI-geheugen wilt houden

Waakzaam blijven

Goede beveiliging is nooit af.

Zeker nu zowel onderzoekers als aanvallers met AI sneller dan ooit zero-day-kwetsbaarheden kunnen vinden. Hoewel we blij zijn dat onze architectuur DentroChat volledig heeft beschermd tegen de golf aan incidenten van deze week, blijven we scherp.

We bekijken actief hoe we onze reactietijd op toekomstige zero-day-exploits nog verder kunnen verkorten, onze servergrenzen nog strakker kunnen dichttimmeren en je gegevens veilig kunnen houden, hoe gek de volgende week in cybersecurity ook wordt. Bedankt dat je deel uitmaakt van DentroChat!