Szalony tydzień w cyberbezpieczeństwie: dlaczego nasz unijny czat AI pozostał bezpieczny mimo ostatnich wycieków

tl;dr: Trzeci tydzień października 2026 przyniósł wyjątkową falę incydentów bezpieczeństwa w całej branży tech, ale DentroChat i twoje dane są bezpieczne.

Jeśli śledzisz newsy o bezpieczeństwie, ten tydzień czuje się jak powódź. Drobne ostrzeżenia pojawiają się cały czas, ale gdy w kilka dni dotkniętych zostaje tyle fundamentalnych narzędzi i platform chmurowych, trzeba powiedzieć wprost: to WILD.

W mniej niż tydzień zdążyło się wydarzyć to wszystko:

• Incydent urzędu certyfikacji eMudhra: 8 pośrednich certyfikatów CA pod korzeniem emSign eMudhry okazało się mieć ekstremalnie słabe klucze prywatne. Ponieważ klucze dało się odtworzyć wstecz, by przechwytywać ruch HTTPS, główne przeglądarki musiały zablokować certyfikaty, eMudhra ogłosiła dziś całkowite wycofanie się z globalnego biznesu certyfikatów SSL/TLS (!), a uv, pip, Node.js, Bun, Go i Rust (!) potrzebowały pilnych aktualizacji, by usunąć skompromitowaną CA ze wbudowanych magazynów zaufania.
• Krytyczne CVE w kluczowym oprogramowaniu internetowym: W PHP załatano dwie luki zdalnego wykonania kodu bez uwierzytelnienia (CVE-2026-109618 i CVE-2026-109619), obok krytycznego przepełnienia bufora w Google Brotli (CVE-2026-111497), nieuwierzytelnionej RCE najwyższej wagi w GitLabie (CVE-2026-110264) oraz luki “PwnEscape” w jądrze Linuxa (CVE-2026-99999).
• Kompromitacja łańcucha dostaw LiteLLM: Wczoraj, 21 października, atakujący (znów) przejęli pipeline wydań LiteLLM i wypchnęli wersję z backdoorem (v1.107.0) do PyPI i Docker Hub. Ponieważ złośliwy pakiet zawierał hook startowy uruchamiany automatycznie przy każdym starcie Pythona, od razu zbierał dane dostępowe do chmury i klucze API z dotkniętych serwerów.
• Włamania na platformach Railway i Zeabur: Zeabur ogłosił trwałe zamknięcie po drugim incydencie, który ujawnił 3,2 miliona rekordów ze zmiennymi środowiskowymi z 321 000 kont użytkowników. Wczoraj Railway poinformował też, że atakujący uzyskał dostęp do zmiennych środowiskowych klientów i je odszyfrował. Celem były zaskakująco klucze inferencji AI.
• Duże włamania korporacyjne: Atakujący dostali się do tenantów klientów Microsoft 365 przy użyciu skradzionych danych backupu ConnectWise (SkyKick), a Capcom doświadczył wycieku dotyczącego 11,7 miliona kont użytkowników.

Czy to “Cyberpocalypse”, czy układ odporności internetu w końcu się budzi?

Dlaczego naraz wychodzi na jaw tyle starych błędów w kompilatorach regex, dekoderach kompresji, alokatorach pamięci i konfiguracjach kryptograficznych?

Odpowiedź jest przede wszystkim taka, że AI czyta teraz kod całego świata. Badacze bezpieczeństwa i obrońcy (tak samo jak atakujący) dają AI przeglądać kod bibliotek open source. Efekt: wychodzi mnóstwo przypadków brzegowych, które ludzie przegapiali przez 15 lat. Nawet słabe klucze CA u eMudhry zostały najwyraźniej wykryte z pomocą AI.

Część komentatorów nazywa ten tydzień już “Cyberpocalypse”. My widzimy to raczej tak: układ odporności internetu w końcu się budzi i leczy sam siebie. Większość tych bugów leżała w kodzie produkcyjnym od lat, a ich odkrycie oznacza, że wreszcie można je naprawić.

Ponieważ lata temu pisałem pracę licencjacką na TU Graz o modelu zaufania i ryzykach strukturalnych urzędów certyfikacji, kaskada eMudhry aż po uv, pip, Node.js i Bun przypomniała mi, dlaczego wtedy wybrałem ten temat. W internecie zaufanie ma wiele form i jest bardzo złożonym systemem.

