Archiwa: Firewall - Strona 3 z 22

Interlock wykorzystuje lukę 0-day w Cisco FMC do przejęcia uprawnień root

Wprowadzenie do problemu / definicja

Aktywna kampania ransomware prowadzona przez grupę Interlock pokazuje, jak poważnym zagrożeniem pozostają podatności 0-day w systemach brzegowych oraz platformach zarządzania bezpieczeństwem. Tym razem celem stało się oprogramowanie Cisco Secure Firewall Management Center, gdzie krytyczna luka CVE-2026-20131 umożliwia zdalne wykonanie kodu bez uwierzytelnienia, a następnie pełne przejęcie urządzenia z uprawnieniami root.

To szczególnie niebezpieczny scenariusz, ponieważ kompromitacji ulega nie zwykły serwer aplikacyjny, lecz centralny komponent odpowiedzialny za zarządzanie politykami bezpieczeństwa, konfiguracją zapór i widocznością zdarzeń w środowisku organizacji.

W skrócie

Grupa Interlock wykorzystuje podatność CVE-2026-20131 w Cisco FMC jako wektor początkowego dostępu.
Luka wynika z niebezpiecznej deserializacji danych Java i pozwala na zdalne wykonanie kodu bez uwierzytelnienia.
Eksploatacja prowadzi do uzyskania uprawnień root na podatnym urządzeniu.
Atak był wykorzystywany jako 0-day jeszcze przed publicznym ujawnieniem podatności i publikacją poprawek.
Po przejęciu systemu operatorzy wdrażają narzędzia do rozpoznania, utrzymania dostępu, maskowania ruchu i przygotowania dalszych etapów ataku ransomware.

Kontekst / historia

Cisco opublikowało advisory dotyczące CVE-2026-20131 na początku marca 2026 roku, przypisując luce maksymalną ocenę krytyczności. Problem dotyczy interfejsu zarządzającego Cisco Secure Firewall Management Center i umożliwia wykonanie dowolnego kodu Java poprzez przesłanie odpowiednio spreparowanego obiektu serializowanego.

Najistotniejsze jest jednak to, że z ustaleń badaczy wynika wcześniejsze wykorzystanie tej podatności przez operatorów Interlock. Oznacza to, że organizacje mogły zostać zaatakowane jeszcze przed publicznym ujawnieniem problemu i przed udostępnieniem poprawki przez producenta.

Ataki na firewalle, VPN-y i konsole administracyjne wpisują się w szerszy trend obserwowany w operacjach ransomware. Zamiast zaczynać od stacji roboczych użytkowników, cyberprzestępcy coraz częściej próbują przejmować systemy o wysokich uprawnieniach i dużej widoczności w infrastrukturze, co przyspiesza rozpoznanie środowiska oraz dalszą eskalację działań.

Analiza techniczna

Źródłem podatności jest insecure deserialization, czyli przetwarzanie niezaufanego, serializowanego obiektu Java bez odpowiednich mechanizmów walidacji. W praktyce atakujący może dostarczyć spreparowane żądanie do podatnego komponentu aplikacji webowej FMC, co prowadzi do wykonania arbitralnego kodu na urządzeniu.

Zaobserwowany łańcuch ataku ma charakter wieloetapowy. Po skutecznej eksploatacji system nawiązuje połączenie z infrastrukturą kontrolowaną przez operatorów, co prawdopodobnie służy do potwierdzenia wykonania kodu i rozpoczęcia dalszych działań. Następnie pobierane są kolejne komponenty, w tym pliki binarne ELF oraz narzędzia wspierające rozpoznanie i utrzymanie dostępu.

Zidentyfikowany zestaw narzędzi wskazuje na dojrzałą operację. Wśród obserwowanych elementów znajdują się skrypty PowerShell służące do szerokiej inwentaryzacji środowisk Windows, niestandardowe trojany zdalnego dostępu napisane w Java i JavaScript, a także mechanizmy pozwalające na uruchamianie poleceń, transfer plików, aktualizację komponentów oraz usuwanie śladów.

Operatorzy wykorzystują również techniki utrudniające analizę i atrybucję. Należą do nich konfiguracja serwerów jako odwrotnych proxy HTTP, okresowe czyszczenie logów, wdrażanie komponentów pośredniczących w ruchu oraz użycie pamięciowych powłok webowych. Dodatkowo stosowane jest legalne oprogramowanie do zdalnego dostępu jako alternatywna metoda utrzymania obecności w środowisku po wykryciu części artefaktów.

Techniczna analiza kampanii jest o tyle cenna, że kompromitacja jednego z elementów infrastruktury operacyjnej grupy umożliwiła badaczom wgląd w narzędzia, skrypty i techniki używane przez Interlock. To pozwoliło powiązać aktywność z tą grupą na podstawie zarówno wskaźników technicznych, jak i charakterystycznych elementów operacyjnych.

Konsekwencje / ryzyko

Ryzyko związane z CVE-2026-20131 jest krytyczne z kilku powodów. Po pierwsze, luka nie wymaga uwierzytelnienia, co znacząco obniża próg wejścia dla napastnika. Po drugie, skuteczne wykorzystanie prowadzi bezpośrednio do wykonania kodu z uprawnieniami root, a więc do pełnej kompromitacji urządzenia. Po trzecie, atak dotyczy systemu centralnego z punktu widzenia zarządzania bezpieczeństwem.

Dla organizacji oznacza to możliwość utraty poufności, integralności i dostępności systemów. Przejęty FMC może zostać wykorzystany do mapowania środowiska, identyfikacji chronionych zasobów, manipulowania konfiguracją zabezpieczeń, wdrażania dodatkowych backdoorów oraz przygotowania końcowego etapu szyfrowania danych lub wymuszenia związanego z ich kradzieżą.

Szczególnie niepokojące jest wykorzystanie luki jako 0-day. Nawet organizacje posiadające sprawne procesy zarządzania poprawkami mogły pozostawać narażone przed publikacją aktualizacji. To pokazuje, że samo szybkie łatanie podatności nie wystarcza, jeśli środowisko nie jest odpowiednio segmentowane, monitorowane i przygotowane na wykrywanie nietypowych zachowań.

Rekomendacje

Organizacje korzystające z Cisco Secure Firewall Management Center powinny w pierwszej kolejności niezwłocznie wdrożyć poprawki udostępnione przez producenta i ustalić, które instancje były dostępne z sieci zewnętrznych lub z segmentów administracyjnych o szerokim zasięgu.

