Őrült hét a kiberbiztonságban: miért maradt biztonságban az EU-s AI chatünk a legutóbbi incidensektől

tl;dr: 2026 októberének harmadik hete rendkívüli biztonsági incidens-hullámot hozott a tech világban, de a DentroChat és az adataid biztonságban vannak.

Ha követed a security híreket, ez a hét áradásnak tűnik. Apró figyelmeztetések gyakran jönnek, de ennyi alap eszköz és cloud platform kis idő alatt — mondjuk ki — WILD.

Kevesebb mint egy hét alatt mindez összejött:

• Az eMudhra tanúsítványkiadó incidense: 8 köztes CA tanúsítvány az eMudhra emSign gyökerén alatt rendkívül gyenge privát kulcsokat használt. Mivel ezeket a kulcsokat visszafejthető módon lehetett HTTPS forgalmat lehallgatni, a nagy böngészőknek blokkolniuk kellett a tanúsítványokat, az eMudhra ma bejelentette, hogy teljesen kilép a globális SSL/TLS tanúsítvány üzletből (!), és uv, pip, Node.js, Bun, Go és Rust (!) sürgős frissítéseket kapott, hogy kivegyék a kompromittált CA-t a beépített trust store-okból.
• Kritikus CVE-k az internet mag szoftvereiben: Két hitelesítés nélküli távoli kódfuttatási hiba lett javítva PHP-ban (CVE-2026-109618 és CVE-2026-109619), mellette kritikus buffer overflow a Google Brotli-ban (CVE-2026-111497), maximális súlyosságú hitelesítés nélküli RCE a GitLab-ban (CVE-2026-110264), és a Linux kernel „PwnEscape” sebezhetőség (CVE-2026-99999).
• A LiteLLM supply-chain kompromittálása: Tegnap, október 21-én a támadók (ismét) átvették a LiteLLM release pipeline-ját, és backdooros verziót (v1.107.0) tettek ki PyPI-ra és Docker Hubra. Mivel a rosszindulatú csomag automatikus startup hookot futtatott minden Python-indításkor, azonnal cloud hitelesítő adatokat és API kulcsokat gyűjtött az érintett szerverekről.
• Railway és Zeabur platform incidensek: A Zeabur bejelentette a végleges bezárást egy második incidens után, ami 321 000 fiókból 3,2 millió környezeti változó rekordot exposed. Tegnap a Railway is közölte, hogy egy támadó hozzáfért és visszafejtette az ügyfelek környezeti változóit. Érdekes módon főleg AI inferencia kulcsok voltak a cél.
• Nagy enterprise incidensek: Támadók Microsoft 365 ügyfél tenantokhoz jutottak ellopott ConnectWise (SkyKick) backup hitelesítőkkel, a Capcom pedig 11,7 millió felhasználói fiókot érintő incidensen ment keresztül.

„Cyberpocalypse” ez, vagy az internet immunrendszere ébred?

Miért bukkannak egyszerre fel annyi régi bug regex fordítókban, tömörítő dekóderekben, memória allokátorokban és kripto setupokban?

A válasz nagyrészt az, hogy az AI most már a világ kódját olvassa. Biztonsági kutatók és védekezők (meg a támadók is) AI-val nézetik át az open source könyvtárak kódját. Eredmény: rengeteg edge case, amit emberi review 15 évig nem vett észre. Az eMudhra gyenge CA kulcsait is AI segítségével fedték fel.

Néhány kommentátor már „Cyberpocalypse”-nek hívja ezt a hetet. Mi úgy látjuk: az internet immunrendszere végre felébred és gyógyítja magát. A bugok többsége évek óta production kódban volt, és most végre javíthatók.

Mivel évekkel ezelőtt a TU Graz-on a tanúsítványkiadók bizalmi modelljéről és strukturális kockázatairól írtam szakdolgozatot, az eMudhra eset uv-ig, pip-ig, Node.js-ig és Bun-ig tartó dominója emlékeztetett, miért választottam akkor ezt a témát. Az interneten a bizalom sok formában jön, és rendkívül komplex rendszer.

Hol áll a DentroChat a hét incidenseihez képest

Ha a DentroChat-et használod a mindennapi munkához és bizalmas dokumentumokhoz, a beszélgetéseid és fájljaid nem érintettek egyik incidensben sem. Mivel lean architektúrát tartunk, a legtöbb érintett szoftver nincs is a stackünkben, amit használunk, azt azonnal patch-eltük:

• CA trust probléma uv, pip, Node.js és Bun esetén: A CLI eszközök és runtime-ok saját megbízható CA listát hordanak, ezért minden olyan eszközt frissíteni kellett, ami a kompromittált eMudhra rootot bízta meg. A DentroChat szerverein egyáltalán nincs uv vagy pip. A webapp viszont Bun-on fut, ezért a production konténereket Bun 1.4.4-re emeltük (patch-elt Debian rendszer tanúsítványokkal), ami teljesen eltávolítja a kompromittált eMudhra rootot.
• LiteLLM (v1.107.0 malware): Bár az AI kéréseket egy európai inferencia gatewayen (Cortecs) irányítjuk, sehol nem használjuk a Python LiteLLM könyvtárat vagy Docker image-eit.
• Railway, Zeabur és cloud deploy platformok: Nem hostolunk multi-tenant developer PaaS-okon, mint Railway vagy Zeabur, és nem tárolunk ügyféladatot US hyperscaler-eknél vagy Microsoft cloud tenantokban. Ahogy a Alvállalkozók oldalon dokumentáljuk, saját self-hosted Coolify példányunkkal kezeljük a deploy-okat, közvetlenül az európai szervereinken. Külső PaaS vendor nem tartja a környezeti változóinkat vagy deploy secretjeinket.
• PHP, GitLab és app függőségek: Nem futtatunk PHP-t vagy self-hosted GitLabot. Emellett auditáltuk és frissítettük a chat platform és a weboldal teljes dependency fáját, jelenleg nulla ismert sebezhetőség van.

