Krytyczna luka w DeepSeek Harness. Serwer da się przejąć zdalnie

Czy narzędzie AI da się przejąć bez hasła, wyłącznie przez źle sprawdzony nagłówek HTTP? Niestety tak. QiAnXin Threat Intelligence Center ujawnił krytyczną lukę w DeepSeek Harness, a sprawa jest poważna - mówimy o zdalnym wykonaniu kodu bez uwierzytelnienia.

Ten news nie dotyczy wyłącznie programistów. Jeśli Twoja firma testuje agentów AI, wystawia panele zarządzania do internetu albo zakłada, że open source „pewnie ktoś już sprawdził” (klasyk), to ten przypadek jest bardzo praktyczną lekcją.

Jak działa luka w DeepSeek Harness?

QiAnXin opisał podatność oznaczoną jako QVD-2026-57410. Dotyczy ona DeepSeek Harness 0.1.1-rc.2, czyli otwartoźródłowej platformy agentowej AI. Luka ma ocenę CVSS 9.8, więc trafia do najwyższej kategorii ryzyka.

Źródłem problemu jest błędna walidacja nagłówka HTTP Host. To element żądania, który mówi serwerowi, pod jaki adres trafia ruch. Gdy aplikacja ufa temu nagłówkowi bardziej, niż powinna, atakujący może podszyć się pod zaufane żądanie i ominąć część zabezpieczeń.

W tym przypadku chodzi o obejście tzw. /api trust fence, czyli bariery zaufania przy API. Po sfałszowaniu nagłówka Host atakujący może wywołać ograniczone wewnętrzne metody RPC, zarejestrować fałszywego dostawcę dużego modelu i skłonić narzędzie Agent do wykonania dowolnych poleceń systemowych na serwerze.

Skąd bierze się skala ryzyka?

Najgorsza część jest prosta: atak nie wymaga poprawnego klucza API ani logowania. Jeśli exploit się powiedzie, polecenia uruchamiają się z uprawnieniami procesu usługi DeepSeek Harness na docelowym serwerze.

To daje bardzo szerokie pole działania. Źródło wprost wskazuje trzy skutki: kradzież danych, instalację backdoora oraz ruch boczny w sieci, czyli przechodzenie z jednego systemu do kolejnych. Dla firmy to już nie „błąd w aplikacji”, ale potencjalny punkt wejścia do większego incydentu.

Dodatkowo kod proof-of-concept jest już publiczny. Internet od tego nie płonie natychmiast, ale jedno jest jasne: bariera wejścia dla atakujących spada. Gdy techniczny przepis jest gotowy, czas reakcji staje się ważniejszy niż firmowe deklaracje o bezpieczeństwie.

Kiedy taki atak faktycznie może zadziałać?

Tu jest ważny niuans. Nie każda instalacja DeepSeek Harness od razu nadaje się do przejęcia. Źródło wskazuje konkretne warunki potrzebne do skutecznego ataku:

• API zarządzające DeepSeek Harness musi być wystawione do publicznego internetu,
• system nie może rygorystycznie sprawdzać nagłówka Host,
• atakujący musi kontrolować zewnętrzną usługę osiągalną z zaatakowanej instancji.

Jeśli te warunki się składają, ryzyko rośnie bardzo mocno. Jeśli nie - zagrożenie spada, ale nie znika z radaru. Publicznie wystawione panele administracyjne od lat wyglądają wygodnie tylko do pierwszego incydentu.

Na moment ujawnienia luki nie potwierdzono aktywnego wykorzystywania jej w realnych atakach. Nie ma też dowodów łączących tę podatność ze znanymi grupami zagrożeń. To dobra wiadomość, ale nie taka, przy której odkładasz temat na przyszły tydzień.

Co zaleca QiAnXin i gdzie firmy najczęściej wykładają się w praktyce?

Dobra, powiedzmy to wprost: lista zaleceń jest dość podstawowa, a mimo to wiele zespołów wciąż ją pomija. QiAnXin rekomenduje trzy działania. Po pierwsze, odizolowanie portu API zarządzającego od publicznej sieci i dopuszczenie tylko zaufanych wewnętrznych adresów IP. Po drugie, wymuszenie ścisłej walidacji nagłówka Host na warstwie reverse proxy. Po trzecie, śledzenie oficjalnych komunikatów bezpieczeństwa DeepSeek i aktualizacja do poprawionej wersji.