Równolegle należy przeprowadzić ocenę pod kątem możliwej kompromitacji. Obejmuje to przegląd logów HTTP i administracyjnych, analizę nietypowych żądań kierowanych do interfejsu webowego, identyfikację nieautoryzowanych połączeń wychodzących oraz kontrolę nowych plików binarnych, skryptów i narzędzi zdalnego dostępu.

Ograniczyć dostęp do interfejsów zarządzających wyłącznie do wydzielonych sieci administracyjnych.
Włączyć dodatkowe mechanizmy kontroli dostępu i segmentację systemów bezpieczeństwa.
Monitorować ruch wychodzący z urządzeń zarządzających.
Szukać oznak pobierania binariów ELF, nietypowych żądań HTTP PUT, czyszczenia logów i zadań cyklicznych.
Zweryfikować obecność nieautoryzowanego oprogramowania do zdalnej administracji, proxy i web shelli.

Z perspektywy strategicznej incydent potwierdza potrzebę stosowania podejścia defense-in-depth. Regularne aktualizacje, twardy hardening urządzeń, ograniczanie powierzchni ataku, telemetria EDR i NDR oraz ćwiczenia reagowania na incydenty powinny obejmować również scenariusze przejęcia platform zarządzających bezpieczeństwem.

Podsumowanie

Kampania Interlock przeciwko Cisco FMC pokazuje, że urządzenia i konsole bezpieczeństwa pozostają jednym z najbardziej atrakcyjnych celów dla operatorów ransomware. CVE-2026-20131 łączy najgroźniejsze cechy nowoczesnej podatności: brak wymogu uwierzytelnienia, zdalne wykonanie kodu, uprawnienia root oraz potwierdzone wykorzystanie w realnych atakach przed publicznym ujawnieniem.

Dla zespołów bezpieczeństwa najważniejsze wnioski są jasne: szybkie wdrożenie poprawek jest konieczne, ocena pod kątem wcześniejszej kompromitacji jest równie ważna jak samo łatane, a skuteczna ochrona przed 0-day wymaga wielowarstwowego podejścia. To właśnie zdolność wykrywania anomalii w systemach zarządzających może zdecydować, czy incydent zakończy się na etapie włamania, czy przerodzi się w pełnoskalowy atak ransomware.

Źródła

The Hacker News — https://thehackernews.com/2026/03/interlock-ransomware-exploits-cisco-fmc.html
Cisco Secure Firewall Management Center Software Remote Code Execution Vulnerability — https://www.cisco.com/content/en/us/support/docs/csa/cisco-sa-fmc-rce-NKhnULJh.html

20 Wskaźników I KPI Cyberbezpieczeństwa Do Śledzenia W 2026 r.

Co naprawdę mierzyć w cyberbezpieczeństwie?

W świecie cyberbezpieczeństwa liczby nie kłamią. Kluczowe Wskaźniki (KPI) pozwalają zmierzyć, jak skutecznie bronimy się przed atakami, zamiast zgadywać na podstawie przeczucia. W 2026 roku, przy coraz sprytniejszych atakach (np. wykorzystujących AI) i rosnącej presji regulacyjnej, mierzenie wyników staje się obowiązkowe. Jeśli nie da się czegoś zmierzyć, nie da się tym efektywnie zarządzać – ta stara zasada menedżerska dotyczy także bezpieczeństwa IT.

Czytaj dalej

Red Access wprowadza firewall-native SSE z ochroną GenAI i przeglądarek

Wprowadzenie do problemu / definicja

Security Service Edge (SSE) to model bezpieczeństwa dostarczanego z chmury, który koncentruje się na ochronie dostępu do aplikacji, usług webowych i danych niezależnie od lokalizacji użytkownika. W praktyce wiele organizacji nadal opiera swoje środowiska ochronne na klasycznych zaporach ogniowych, co utrudnia szybkie rozszerzenie kontroli na ruch SaaS, aktywność w przeglądarkach oraz wykorzystanie narzędzi generatywnej AI.

Na tym tle Red Access promuje podejście określane jako firewall-native SSE, czyli warstwę SSE dobudowaną do istniejącej architektury firewalli. Celem takiego modelu jest rozszerzenie ochrony bez konieczności kosztownej i ryzykownej wymiany już wdrożonej infrastruktury bezpieczeństwa.

W skrócie

Red Access zaprezentował rozwiązanie firewall-native SSE, które ma działać jako bezagentowa warstwa chmurowa rozszerzająca możliwości istniejących zapór ogniowych. Platforma ma zapewniać funkcje typowe dla SSE, a jednocześnie dodawać ochronę środowisk GenAI oraz zabezpieczenia przeglądarkowe.

brak konieczności pełnej wymiany dotychczasowych firewalli,
deklarowana kompatybilność z rozwiązaniami różnych dostawców,
ochrona ruchu webowego, SaaS i sesji użytkownika,
kontrola rozszerzeń przeglądarkowych, aplikacji desktopowych, komunikatorów i WebSocketów,
funkcje związane z DLP, CASB, SWG i ochroną przed phishingiem.

Kontekst / historia

Rynek cyberbezpieczeństwa od kilku lat przesuwa się w stronę architektur cloud-delivered security. Tradycyjna granica sieci coraz częściej ustępuje miejsca ochronie tożsamości, sesji użytkownika i aplikacji, zwłaszcza w środowiskach hybrydowych oraz organizacjach intensywnie korzystających z SaaS.

Jednocześnie przedsiębiorstwa mierzą się z nowymi wyzwaniami wynikającymi z wykorzystania generatywnej AI. Ryzyko obejmuje nie tylko wycieki danych do zewnętrznych modeli, ale także brak widoczności w zakresie promptów, odpowiedzi i interakcji użytkownika z usługami AI. Dla wielu firm problemem pozostaje jednak migracja do pełnego modelu SSE lub SASE, ponieważ posiadają rozbudowane inwestycje w istniejące zapory, polityki sieciowe i procesy operacyjne.

Analiza techniczna

Z technicznego punktu widzenia firewall-native SSE ma działać jako warstwa bezpieczeństwa osadzona nad aktualną infrastrukturą sieciową. Zamiast zastępować zapory ogniowe, rozwiązanie ma rozszerzać ich działanie o funkcje charakterystyczne dla nowoczesnych platform SSE.

Według deklaracji produkt obejmuje mechanizmy takie jak Data Loss Prevention, Cloud Access Security Broker, Secure Web Gateway, zaawansowaną ochronę przed phishingiem, kontrolę przeglądarki korporacyjnej oraz lokalną izolację przeglądarki. Istotnym elementem jest także warstwa ochrony dla usług GenAI, która ma odpowiadać na ryzyka związane z przesyłaniem poufnych danych do modeli językowych i korzystaniem z nieautoryzowanych narzędzi AI.