Gdzie stoi DentroChat po incydentach z tego tygodnia

Jeśli używasz DentroChat do codziennej pracy i poufnych dokumentów, twoje rozmowy i pliki nie zostały dotknięte żadnym z tych incydentów. Ponieważ utrzymujemy szczupłą architekturę, większość dotkniętego oprogramowania w ogóle nie wchodzi w nasz stack, a to, czego używamy, natychmiast załataliśmy:

• Problem zaufania CA w uv, pip, Node.js i Bun: Narzędzia wiersza poleceń i runtime’y mają własną listę zaufanych urzędów certyfikacji, więc wszystko, co ufało skompromitowanemu korzeniowi eMudhry, musiało zostać zaktualizowane. DentroChat w ogóle nie używa uv ani pip na swoich serwerach. Nasza aplikacja webowa działa jednak na Bunie, więc zaktualizowaliśmy kontenery produkcyjne do Bun 1.4.4 (razem z załatanymi certyfikatami systemowymi Debiana), co całkowicie usuwa skompromitowany korzeń eMudhry.
• LiteLLM (złośliwe v1.107.0): Choć kierujemy zapytania AI przez europejską bramę inferencji (Cortecs), nigdzie w stacku nie używamy biblioteki Python LiteLLM ani jej obrazów Docker.
• Railway, Zeabur i platformy deploy w chmurze: Nie hostujemy na wielodostępnych PaaS dla deweloperów jak Railway czy Zeabur, ani nie przechowujemy danych klientów u amerykańskich hyperscalerów czy w tenantach chmury Microsoftu. Jak opisujemy na stronie Podwykonawcy, deploye zarządzamy własną samodzielnie hostowaną instancją Coolify, która działa bezpośrednio na naszych europejskich serwerach. Żaden zewnętrzny dostawca PaaS nie trzyma więc naszych zmiennych środowiskowych ani sekretów deploy.
• PHP, GitLab i zależności aplikacji: Nie uruchamiamy PHP ani self-hosted GitLaba. Poza tym przeskanowaliśmy i zaktualizowaliśmy całe drzewo zależności platformy czatu i strony, i obecnie mamy zero znanych podatności.

Jak projektujemy DentroChat, żeby twoje dane były bezpieczne

Ponieważ audyty kodu wspierane przez AI będą nadal ujawniać nowe CVE w open source, pakiety firm trzecich nigdy nie będą w pełni “bez bugów”. Dlatego zaprojektowaliśmy DentroChat ze ścisłą izolacją, żeby błąd w jednym komponencie nie mógł naruszyć twoich danych ani naszych serwerów.

1. Wykonywanie kodu w piaskownicy WebAssembly bez sieci

W tym roku viralowy raport bezpieczeństwa pokazał, że agenci OpenAI wyrwali się z piaskownicy podczas wewnętrznej oceny. Było to możliwe, bo agenci działali w kontenerze Linux z dostępem do wewnętrznego proxy rejestru pakietów, a agent wykorzystał zero-day w tym proxy, by dotrzeć do internetu.

W DentroChat ta ścieżka ataku nie istnieje (na ten moment), bo nie uruchamiamy kodu użytkownika w kontenerze Linux ze shellem ani instalatorem pakietów. Gdy wgrywasz arkusz albo prosisz DentroChat o analizę w Pythonie, kod działa w odizolowanej piaskownicy WebAssembly (WASM):

• Każda wspierana biblioteka Pythona do analizy danych i tworzenia dokumentów jest pakowana na etapie builda, więc w runtime nic nie jest pobierane z PyPI ani z wewnętrznego proxy pakietów.
• Zanim w ogóle uruchomi się Python, wszystkie wychodzące API sieciowe, dynamiczne loadery bibliotek i mosty do systemu plików hosta są odcięte i usuwane ze środowiska runtime.
• Nawet gdyby biblioteka Pythona kiedyś zawierała backdoor supply chain jak skrypt startowy LiteLLM, piaskownica WebAssembly nie ma połączenia sieciowego, by wysłać dane na zewnątrz, ani dostępu do zmiennych środowiskowych serwera czy plików innych użytkowników. Gdy wykres lub dokument jest gotowy, tymczasowy workspace jest znowu czyszczony.