Dokumentacja techniczna idzie krok dalej. Zaleca dodanie mechanizmu uwierzytelniania przy /api trust fence, który nie zależy od nagłówka Host. Do tego dochodzi ograniczenie interfejsu llm.discoverModels, żeby zmniejszyć ryzyko SSRF, czyli sytuacji, w której serwer daje się nakłonić do wykonywania żądań tam, gdzie nie powinien.

Jeśli prowadzisz firmę albo odpowiadasz za wdrożenia AI, ten przypadek pokazuje jedną rzecz: agenci AI to nie tylko modele i prompty. To także warstwa infrastruktury, API, proxy i uprawnień. Właśnie dlatego dyskusja o bezpieczeństwie modeli open-weight wraca coraz częściej, o czym pisaliśmy przy okazji tekstu o amerykańskich restrykcjach wobec modeli open-weight.

To także kolejny sygnał, że regulacje i bezpieczeństwo zaczynają iść ramię w ramię. Jeśli śledzisz ten kierunek, zajrzyj też do analizy o tym, jak przyspieszają regulacje wokół rogue AI oraz do tekstu o unijnym kodeksie przejrzystości AI. Z polskiej perspektywy wniosek jest prosty: firmy wdrażające narzędzia AI w UE będą coraz częściej rozliczane nie tylko z efektów, ale też z higieny bezpieczeństwa.

Czy to problem jednego produktu, czy ostrzeżenie dla całego rynku agentów AI?

Sprawdzam. To problem szerszy niż sam DeepSeek Harness. Ten przypadek jest konkretny, ale dotyczy całej klasy narzędzi, które łączą modele, wtyczki, API i możliwość wykonywania akcji na systemie. Im więcej sprawczości dajesz agentowi, tym większe szkody może zrobić po przejęciu.

To nie jest argument przeciw open source. To argument przeciw naiwnym wdrożeniom. Open source daje szybkość i elastyczność, ale nie zwalnia z myślenia o ekspozycji usług, zaufaniu między komponentami i kontroli dostępu. Jeśli chcesz lepiej zrozumieć, czym różnią się takie systemy od zwykłych chatbotów, przeczytaj też wyjaśnienie różnicy między LAM a agentycznymi LLM.

Również sam DeepSeek jest dziś pod większą obserwacją rynku. Niedawno pisaliśmy o tym, że firma rozszerza działania poza sam software w artykule o ruchach DeepSeek poza klasyczny świat modeli. Gdy platforma szybko zdobywa popularność, każda luka waży więcej. Taki jest koszt skali.

Werdykt: to nie jest drobny błąd techniczny, ale przypomnienie, że agent AI z dostępem do narzędzi staje się elementem infrastruktury krytycznej. Jeśli wystawiasz panel zarządzania do internetu i liczysz, że „jakoś to będzie”, właśnie dostałeś bardzo kosztowną odpowiedź.

Najczęstsze pytania

Czy luka w DeepSeek Harness pozwala na atak bez logowania?

Tak. Według ujawnionych informacji podatność jest nieuwierzytelniona, więc atak nie wymaga poprawnego klucza API ani wcześniejszego zalogowania do systemu.

Która wersja DeepSeek Harness jest podatna?

Źródło wskazuje konkretnie wersję 0.1.1-rc.2. Artykuł odsyła też do oficjalnych komunikatów bezpieczeństwa DeepSeek w sprawie aktualizacji do poprawionej wersji.

Na czym polega problem z nagłówkiem Host?

Nagłówek HTTP Host mówi serwerowi, pod jaki adres trafia żądanie. Jeśli aplikacja źle go sprawdza, atakujący może sfałszować ten element i obejść część mechanizmów zaufania w API.

Czy są już potwierdzone ataki wykorzystujące tę lukę?

Na moment ujawnienia podatności nie potwierdzono wykorzystywania jej w realnych atakach. Nie ma też dowodów łączących tę lukę ze znanymi grupami zagrożeń.

Co firma może zrobić od razu, żeby zmniejszyć ryzyko?

Najkrótsza lista działań jest prosta: schować API zarządzające za sieć wewnętrzną, dopuścić tylko zaufane adresy IP i wymusić ścisłą walidację nagłówka Host na reverse proxy. Dodatkowo trzeba śledzić komunikaty DeepSeek i wdrożyć poprawioną wersję, gdy jest dostępna.