Ważną cechą platformy ma być bezagentowy model wdrożenia. Taki wariant może ograniczyć potrzebę instalowania dodatkowego oprogramowania na urządzeniach końcowych, co potencjalnie upraszcza wdrożenie i zmniejsza problemy kompatybilności. Jednocześnie skuteczność podejścia bez agenta zależy od sposobu przechwytywania ruchu, integracji z istniejącą infrastrukturą oraz poziomu widoczności na warstwie sesji.

Na uwagę zasługuje również deklarowany zakres ochrony. Oprócz klasycznego ruchu webowego i usług SaaS rozwiązanie ma obejmować także rozszerzenia przeglądarkowe, aplikacje desktopowe, komunikatory oraz połączenia WebSocket. To ważne, ponieważ współczesne zagrożenia coraz częściej wykorzystują aktywne sesje przeglądarkowe, kanały czasu rzeczywistego i integracje z usługami chmurowymi do obchodzenia tradycyjnych mechanizmów filtracji.

Konsekwencje / ryzyko

Dla organizacji rozwijających środowiska SaaS i AI tego typu rozwiązanie może pomóc zamknąć lukę między ochroną perymetryczną a potrzebą kontroli działań użytkownika na poziomie aplikacji i sesji. Jest to szczególnie istotne w kontekście wycieków danych do usług GenAI, nadużyć kont SaaS, phishingu opartego na przeglądarce oraz wykorzystywania dodatków i aplikacji pomocniczych do obchodzenia polityk bezpieczeństwa.

Nie oznacza to jednak braku ryzyk wdrożeniowych. Integracja z wieloma dostawcami firewalli, systemami tożsamości, politykami dostępu i procesami SOC może wymagać starannego planowania. W środowiskach regulowanych znaczenie będą miały również kwestie retencji logów, zgodności, lokalizacji danych i sposobu przetwarzania treści sesji użytkownika.

Kluczowe pytanie dotyczy też rzeczywistego poziomu widoczności w szyfrowanym ruchu, aplikacjach niestandardowych i kanałach czasu rzeczywistego. Jeśli deklarowana granularna kontrola sesji okaże się skuteczna w praktyce, firewall-native SSE może być atrakcyjną drogą do wdrożenia nowoczesnej ochrony bez pełnej przebudowy środowiska. Jeśli jednak zakres inspekcji będzie ograniczony, poprawa bezpieczeństwa może okazać się tylko częściowa.

Rekomendacje

Organizacje rozważające wdrożenie firewall-native SSE powinny rozpocząć od identyfikacji przepływów danych pomiędzy użytkownikami, aplikacjami SaaS, usługami AI i zasobami webowymi. Tylko wtedy możliwe jest prawidłowe dopasowanie polityk DLP, CASB oraz ochrony przeglądarkowej do realnych scenariuszy ryzyka.

przeprowadzić ocenę obecnej dojrzałości infrastruktury firewalli,
zidentyfikować nieobjęte kontrolą obszary, takie jak GenAI, rozszerzenia przeglądarkowe, komunikatory i WebSockety,
uruchomić pilotaż obejmujący scenariusze wycieku danych, blokowania nieautoryzowanych usług AI i wykrywania phishingu,
zintegrować nową warstwę z IAM, SIEM oraz procesami SOC,
zweryfikować wpływ rozwiązania na wydajność, prywatność i zgodność regulacyjną,
ocenić ograniczenia modelu bezagentowego pod kątem telemetrii i egzekwowania polityk na urządzeniach niezarządzanych.

Podsumowanie

Red Access pozycjonuje firewall-native SSE jako sposób na szybkie rozszerzenie istniejących zapór sieciowych o funkcje nowoczesnego SSE, ochronę przeglądarek i kontrolę ryzyk związanych z GenAI. Koncepcja wpisuje się w potrzeby organizacji, które chcą poprawić bezpieczeństwo sesji użytkownika i ruchu SaaS bez przeprowadzania pełnej wymiany infrastruktury.

Ostateczna wartość takiego rozwiązania będzie jednak zależała od praktycznej skuteczności integracji, poziomu widoczności w ruchu aplikacyjnym oraz zdolności do egzekwowania polityk w środowiskach hybrydowych i wielodostawczych.

Źródła

https://www.helpnetsecurity.com/2026/03/13/red-access-firewall-native-sse/

Ataki na FortiGate otwierają drogę do kradzieży konfiguracji i pełnej kompromitacji sieci

Wprowadzenie do problemu / definicja

Urządzenia FortiGate od lat stanowią kluczowy element ochrony sieci przedsiębiorstw, łącząc funkcje zapory nowej generacji, dostępu zdalnego, filtrowania ruchu oraz integracji z usługami katalogowymi. To właśnie ich uprzywilejowana pozycja sprawia, że skuteczne przejęcie takiego systemu może dać napastnikom nie tylko kontrolę nad ruchem sieciowym, ale również dostęp do danych konfiguracyjnych, kont usługowych i informacji o architekturze środowiska.

Najnowsze analizy incydentów pokazują, że FortiGate bywa wykorzystywany jako punkt wejścia do znacznie głębszej kompromitacji infrastruktury. Po uzyskaniu dostępu administracyjnego atakujący są w stanie eksportować konfigurację, zmieniać polityki bezpieczeństwa oraz wykorzystywać przechowywane w urządzeniu informacje do dalszego ruchu lateralnego.

W skrócie

Badacze reagowania na incydenty obserwują kampanie, w których FortiGate staje się pierwszym etapem ataku na organizację. Po przejęciu urządzenia intruzi eksportują pełną konfigurację, tworzą dodatkowe konta administratorów, modyfikują reguły firewalla i wykorzystują pozyskane poświadczenia do wejścia w głąb środowiska.

celem są dane o topologii sieci i kontach usługowych,
atakujący wykorzystują zarówno podatności, jak i słabe hasła,
po kompromitacji dochodzi do ruchu lateralnego i utrwalania dostępu,
w najpoważniejszych przypadkach próbują wykraść bazę NTDS.dit z kontrolera domeny.

Kontekst / historia

W tle analizowanych incydentów pojawiają się wcześniej ujawnione luki związane z mechanizmami uwierzytelniania i SSO w ekosystemie Fortinet. W szczególności wskazywano na błędy weryfikacji podpisu kryptograficznego, które mogły umożliwiać obejście uwierzytelnienia w określonych scenariuszach związanych z FortiCloud SSO. Równolegle eksperci podkreślają, że nie każdy incydent wymaga użycia zaawansowanego exploita — w wielu przypadkach wystarczają publicznie dostępne interfejsy administracyjne i słabe dane logowania.