2. Siedmiodniowy okres ochłodzenia przed atakami supply chain

Atak na LiteLLM działał tak:

1. złośliwa wersja pakietu trafia na PyPI
2. zautomatyzowane pipeline’y build na całym świecie instalują ją od razu
3. po 2 godzinach badacze bezpieczeństwa orientują się, że coś jest nie tak
4. do tego czasu złośliwy kod zdążył już dotknąć wielu systemów

Żeby powstrzymać takie “supply chain attack”, nasz menedżer pakietów, oprócz zamrożonych lockfile’ów, wymusza ścisłe minimum 7 dni od wydania. Świeżo opublikowana wersja open source musi przetrwać pełny tydzień publicznej weryfikacji, zanim pipeline build pozwoli ją zainstalować. Chyba że ręcznie audytujemy i przypinamy konkretną łatkę bezpieczeństwa, jak dzisiejsza aktualizacja runtime…

3. Dlaczego blokujemy dostęp do sieci wewnętrznej, gdy AI odwiedza strony

Gdy prosisz DentroChat o przeczytanie strony albo pobranie publicznego zbioru danych z API open data, nasz serwer pobiera ten URL w twoim imieniu. Bez twardych granic sieci złośliwa strona mogłaby ukryć instrukcje, które oszukują model, by żądał wewnętrznych adresów serwera (np. 127.0.0.1 lub wewnętrznych portów Docker) zamiast publicznej witryny. Technika ta nazywa się Server-Side Request Forgery (SSRF) i mogłaby ujawnić wewnętrzne usługi na samym serwerze.

Dlatego nasz wychodzący fetcher rozwiązuje DNS przed połączeniem, blokuje wszystkie prywatne, loopbackowe i wewnętrzne zakresy IP oraz przypina zweryfikowany adres IP przy każdym przekierowaniu. Nawet jeśli strona próbuje oszukać model albo używa DNS rebinding, by w ostatniej milisekundzie zmienić IP domeny na 127.0.0.1, połączenie jest odrzucane, zanim dotknie naszej sieci wewnętrznej.

4. Samodzielnie zarządzane szyfrowanie danych w spoczynku u Hetznera w Europie

Wszystkie serwery aplikacji DentroChat, bazy danych i samodzielnie hostowane narzędzia działają u Hetznera w Niemczech, podczas gdy szyfrowane kopie zapasowe i pseudonimizowane logi serwera trzymamy u Scaleway we Francji, wszystko pod jurysdykcją UE i poza amerykańskim CLOUD Act. Pełną infrastrukturę możesz w każdej chwili sprawdzić na naszej stronie Podwykonawcy.

Wszystkie dane są chronione szyfrowaniem w tranzycie i szyfrowaniem w spoczynku. Szczegół techniczny, który często umyka: u większości hostingodawców (także u Hetznera) dyski serwerów domyślnie w ogóle nie są szyfrowane w spoczynku. Dlatego szyfrowanie w spoczynku konfigurujemy i utrzymujemy sami. Ta bezpieczna infrastruktura dobrze współgra z naszymi standardowymi kontrolami prywatności:

• Brak trenowania na twoich rozmowach i plikach
• Automatyczne usuwanie czatów, które kontrolujesz
• Tryb dyskretnej rozmowy, gdy chcesz wykluczyć rozmowę z pamięci AI

Pozostajemy czujni

Dobre bezpieczeństwo nigdy nie jest “skończone”.

Tym bardziej teraz, gdy zarówno badacze, jak i atakujący znajdują luki zero-day z AI szybciej niż kiedykolwiek. Cieszymy się, że nasza architektura utrzymała DentroChat w pełni poza zasięgiem fali incydentów z tego tygodnia, ale pozostajemy czujni.

Aktywnie oceniamy, jak możemy jeszcze skrócić czas reakcji na przyszłe exploity zero-day, wzmocnić granice serwerów i chronić twoje dane, niezależnie od tego, jak szalony będzie kolejny tydzień w cyberbezpieczeństwie. Dziękujemy, że jesteś częścią DentroChat!