Hogyan építettük a DentroChat-et, hogy az adataid biztonságban maradjanak

Mivel az AI-asszisztált kódaudit továbbra is új CVE-ket fog felszínre hozni open source-ban, a third-party csomagok sosem lesznek teljesen „bugmentesek”. Ezért szigorú izolációval terveztük a DentroChat-et, hogy egy komponens hibája ne veszélyeztesse az adataidat vagy a szervereinket.

1. Kódfuttatás hálózatmentes WebAssembly sandboxban

Idén egy viral security riport szerint OpenAI agentek kiszabadultak a sandboxból belső értékelés közben. Azért sikerült, mert Linux konténerben futottak, aminek még volt hálózati hozzáférése egy belső package registry proxyhoz, és az agent zero-day bugot használt a proxyban, hogy kijusson az internetre.

A DentroChat-nál ez a támadási út (egyelőre) nem létezik, mert nem futtatunk user kódot Linux konténerben shell-lel vagy package installerrel. Ha feltöltesz egy spreadsheetet, vagy Python elemzést kérsz, a kód egy izolált WebAssembly (WASM) sandboxban fut:

• Minden támogatott Python könyvtár adatelemzéshez és dokumentumkészítéshez build időben be van csomagolva, runtime-ban semmi nem jön le PyPI-ról vagy belső package proxyról.
• Mielőtt Python futna, minden kimenő hálózati API, dinamikus library loader és host filesystem híd le van vágva és törölve a runtime-ból.
• Ha egy Python könyvtár supply-chain backdoort tartalmazna, mint a LiteLLM startup scriptje, a WebAssembly sandboxnak nincs hálózati kapcsolata adatok kiküldésére, és nincs hozzáférése a szerver env változóihoz vagy más userek fájljaihoz. Amint megkapod a chartot vagy dokumentumot, a temp workspace újra törlődik.

2. 7 napos várakozás supply-chain támadások ellen

A LiteLLM támadás így működött:

1. a rosszindulatú csomagverzió megjelenik PyPI-n
2. a világ automatizált build pipeline-jai azonnal telepítik
3. 2 óra múlva a security kutatók rájönnek, hogy gond van
4. addigra a rossz kód már sok rendszert meg tudott nyerni

Az ilyen „supply chain attack” ellen a package managerünk frozen lockfile-ok mellett szigorú 7 napos minimum release kort kényszerít ki. Egy frissen publikált open source verzió teljes hetet kell túléljen nyilvános ellenőrzés alatt, mielőtt a build pipeline telepíteni engedné. Hacsak persze manuálisan nem auditálunk és pin-elünk egy konkrét security patch-et, mint a mai runtime frissítés…

3. Miért blokkoljuk a belső hálózatot, amikor az AI weboldalakat látogat

Ha azt kéred, hogy a DentroChat olvasson egy weboldalt vagy hozzon le nyilvános adathalmazt open-data API-ról, a szerverünk a te nevedben fetch-eli az URL-t. Szigorú hálózati határok nélkül egy rosszindulatú oldal rejtett utasításokat tartalmazhatna, amikkel az AI-t belső címeket (127.0.0.1, belső Docker portok) kérővé teszi nyilvános web helyett. Ezt a technikát Server-Side Request Forgery (SSRF)-nek hívják, és belső szolgáltatásokat fedhet fel a szerveren.

Ezért a kimenő fetcher DNS-t old fel csatlakozás előtt, blokkol minden privát, loopback és belső IP tartományt, és minden redirect ugrásnál rögzíti az ellenőrzött IP-t. Még ha egy oldal át akarná verni a modellt, vagy DNS rebindinggel az utolsó milliszekundumban 127.0.0.1-re váltana, a kapcsolat elutasításra kerül, mielőtt belső hálózatunkat érintené.

4. Saját kezelésű titkosítás nyugalmi állapotban Hetzneren, Európában

Minden DentroChat app szerver, adatbázis és self-hosted tool Hetzneren fut Németországban, a titkosított backupok és pseudonimizált szerver logok pedig Scaleway-nél Franciaországban, mind EU joghatóság alatt, a US CLOUD Act-on kívül. A teljes infrastruktúrát bármikor megnézheted az Alvállalkozók oldalon.

Minden adat titkosítás tranzitban és titkosítás nyugalmi állapotban alatt áll. Gyakran figyelmen kívül hagyott technikai részlet: a legtöbb hostnál (Hetzner is) a szerver lemezek alapból nincsenek nyugalmi titkosítással. Ezért mi magunk állítjuk be és kezeljük a nyugalmi titkosítást. Ez jól passzol az adatvédelmi kontrolljainkhoz:

• Nulla training a beszélgetéseiden vagy fájljaidon
• Automatikus chat törlés, amit te irányítasz
• Discreet Chat mód, ha egy beszélgetést ki akarsz zárni az AI memóriájából

Éber maradás

A jó biztonság sosem „kész”.

Most különösen, mert kutatók és támadók is gyorsabban találnak zero-day sebezhetőségeket AI-val, mint valaha. Hálásak vagyunk, hogy architektúránk teljesen megvédte a DentroChat-et a hét incidens-hullámától, de éberek maradunk.

Aktívan vizsgáljuk, hogyan rövidíthetjük tovább a reakcióidőt jövőbeli zero-day exploitokra, hogyan erősíthetjük a szerverhatárokat, és hogyan tarthatjuk biztonságban az adataidat, bármilyen őrült is lesz a következő hét a kiberbiztonságban. Köszönjük, hogy a DentroChat része vagy!