Dodatkowym problemem pozostaje ograniczona retencja logów na urządzeniach brzegowych. Gdy organizacja przechowuje logi zbyt krótko, bardzo trudno ustalić dokładny moment przejęcia zapory, pierwotny wektor wejścia oraz pełną skalę działań napastnika. W praktyce często widoczny jest dopiero etap późniejszej aktywności w sieci wewnętrznej.

Analiza techniczna

Po uzyskaniu uprawnień administracyjnych na FortiGate napastnik może wyeksportować konfigurację urządzenia i przeanalizować ją pod kątem danych przydatnych operacyjnie. W konfiguracji mogą znajdować się informacje o segmentacji sieci, politykach dostępu, integracjach z LDAP lub Active Directory oraz zaszyfrowane poświadczenia kont usługowych.

W opisywanych przypadkach intruzi tworzyli lokalne konta administratorów na urządzeniach, a następnie modyfikowali reguły firewalla, aby ułatwić komunikację między segmentami lub utrzymać stały dostęp. Z pozyskanych danych konfiguracyjnych wyciągano informacje pozwalające na uwierzytelnienie w usługach katalogowych, co otwierało drogę do dalszej enumeracji i kompromitacji domeny.

W kolejnych etapach obserwowano dołączanie nieautoryzowanych stacji roboczych do domeny, użycie legalnych narzędzi zdalnego zarządzania, takich jak Pulseway i MeshAgent, a także wykorzystanie PowerShella, PsExec oraz technik uruchamiania złośliwego kodu przy użyciu DLL side-loading. Tego typu działania pozwalają napastnikom poruszać się po środowisku w sposób mniej oczywisty i zwiększają szansę na dłuższe utrzymanie obecności.

Najbardziej niebezpiecznym etapem była próba pozyskania danych z kontrolera domeny. Atakujący tworzyli kopie woluminów, wyodrębniali pliki NTDS.dit i SYSTEM, a następnie przygotowywali je do dalszej eksfiltracji. Taki zestaw umożliwia offline’ową analizę skrótów haseł i może prowadzić do długotrwałej kompromitacji tożsamości w organizacji.

Konsekwencje / ryzyko

Kompromitacja FortiGate nie ogranicza się do pojedynczego urządzenia sieciowego. W praktyce może oznaczać ujawnienie pełnej logiki ochrony środowiska, wewnętrznej adresacji, mapy połączeń oraz danych kont wykorzystywanych do integracji z systemami krytycznymi. To z kolei znacząco obniża koszt dalszego ataku i skraca czas potrzebny do zdobycia wysokich uprawnień.

przejęcie kont usługowych i kont administracyjnych,
tworzenie nieautoryzowanych kont lokalnych oraz domenowych,
zmiana polityk zapory w celu utrzymania dostępu,
wdrażanie narzędzi RMM jako mechanizmu persistence,
ruch lateralny do serwerów krytycznych,
eksfiltracja danych Active Directory,
utrata poufności i integralności całego środowiska.

Problem komplikuje także ograniczona widoczność telemetryczna. Urządzenia brzegowe zwykle nie są objęte klasycznym monitoringiem EDR, dlatego skuteczne wykrywanie nadużyć wymaga korelacji logów sieciowych, systemowych i danych z SIEM.

Rekomendacje

Organizacje korzystające z FortiGate powinny traktować te urządzenia jak zasoby krytyczne o wysokim poziomie uprzywilejowania. Oznacza to konieczność szybkiego wdrażania poprawek, regularnej weryfikacji ekspozycji interfejsów zarządzających oraz przeglądu funkcji, które nie są niezbędne biznesowo, w tym wybranych integracji SSO.

aktualizować FortiOS i komponenty powiązane do wersji wolnych od znanych luk,
stosować silne i unikalne hasła dla kont administracyjnych,
wymuszać MFA dla dostępu administracyjnego,
ograniczać interfejsy zarządzające do zaufanych adresów IP,
regularnie przeglądać lokalne konta administratorów na urządzeniu,
monitorować eksport konfiguracji i zmiany polityk firewalla,
wykrywać nietypowe logowania oraz użycie narzędzi RMM, PowerShell i PsExec,
wydłużyć retencję logów do co najmniej 60–90 dni i centralizować je w SIEM,
rotować poświadczenia kont usługowych po każdej podejrzanej aktywności,
ograniczyć uprawnienia kont integracyjnych i przejrzeć ustawienia MachineAccountQuota.

Podsumowanie

Incydenty związane z FortiGate pokazują, że urządzenia brzegowe pozostają jednym z najbardziej atrakcyjnych celów dla operatorów zagrożeń. Ich kompromitacja może szybko przełożyć się na dostęp do usług katalogowych, serwerów oraz kluczowych poświadczeń, a następnie na pełną penetrację środowiska.

Dla zespołów bezpieczeństwa oznacza to potrzebę zmiany podejścia: firewall nie jest wyłącznie narzędziem ochronnym, ale również zasobem wysokiego ryzyka, który sam wymaga ścisłego monitoringu, twardego hardeningu i rozbudowanej telemetrii. W obecnym krajobrazie zagrożeń ochrona urządzeń FortiGate powinna być traktowana jako jeden z priorytetów cyberbezpieczeństwa przedsiębiorstwa.

Źródła

Attackers exploit FortiGate devices to access sensitive network information — https://securityaffairs.com/189241/security/attackers-exploit-fortigate-devices-to-access-sensitive-network-information.html
FortiGate Edge Intrusions | Stolen Service Accounts Lead to Rogue Workstations and Deep AD Compromise — https://www.sentinelone.com/blog/fortigate-edge-intrusions/
Fortinet fixed two critical authentication-bypass vulnerabilities — https://securityaffairs.com/185546/security/fortinet-fixed-two-critical-authentication-bypass-vulnerabilities.html
CVE-2025-59718 — https://nvd.nist.gov/vuln/detail/CVE-2025-59718
CVE-2025-59719 — https://nvd.nist.gov/vuln/detail/CVE-2025-59719

FortiGate jako punkt wejścia do sieci: kradzież kont usługowych i kompromitacja Active Directory

Wprowadzenie do problemu / definicja

Urządzenia FortiGate od lat stanowią kluczowy element ochrony styku sieci wewnętrznej z internetem. Problem pojawia się jednak wtedy, gdy sama zapora staje się celem skutecznego ataku, ponieważ jej przejęcie może otworzyć napastnikom drogę nie tylko do zarządzania ruchem sieciowym, ale również do konfiguracji, danych uwierzytelniających oraz informacji o architekturze środowiska.

W analizowanych incydentach FortiGate nie było jedynie pojedynczym punktem naruszenia. Po uzyskaniu dostępu do urządzenia atakujący wykorzystywali je jako przyczółek do dalszej penetracji infrastruktury Windows, przejmowania kont usługowych oraz operacji wymierzonych w Active Directory.

W skrócie

Badacze opisali scenariusze, w których FortiGate był wykorzystywany jako wektor wejścia do sieci. Napastnicy uzyskiwali dostęp administracyjny przez podatności lub słabe dane logowania, a następnie eksportowali konfigurację urządzenia, odzyskiwali poświadczenia kont usługowych i pozyskiwali informacje o topologii środowiska.

tworzenie nowych kont administratora na FortiGate,
modyfikacja reguł firewall w celu ułatwienia ruchu bocznego,
dołączanie nieautoryzowanych stacji roboczych do domeny,
wdrażanie narzędzi zdalnego zarządzania,
próby pozyskania pliku NTDS.dit z kontrolerów domeny.

Kontekst / historia

Kampania została zaobserwowana na przełomie końca 2025 i początku 2026 roku. W tym okresie szczególne znaczenie miały luki CVE-2025-59718, CVE-2025-59719 oraz CVE-2026-24858, powiązane z mechanizmami FortiCloud SSO i błędami w procesie uwierzytelniania.

W praktyce problem nie ograniczał się do samego urządzenia brzegowego. FortiGate w wielu organizacjach współpracuje z LDAP i Active Directory, używając kont usługowych do mapowania użytkowników, grup i polityk dostępu. To sprawia, że kompromitacja zapory może stać się bezpośrednim pomostem do naruszenia tożsamości domenowych.

Analiza techniczna

W opisywanych przypadkach atakujący uzyskiwali dostęp administracyjny do FortiGate na dwa główne sposoby: poprzez aktywnie wykorzystywane podatności albo w wyniku błędnej konfiguracji i słabych haseł. Następnie eksportowali konfigurację FortiOS, która mogła zawierać zaszyfrowane poświadczenia kont usługowych wykorzystywanych do integracji z LDAP lub Active Directory.

Po wyeksportowaniu konfiguracji napastnicy odzyskiwali hasła i wykorzystywali je do logowania w środowisku domenowym. W jednym z incydentów zdobyte konto usługowe posłużyło do uwierzytelnienia w Active Directory i dołączenia dwóch nieautoryzowanych stacji roboczych do domeny. Taki ruch umożliwia obejście części mechanizmów kontroli dostępu i stanowi skuteczną bazę do dalszych działań.

Atak obejmował również utrwalenie dostępu na samym urządzeniu brzegowym. Tworzono lokalne konta administracyjne oraz dodawano nowe reguły firewall, które ułatwiały komunikację między segmentami sieci. W drugim przypadku napastnicy bardzo szybko przeszli do logowania na serwery z użyciem przejętych poświadczeń uprzywilejowanych, wdrożyli legalne narzędzia zdalnego zarządzania oraz uruchomili złośliwy ładunek z wykorzystaniem techniki DLL side-loading.

Końcowym celem była próba pozyskania pliku NTDS.dit i gałęzi SYSTEM z kontrolera domeny. Taki zestaw danych pozwala na dalsze łamanie skrótów haseł, eskalację uprawnień i rozszerzenie kompromitacji na całą organizację.

Istotnym problemem okazał się również ograniczony poziom widoczności. Krótka retencja logów na urządzeniach brzegowych utrudniała ustalenie dokładnego momentu wejścia, przebiegu ataku oraz rzeczywistej skali naruszenia.

Konsekwencje / ryzyko

Kompromitacja FortiGate wiąże się z wysokim ryzykiem operacyjnym. Urządzenie znajduje się na styku internetu i sieci wewnętrznej, a jednocześnie często posiada relacje z systemami tożsamości, co czyni je szczególnie wartościowym celem.

utrata poufności danych uwierzytelniających,
manipulacja politykami bezpieczeństwa i ruchem sieciowym,
możliwość nieautoryzowanego dołączania hostów do domeny,
szybki ruch boczny do serwerów i kontrolerów domeny,
utrwalenie dostępu przez konta lokalne i narzędzia RMM,
kradzież danych z Active Directory i pełna eskalacja uprawnień.

Dodatkowym zagrożeniem jest fakt, że urządzenia brzegowe nie zawsze są objęte równie rozbudowanym monitoringiem jak stacje końcowe i serwery. Ograniczona telemetria, brak EDR oraz niewystarczająca retencja logów wydłużają czas niewykrytej obecności napastnika.

Rekomendacje

Organizacje powinny traktować FortiGate jako system krytyczny nie tylko z perspektywy sieci, ale także bezpieczeństwa tożsamości i domeny. Samo aktualizowanie urządzenia nie wystarczy, jeśli równolegle nie zostaną zabezpieczone konta usługowe, interfejsy administracyjne i procesy monitorowania.

zweryfikować wersję FortiOS i niezwłocznie wdrożyć poprawki dla wskazanych podatności,
wyłączyć FortiCloud SSO tam, gdzie nie jest niezbędne,
ograniczyć dostęp administracyjny wyłącznie do zaufanych segmentów i zabezpieczyć go MFA,
przeprowadzić rotację haseł wszystkich kont usługowych powiązanych z LDAP i AD,
przejrzeć lokalne konta administratorów oraz historię zmian polityk firewall,
monitorować eksport konfiguracji i nietypowe logowania administracyjne,
zwiększyć retencję logów urządzeń NGFW do co najmniej kilkunastu dni, a najlepiej do 60–90 dni,
centralizować logi w systemie SIEM,
analizować zdarzenia domenowe związane z nowymi komputerami, nietypowymi logowaniami i zmianami w katalogu,
zweryfikować ustawienia umożliwiające dołączanie maszyn do domeny bez ścisłej kontroli.

W środowiskach, gdzie istnieje podejrzenie naruszenia, warto dodatkowo sprawdzić, czy nie doszło do eksportu konfiguracji z FortiGate, utworzenia nowych kont lokalnych, logowań z adresów powiązanych z VPN zapory do serwerów domenowych oraz instalacji narzędzi zdalnego zarządzania.

Podsumowanie

Opisane incydenty pokazują, że nowoczesna zapora sieciowa może stać się nie tylko narzędziem ochrony, ale również wyjątkowo skutecznym punktem wejścia do środowiska firmowego. Kompromitacja FortiGate może prowadzić do przejęcia kont usługowych, obejścia segmentacji, ruchu bocznego i pełnego naruszenia Active Directory.

Dla obrony kluczowe znaczenie mają szybkie łatanie podatności, ścisła kontrola dostępu administracyjnego, regularna rotacja poświadczeń oraz pełna widoczność telemetryczna z urządzeń brzegowych. Bez tych działań firewall może przestać pełnić funkcję bariery i sam stać się najgroźniejszym elementem łańcucha ataku.

Źródła

Złośliwe rozszerzenia „AI assistant” kradną historię rozmów z LLM: jak działa kampania i jak się bronić

Wprowadzenie do problemu / definicja luki

Rynek narzędzi „AI sidebar / AI assistant” w przeglądarce rośnie błyskawicznie, a wraz z nim rośnie pokusa nadużyć. Najnowsze ustalenia Microsoft Defender pokazują kampanię złośliwych rozszerzeń Chromium (Chrome/Edge), które podszywają się pod legalne asystenty AI i masowo zbierają treści rozmów z LLM oraz historię przeglądania. Kluczowe ryzyko nie polega tu na „efektownym exploicie”, tylko na tym, że użytkownicy sami instalują dodatek, często w środowisku firmowym, a potem wklejają do okna czatu wrażliwe dane (kod, procedury, koncepcje produktowe, dane klientów).

W skrócie

Microsoft opisuje kampanię z ~900 tys. instalacji oraz sygnały aktywności w ponad 20 tys. tenantów enterprise.
Rozszerzenia zbierały pełne URL-e (w tym wewnętrzne) oraz fragmenty rozmów z platform takich jak ChatGPT i DeepSeek.
Dane były cyklicznie wysyłane metodą HTTPS POST do domen m.in. deepaichats[.]com, chatsaigpt[.]com (oraz wskazywanych wildcardów).
W kampanii pojawiają się konkretne ID rozszerzeń wykorzystywane w huntingu i detekcji.

Kontekst / historia / powiązania

To nie jest odosobniony przypadek. Już pod koniec 2025 r. OX Security opisało niemal identyczny motyw: fałszywe rozszerzenia podszywające się pod legalny produkt (AITOPIA), które eksportowały rozmowy z ChatGPT/DeepSeek oraz listę odwiedzanych kart, a jedna z próbek miała nawet wyróżnienie w sklepie.

Równolegle w 2026 r. badacze (m.in. opisywani przez Malwarebytes) zwracali uwagę na inną klasę zagrożeń: rozszerzenia kradnące tokeny sesji ChatGPT, co umożliwia przejęcie konta i dostęp do historii/metadanych.

W tle rośnie jeszcze jedno zjawisko: „agentic” funkcje w przeglądarkach i asystentach webowych rozszerzają powierzchnię ataku (np. wątki o eskalacji uprawnień w komponentach asystenta i nadużyciach przez rozszerzenia).

Analiza techniczna / szczegóły

1. Łańcuch ataku (wg Microsoft)

Microsoft opisuje „klasyczny” łańcuch dla złośliwego rozszerzenia, gdzie największą rolę gra socjotechnika i architektura uprawnień Chromium:

Recon: wybór popularnej niszy „AI assistant”, analiza legalnych dodatków (np. AITOPIA) i skopiowanie brandingu oraz zachowań instalacyjnych.
Delivery: dystrybucja przez Chrome Web Store, z naturalnym „przenikaniem” także do Edge (obsługa dodatków Chrome).
Exploitation (w sensie operacyjnym): po instalacji dodatek wykorzystuje model uprawnień rozszerzeń i zaczyna zbierać dane bez kolejnych kliknięć.
C2/Exfil: okresowe wysyłki HTTPS POST na infrastrukturę atakujących (deepaichats[.]com, chatsaigpt[.]com itd.).

2. Co dokładnie było zbierane

Według Microsoft złośliwe rozszerzenie:

logowało niemal wszystkie odwiedzane URL-e (w tym zasoby intranetowe),
przechwytywało wycinki wiadomości czatu (prompty i odpowiedzi) z narzędzi LLM,
zapisywało dane lokalnie jako Base64-encoded JSON, a potem wysyłało je na zewnątrz,
dołączało m.in. kontekst nawigacji, nazwy modeli, oraz trwały UUID (identyfikator sesji/instalacji).

3. „Zgoda” jako mechanizm kamuflażu

Ciekawy element opisu Microsoft to mechanika „konsentu”: użytkownik mógł początkowo wyłączyć zbieranie danych, ale aktualizacje miały automatycznie przywracać telemetrię (re-enable), co w praktyce tworzyło trwały kanał wycieku przy minimalnej widoczności dla ofiary.

4. Twarde artefakty: domeny i identyfikatory

Microsoft podaje znane endpointy/domeny do monitoringu oraz ID rozszerzeń używane w przykładowych zapytaniach huntingowych:

Domeny/C2 do obserwacji: chatsaigpt.com, deepaichats.com, chataigpt.pro, chatgptsidebar.pro (oraz wildcards).
Przykładowe ID: fnmihdojmnkclgjpcoonokmkhjpjechg, inhcgfpbfdjbjogdfjbclgolkmhnooop.

Praktyczne konsekwencje / ryzyko

Dla organizacji to jest przede wszystkim problem DLP i tajemnicy przedsiębiorstwa:

Wycieki kodu i IP: prompty często zawierają fragmenty repo, logi, konfiguracje, architekturę.
Mapowanie środowiska: pełne URL-e (w tym wewnętrzne) ujawniają nazwy systemów, ścieżki aplikacji, czasem identyfikatory zasobów lub tenantów.
Ryzyko zgodności: jeśli w promptach/odpowiedziach lądują dane osobowe lub kontraktowe, organizacja może „nieświadomie” uruchomić incydent naruszenia.
Trwałość: rozszerzenie „żyje” tak długo, jak przeglądarka i profil użytkownika — bez klasycznych wskaźników infekcji endpointu.

Rekomendacje operacyjne / co zrobić teraz

1. Szybkie działania (0–24h)

Audyt rozszerzeń w przeglądarkach firmowych (Chrome/Edge) + identyfikacja dodatków AI/sidebar. Microsoft rekomenduje użycie funkcji oceny rozszerzeń w Defender VM.
Blokada ruchu do wskazanych domen (proxy/SWG/DNS/EDR Network Protection) i przegląd logów POST/HTTPS.
Weryfikacja instalacji po ID: polowanie po ExtensionId i ścieżkach katalogów profilu przeglądarki (Windows).
Komunikat do użytkowników: natychmiastowe usunięcie niezweryfikowanych „AI assistant” + krótkie zasady użycia LLM (czego nie wklejać do promptów).

2. Detekcja i hunting (praktycznie)

Microsoft publikuje gotowe przykłady zapytań (Microsoft Defender XDR), m.in.:

wykrywanie uruchomień przeglądarki z parametrami zawierającymi znane ID,
wykrywanie połączeń do domen kampanii,
enumeracja instalacji w tabeli DeviceTvmBrowserExtensions,
wykrywanie artefaktów na dysku w folderach profilu Chrome/Edge.

Jeśli nie korzystasz z Defender XDR, przełóż to 1:1 na:

reguły w SIEM (DNS/Proxy/Firewall) na domeny,
IOC w EDR dla ścieżek katalogów rozszerzeń,
polityki Browser Management (allowlist/denylist rozszerzeń).

3. Kontrole długoterminowe (policy + technologia)

Allowlist rozszerzeń (preferowane) zamiast „każdy może instalować wszystko”.
Microsoft Defender SmartScreen + Network Protection (Microsoft wskazuje je jako warstwę blokowania).
Purview / kontrola przepływu danych dla aplikacji GenAI: w praktyce chodzi o to, by prompt i odpowiedź były traktowane jak kanał danych (klasyfikacja, DLP, zasady).
Zasady użycia AI: minimalny standard to „prompt hygiene”, etykietowanie danych, zakaz wklejania sekretów i fragmentów kluczy/tokenów.

Różnice / porównania z innymi przypadkami

Warto rozróżnić dwa popularne modele ataku na „AI w przeglądarce”:

Telemetria/Podsłuch (ten przypadek)

celem jest ciągłe zbieranie: URL-e + treści czatów, często „po cichu”, długoterminowo, z UUID.

Kradzież tokenów sesji / przejęcie konta

rozszerzenie kradnie token uwierzytelnienia (np. do ChatGPT), co daje możliwość przejęcia tożsamości i wglądu w historię konta. Takie kampanie opisywano m.in. w kontekście zestawu złośliwych dodatków dla Chrome/Edge.

Oba scenariusze kończą się podobnie (wyciek treści), ale różnią się tym, gdzie powstaje szkoda: lokalnie w przeglądarce (podsłuch) vs „po stronie usługi/konta” (token).

Podsumowanie / kluczowe wnioski

„AI assistant” w formie rozszerzenia to dziś jeden z najłatwiejszych kanałów wycieku danych: wystarczy instalacja i szerokie uprawnienia.
Skala jest realna: Microsoft mówi o ~900 tys. instalacji i aktywności w >20 tys. tenantów, co wskazuje na istotny wymiar enterprise.
Najlepsza obrona to połączenie allowlisty rozszerzeń, monitoringu domen/C2, i zasad użycia LLM (prompt hygiene + DLP).

Źródła / bibliografia

Microsoft Security Blog (Microsoft Defender Security Research Team) – „Malicious AI Assistant Extensions Harvest LLM Chat Histories” (05.03.2026). (Microsoft)
OX Security – „900K Users Compromised: Chrome Extensions Steal ChatGPT and DeepSeek Conversations” (30.12.2025). (OX Security)
Malwarebytes – „Malicious Chrome extensions can spy on your ChatGPT chats” (28.01.2026). (Malwarebytes)
TechRadar (na podstawie LayerX/BleepingComputer) – kampanie fałszywych rozszerzeń GenAI i masowe eksfiltracje treści (luty 2026). (TechRadar)
ITPro – przykład ryzyk związanych z asystentami w przeglądarce i nadużyciami przez rozszerzenia (CVE-2026-0628 / Gemini Live). (IT Pro)

CVE-2026-2256: luka w MS-Agent (ModelScope) pozwala na wykonanie poleceń systemowych i potencjalne pełne przejęcie hosta

Wprowadzenie do problemu / definicja luki

MS-Agent to otwartoźródłowy framework ModelScope do budowy agentów AI, które nie tylko generują tekst/kod, ale też wykonują akcje przez narzędzia (tools) – m.in. integracje, wyszukiwanie czy operacje na systemie.

Właśnie ta „sprawczość” (agency) jest sednem problemu: podatność CVE-2026-2256 dotyczy mechanizmu wykonywania poleceń przez tzw. Shell tool. Błąd w sanitizacji i walidacji wejścia może doprowadzić do command injection, czyli wymuszenia wykonania niezamierzonych poleceń systemowych w kontekście procesu agenta.

W skrócie

Identyfikator: CVE-2026-2256
Klasa błędu: command injection (w praktyce: prompt-derived input → polecenie shell)
Dotknięte wersje: wg rekordu CVE – ms-agent v1.6.0rc1 i wcześniejsze
Scenariusz ataku: złośliwa treść w danych, które agent konsumuje (prompt/dokument/log/research input), może skłonić agenta do użycia Shell tool i „przemycić” payload omijający filtr bezpieczeństwa
Status koordynacji/patcha: CERT/CC wskazuje, że nie uzyskano patcha ani stanowiska vendora w trakcie koordynacji (stan na publikację noty)
CVSS (wg wzbogacenia w rekordzie CVE): 6.5 (Medium)
- Uwaga praktyczna: realny wpływ bywa większy, jeśli agent działa z szerokimi uprawnieniami lub ma dostęp do sekretów/sieci wewnętrznej (typowe w środowiskach dev/ops).

Kontekst / historia / powiązania

W ostatnich 12–18 miesiącach rośnie liczba incydentów i badań pokazujących, że prompt injection w agentach to nie „zabawny jailbreak”, tylko wektor na system. Różnica jest fundamentalna:

Chatbot bez narzędzi co najwyżej „powie coś złego”.
Agent z narzędziami może coś zrobić: wykonać polecenie, pobrać plik, wysłać dane, zmienić konfigurację.

Dobrym punktem odniesienia jest klasa ataków indirect prompt injection (pośrednie wstrzyknięcie instrukcji do treści typu PDF/HTML), gdzie model nie odróżnia poleceń użytkownika od „instrukcji” zaszytych w oglądanych materiałach. HiddenLayer pokazał to na przykładzie frameworka „Computer Use” (agent sterujący środowiskiem i shellem), gdzie odpowiednio spreparowana treść potrafi doprowadzić do destrukcyjnych akcji w systemie.

CVE-2026-2256 wpisuje się w ten sam nurt: atakujący kontroluje treść → agent interpretuje ją jako część planu działania → narzędzie wykonuje komendy.

Analiza techniczna / szczegóły luki

Gdzie jest błąd?

Z noty CERT/CC wynika, że Shell tool w MS-Agent opiera się na metodzie check_safe() z regexową denylistą (blacklistą) mającą blokować „niebezpieczne” komendy. Taki wzorzec obrony jest kruchy: da się go obchodzić przez warianty składni powłoki, łączenie poleceń, encodowanie/obfuskację czy inne semantyki parsowania przez shell.

SecurityWeek podkreśla, że mimo wielu warstw walidacji, sposób w jaki powłoka interpretuje końcowy łańcuch poleceń może spowodować ominięcie filtrów i wykonanie logiki sterowanej przez atakującego.

Jak wygląda typowy łańcuch ataku (high-level)?

Agent pobiera/analizuje treść z zewnątrz (np. dokument, logi, wyniki researchu).
W treści zaszyte są instrukcje lub fragmenty tekstu, które model „wplata” w generowane polecenie.
Model decyduje się użyć Shell tool (bo „to najszybszy sposób”).
check_safe() przepuszcza payload (obejście denylisty/regex).
Shell wykonuje polecenie na hoście z uprawnieniami procesu agenta.

Dlaczego to jest szczególnie groźne w praktyce?

Bo agenty często działają:

w środowiskach developerskich/CI z dostępem do repozytoriów i tokenów,
na maszynach analitycznych z danymi,
z możliwością wykonywania narzędzi sieciowych (curl/wget/git),
czasem w kontekście kont uprzywilejowanych „bo wygodniej”.

W takim układzie command injection z poziomu narzędzia jest blisko klasycznego RCE „z premią”: agent sam pomaga atakującemu dobrać kroki i narzędzia.

Praktyczne konsekwencje / ryzyko

SecurityWeek opisuje możliwe skutki jako pełne przejęcie hosta w zależności od uprawnień procesu: odczyt sekretów (API keys/tokens/configi), modyfikacja plików roboczych, zrzut danych, drop payloadu, persystencja i pivot do usług wewnętrznych lub systemów sąsiednich.

CERT/CC dodaje, że podatność może ujawnić się także w „niewinnych” workflowach (np. podsumowanie dokumentu), jeśli agent wchodzi w interakcję z atakującym kontrolowaną treścią.

Rekomendacje operacyjne / co zrobić teraz

Jeśli używasz MS-Agent lub podobnych frameworków agentowych z narzędziami wykonawczymi, potraktuj to jako checklistę „hardeningu”:

Wyłącz Shell tool tam, gdzie nie jest absolutnie konieczny.
Najskuteczniejsza kontrola to redukcja powierzchni ataku.
Izoluj wykonanie narzędzi (sandbox/containery/VM):
Uruchamiaj agenta i szczególnie narzędzia OS w odseparowanym środowisku (oddzielny kontener/VM, ograniczone mounty, brak dostępu do hosta).
Least privilege + osobne tożsamości:
- osobny użytkownik systemowy bez uprawnień admin,
- brak dostępu do katalogów domyślnie wrażliwych,
- minimalne uprawnienia do sieci (egress filtering).
Zastąp denylisty allowlistą (jeśli shell musi zostać):
Zamiast „blokować złe”, dopuszczaj tylko konkretne, parametryzowane komendy (np. wywołania jednego wrappera z bezpiecznymi argumentami). CERT/CC wprost wskazuje, że denylist/regex jest niewystarczający.
Twarde granice danych wejściowych:
- traktuj dokumenty/logi/research input jako niezaufane,
- sanitizuj/normalizuj treść zanim trafi do kontekstu modelu,
- rozważ „content firewall”/detektory prompt injection.
Human-in-the-loop dla akcji wysokiego ryzyka:
- wymagaj jawnej akceptacji operatora przed wykonaniem komend,
- loguj i podpisuj (tamper-evident) plan i wykonane kroki.
Sekrety poza zasięgiem procesu:
- krótkotrwałe tokeny,
- brak plików z kluczami w workspace,
- ograniczenia IAM (scoping), rotacja.

W notach o CVE podkreśla się też prostą zasadę: uruchamiaj MS-Agent tylko tam, gdzie treści, które agent „połyka”, są zaufane/zweryfikowane – dopóki nie ma jednoznacznego patcha lub twardych mechanizmów izolacji.

Różnice / porównania z innymi przypadkami

CVE-2026-2256 vs „indirect prompt injection”

Indirect prompt injection: złośliwa instrukcja ukryta w dokumencie/stronie wpływa na zachowanie agenta.
CVE-2026-2256: dodatkowo dochodzi warstwa techniczna – filtr/denylista w Shell tool jest obchodzona, więc agent może wykonać polecenie nawet wtedy, gdy teoretycznie miał je odrzucić.

„Confused deputy” w praktyce

HiddenLayer opisuje ryzyko „confused deputy”: model działa z uprawnieniami użytkownika/systemu, ale daje się sterować obcą treścią.
W MS-Agent ten wzorzec jest szczególnie niebezpieczny, bo narzędzie shell jest z definicji „mostem” do systemu operacyjnego.

Podsumowanie / kluczowe wnioski

CVE-2026-2256 to prompt-derived command injection w ekosystemie agentów: złośliwa treść może doprowadzić do wykonania komend systemowych przez Shell tool.
Problem pogłębia fakt, że kontrola bezpieczeństwa bazuje na regexowej denyliście, którą da się obejść.
Nawet jeśli formalny scoring w rekordzie CVE wygląda „umiarkowanie”, realny wpływ zależy od tego, jak szerokie uprawnienia i jakie sekrety ma proces agenta.
Najrozsądniejsze działania „na dziś”: izolacja, least privilege, wyłączenie shell gdzie się da, allowlisty, kontrola egress i HITL.

Źródła / bibliografia

SecurityWeek – opis podatności, scenariusze wpływu i rekomendacje ogólne (SecurityWeek)
CERT/CC VU#431821 – nota koordynacyjna, mechanika obejścia denylisty/regex, status patcha (kb.cert.org)
OpenCVE (rekord CVE-2026-2256) – zakres wersji, metryki, referencje (app.opencve.io)
GitHub Advisory Database (GHSA-4gc2-344q-r2rw) – agregacja informacji o CVE w ekosystemie OSS (GitHub)
HiddenLayer – indirect prompt injection i „confused deputy” w agentach sterujących środowiskiem (hiddenlayer.com)