Miniony tydzień w świecie cyberbezpieczeństwa upłynął pod znakiem podatności PHP2Shell i nie mogło jej zabraknąć także w naszym Krajobrazie Zagrożeń. Podsumowanie opatrzyliśmy komentarzem, który pomoże odnaleźć się w szumie informacji panującym wokół tego tematu. Łatanie i analizowanie luki mogło utrudnić śledzenie pozostałych wiadomości, co skłoniło nas do przedstawienia najważniejszych informacji z zakresu ataków na łańcuch dostaw. A działo się wiele, kiedy akurat większość oczu była skierowana na inne problemy, zaatakowano m.in. OVHcli i (ponownie) LiteLLM. Przyjrzeliśmy się także wykorzystaniu techniki LLMjacking w atakach i konsekwencjom dla firm, których zasoby zostały w ten sposób nadużyte.

CVE Tygodnia

PHP2Shell. Krytyczne podatności w silniku PHP

• CVE-2026-109618 i CVE-2026-109619 w silniku PHP mogą umożliwić zdalne wykonanie kodu bez uwierzytelnienia. Obie podatności otrzymały ocenę 9,2 w CVSS v4.0. 
• Odnotowano już próby wykorzystania podatności. Firma watchTowr zaobserwowała taką aktywność 21 października 2026 r. w swojej globalnej sieci honeypotów Attacker Eye. O atakach na swoich klientów informowało również Cloudflare.
• Priorytetem jest aktualizacja PHP. Doraźne zmiany konfiguracji mogą ograniczyć niektóre ścieżki ataku, ale nie zastępują wdrożenia poprawek.

21 października 2026 r. zespół PHP opublikował aktualizacje usuwające dwie krytyczne podatności określane jako PHP2Shell. Błędy w obsłudze pamięci podczas przetwarzania żądań mogą umożliwić zdalnemu atakującemu wykonanie własnego kodu na serwerze bez wcześniejszego uwierzytelnienia. Zagrożenie dotyczy samego PHP, dlatego może obejmować również aplikacje, których kod nie zawiera podatności. 

CVE-2026-109618 dotyczy nieprawidłowej obsługi wyczerpania pamięci (out of memory, OOM). Przerwanie operacji może pozostawić częściowo zainicjalizowane struktury danych, które PHP następnie potraktuje jako prawidłowe podczas kończenia obsługi żądania. CVE-2026-109619 wiąże się natomiast z zachowaniem odwołań do pamięci zwolnionej po zakończeniu żądania. Gdy ten sam proces obsłuży kolejne żądanie, może ponownie użyć tej pamięci przed zresetowaniem swojego stanu. Powstaje wówczas błąd typu use-after-free, czyli użycia zwolnionej pamięci. Skutki nie ograniczają się do wykonania kodu. Wiz potwierdził również możliwość odczytu pamięci procesu PHP, która może zawierać hasła, tokeny uwierzytelniające czy klucze API. 

Zakres podatnych wydań sięga PHP 5.4. Badacze potwierdzili możliwość wykonania kodu bez uwierzytelnienia w środowiskach obsługujących m.in. WordPress, Joomla, Magento i phpMyAdmin. Skuteczność poszczególnych wariantów ataku zależy jednak od wersji PHP, konfiguracji i sposobu działania aplikacji. Zespół PHP ocenia ryzyko jako najwyższe dla Apache z modułem mod_php, gdzie potwierdzony atak może nastąpić przed wykonaniem kodu aplikacji. PHP-FPM również nie wyklucza zagrożenia — zweryfikowana w tym środowisku ścieżka RCE wymaga jednak odpowiedniej operacji po stronie aplikacji. Sama aktualizacja CMS-a lub jego wtyczek nie usuwa błędów w PHP. 

Skuteczne i powtarzalne wykorzystanie PHP2Shell wymaga jednak dostosowania exploita do konkretnego środowiska. Znaczenie mają m.in. sposób kompilacji PHP, zainstalowane rozszerzenia, konfiguracja serwera oraz układ pamięci procesu.  Publiczne PoC umożliwiają wykonanie kodu wyłącznie dla określonych kombinacji systemu operacyjnego, wersji PHP i serwera WWW. Żaden z nich nie zapewnia niezawodnego działania w różnych środowiskach. Ogranicza to możliwość wykorzystania tego samego kodu do atakowania wielu odmiennych instalacji i zmniejsza prawdopodobieństwo wykorzystania podatności na masową skalę. 

Próby wykorzystania luk pojawiły się jeszcze przed oficjalną publikacją szczegółów i poprawek. Cloudflare odnotował ataki wymierzone w swoich klientów, w tym modyfikowanie żądań w celu obejścia zabezpieczeń. watchTowr informuje z kolei o obserwacji wykorzystania podatności od 21 października w sieci honeypotów Attacker Eye. Oba doniesienia potwierdzają aktywność cyberprzestępców, nie pozwalają jednak określić liczby skutecznie przejętych systemów. Dodatkowo dostępne jest także publiczne repozytorium Is4yev/php2shell-poc, opisywane przez autora jako demonstracja awarii i szkielet exploita RCE. 

Poprawki opublikowane 21 października 2026 r. są dostępne w wydaniach PHP 8.2.35, 8.3.36, 8.4.27 i 8.5.12. W przypadku pakietów dystrybucyjnych należy sprawdzić komunikat dostawcy, który może udostępnić poprawkę również dla starszego wydania PHP jako backport. Do czasu aktualizacji część ścieżek ataku można ograniczyć, m.in. ustawiając session.upload_progress.enabled=0. Zmianę należy wprowadzić w konfiguracji obowiązującej przed parsowaniem żądań, np. w php.ini lub konfiguracji puli PHP-FPM, a następnie zrestartować wszystkie procesy robocze PHP. Wyłączenie tej funkcji blokuje potwierdzone warianty wykorzystania związane z obsługą sesji, ale nie zabezpiecza przed pozostałymi ścieżkami ataku.  

Równolegle warto przeanalizować dostępne logi, pamiętając, że logi samej aplikacji mogą zawierać niewiele informacji o przebiegu ataku. Wiz wskazuje jako sygnały wymagające sprawdzenia nietypowe żądania multipart, po których występują błędy przekroczenia limitu pamięci lub powtarzające się odpowiedzi HTTP 500. Uwagę powinny zwrócić również nieoczekiwanie duże bądź nieprawidłowe ciasteczka PHPSESSID w odpowiedziach serwera oraz niewyjaśnione restarty procesów roboczych PHP. Zdarzenia te należy oceniać w kontekście pozostałych obserwacji — pojedynczo nie potwierdzają skutecznego włamania.  

CVE-2026-115560 

23 października 2026 r.  PHP poinformował o kolejnej podatności, oznaczonej jako CVE-2026-115560. Problem dotyczy mechanizmu śledzenia postępu przesyłania plików i wymaga nietypowego połączenia konfiguracji z zachowaniem aplikacji. By atak się powiódł, funkcja session.upload_progress.enabled musi pozostawać włączona, a parametr session.serialize_handler musi mieć początkowo wartość php_binary lub php_serialize. Następnie aplikacja musi zmienić go na php za pomocą ini_set(), zanim wywoła session_start(). Aplikacje, które nie zmieniają tego ustawienia podczas działania, nie są narażone na ten konkretny problem.  

Zespół PHP ocenia wystąpienie takiej kombinacji jako mało prawdopodobne w praktyce, dlatego zapowiedział usunięcie luki w kolejnym regularnym wydaniu zamiast publikacji aktualizacji awaryjnej.

Patrząc szerzej

Wykorzystywanie podatności odgrywa coraz większą rolę w uzyskiwaniu początkowego dostępu do systemów. Według Verizon DBIR 2026 odpowiadało za 31% analizowanych naruszeń i po raz pierwszy wyprzedziło użycie skradzionych danych uwierzytelniających jako najczęstszy sposób rozpoczęcia ataku. PHP2Shell ma w tym kontekście szczególne znaczenie ze względu na umiejscowienie błędów w środowisku wykonawczym wykorzystywanym przez wiele różnych aplikacji. Można więc oczekiwać zainteresowania atakujących poszukujących podatnych usług niezależnie od branży czy rodzaju prowadzonej działalności. Nie oznacza to jednak jednakowej skuteczności ataków wobec wszystkich instalacji — możliwości wykorzystania luk nadal zależą od konfiguracji i sposobu działania aplikacji.  

Jak najszybsza aktualizacja PHP jest kluczowa, szczególnie że próby wykorzystania podatności zostały już zaobserwowane. Doraźne zmiany konfiguracji ograniczają tylko wybrane warianty ataku.

Więcej informacji:  
https://github.com/Is4yev/php2shell-poc 
https://watchtowr.com/intelligence/php-cve-2026-109618-faq/ 
https://www.php.net/archive/2026.php#2026-10-20-1 
https://www.wiz.io/blog/php2shell-php-rce 

Future

LLMjacking, czyli autonomia zasilana kradzieżą

• LLMjacking, czyli nieautoryzowane wykorzystanie cudzej infrastruktury lub kont dostępowych do modeli językowych, pozwala atakującym wykluczyć rosnące koszty operacji wspieranych AI i prowadzić dalsze działania z cudzego konta.
• Analiza Wiz prezentuje scenariusz, w którym za pomocą phishingu atakujący pozyskują poświadczenia do środowiska chmurowego GCP, a następnie wykorzystują dostęp do kradzieży zasobów obliczeniowych generujący wysokie koszty dla ofiary.
• Inną perspektywę zaprezentowali analitycy Symantec, którzy opisali działalność atakujących korzystających z autonomicznego ofensywnego agenta AI. W zapętleniu poszukiwał dostępnych endpointów LLM i wykorzystywał te zasoby do dalszych ataków.

Analizy incydentów opublikowane przez Wiz oraz Symantec wskazują na dwa uzupełniające się scenariusze: przejmowanie kont chmurowych w celu finansowania masowego przetwarzania przez modele AI oraz wykorzystywanie niezabezpieczonych endpointów LLM jako zaplecza dla zautomatyzowanych kampanii cyberataków. W obu przypadkach atakujący przenoszą koszty operacyjne na ofiarę, jednocześnie ograniczając jej widoczność w zakresie rzeczywistego wykorzystania zasobów i nielegalnych działań przeprowadzanych z jej wykorzystaniem.  

W kampaniach analizowanych przez Wiz wektorem wejścia był phishing wykorzystujący reklamy w wyszukiwarce Google, kierujące użytkowników do fałszywych stron logowania do Google Cloud Platform (GCP). Przechwycone poświadczenia oraz kody MFA umożliwiały uzyskanie dostępu do środowiska chmurowego. Następnie atakujący wykorzystywali wysokie uprawnienia przejętych kont do włączenia Gemini API, tworzenia kont usługowych i kluczy API oraz modyfikowania polityk kontroli dostępu. Dodawali również własne konta do infrastruktury rozliczeniowej i łączyli z nią projekty GCP pozostające pod ich kontrolą. W rezultacie zapytania do modeli były wykonywane w zewnętrznych projektach, natomiast koszty obciążały rachunek organizacji będącej ofiarą. W opisanych incydentach nieautoryzowane wydatki sięgały dziesiątek, a nawet setek tysięcy dolarów w ciągu 24–48 godzin od uzyskania początkowego dostępu.  

Przeniesienie obciążenia do projektów zewnętrznych utrudniało również analizę incydentu. Organizacja ponosiła koszty przetwarzania, ale jej wewnętrzne logi nie zapewniały wglądu w treść promptów, odpowiedzi modeli ani cel realizowanych zadań. Atakujący dodatkowo ograniczali możliwość reakcji przyznając zewnętrznym kontom wysokie uprawnienia i obniżając role dotychczasowych administratorów kontrolujących wątki rozliczeniowe. Choć celem LLMjacking ma być przede wszystkim skorzystanie z cudzego budżetu przez atakujących, to sposób dotarcia do tego punktu może prowadzić także do utraty kontroli nad tożsamością, mechanizmami zarządzania chmurą i danymi.  

Drugi kierunek rozwoju zagrożenia pokazuje opisana przez Symantec aktywność autonomicznego ofensywnego agenta i trybu określanego przez operatorów jako „Skynet mode”. Wykorzystywał on niezabezpieczone endpointy modeli, interfejsy zgodne z API OpenAI oraz skradzione klucze do uzyskania dostępu do mocy obliczeniowej. Model pełnił funkcję silnika planującego operacje, współpracującego z zestawem narzędzi do rozpoznania, wykorzystywania podatności i pozyskiwania danych. Instrukcje obejmowały skanowanie internetu, ataki na popularne frameworki i środowiska deweloperskie, odczyt plików konfiguracyjnych, kradzież poświadczeń, eksfiltrację baz danych oraz obsługę infrastruktury botnetowej. Operatorzy próbowali też omijać zabezpieczenia modeli komercyjnych za pomocą wielowarstwowych, fabularnych instrukcji typu jailbreak, prezentujących odczyt sekretów i pozyskiwanie kluczy jako zwykłe czynności programistyczne.  

Istotnym elementem tego scenariusza jest autonomia działania. Instrukcje agenta przewidywały nawet 100 tys. kroków wykonywanych bez bieżącej walidacji przez człowieka oraz powtarzalną pętlę wyszukiwania celów, infekowania systemów i ponawiania ataków. Zarejestrowane materiały wskazywały także na instalowanie koparek kryptowalut, ukrywanie plików, utrudnianie usunięcia złośliwego oprogramowania i kasowanie lokalnych logów. LLMjacking zapewniał zatem nie tylko dostęp do mocy obliczeniowej, lecz także możliwość zasilania kolejnych działań, których skutki obejmowały przejęcie danych, poświadczeń i zasobów kolejnych ofiar.

Patrząc szerzej

Oba scenariusze pokazują, że LLMjacking może skutkować zarówno stratami finansowymi, jak i kradzieżą danych oraz zakłóceniami w działalności operacyjnej. Warto też wspomnieć o potencjalnym ryzyku reputacyjnym jeżeli zasoby związane z naszą organizacją zostałyby dostrzeżone jako źródło w atakach na inne firmy.  

Zabezpieczenie się przed tego typu atakami wymaga uwierzytelniania wszystkich endpointów AI, ograniczania uprawnień kluczy API, monitorowania zmian w IAM i politykach organizacyjnych oraz wykrywania nietypowych skoków zużycia modeli. W przypadku agentów o większych możliwościach dostępowych i narzędziowych, konieczne jest również ograniczenie ruchu wychodzącego i kontrolowanie dostępu do systemów wewnętrznych. 

Więcej informacji:  
https://www.wiz.io/blog/from-phishing-to-llmjacking  
https://www.security.com/threat-intelligence/ai-llmjacking-skynet  

Łańcuch dostaw

Co mogło umknąć przez PHP2Shell? Od LiteLLM do eMudhra czyli tydzień w łańcuchu dostaw

• LiteLLM ponownie posłużył do dystrybucji złośliwego kodu, a w OVHcloud CLI podmieniono pliki przy istniejących wydaniach. W obu przypadkach zawartość oficjalnego repozytorium źródłowego nie odzwierciedlała zagrożenia dostarczanego użytkownikom.
• Microsoft przypisał atak na ConnectWise grupie Storm-0940. Atakujący wykorzystywali uprawnienia aplikacji w środowiskach klientów, a framework ARTEX wspomagał automatyzację ich działań. 
• Słabe klucze prywatne pośrednich urzędów certyfikacji eMudhra umożliwiały wystawianie nieuprawnionych certyfikatów. Konsekwencje błędu objęły również wycofywanie zaufania do jednego z certyfikatów głównych, mimo braku publicznego potwierdzenia wcześniejszych nadużyć.

Doniesienia o PHP2Shell mogły przesłonić pozostałe wydarzenia z ostatnich dni. Tymczasem złośliwy kod trafił do oficjalnych wydań narzędzi deweloperskich, pojawiły się nowe ustalenia dotyczące ataku na ConnectWise, a błąd w infrastrukturze eMudhra uruchomił szeroko zakrojoną akcję wycofywania zaufania do certyfikatów. Przegląd zaczyna się od projektu, który już wcześniej w tym roku znalazł się w podobnej sytuacji. 

Powtórka z LiteLLM 

Październikowe doniesienia o LiteLLM mogły wywołać déjà vu. 24 marca 2026 r. złośliwy kod trafił do wersji 1.82.7 i 1.82.8 publikowanych w PyPI. Po tamtym incydencie projekt przebudował proces wydawniczy. Siedem miesięcy później, 21 października, problem powrócił wraz z wersją 1.107.0. Tym razem zainfekowano zarówno pakiety wheel, czyli gotowe dystrybucje biblioteki, jak i oficjalne obrazy kontenerowe. LiteLLM, służący do obsługi wielu dostawców modeli językowych przez jeden interfejs, ponownie posłużył do dystrybucji złośliwego oprogramowania.  

Malware wykorzystywał mechanizmy startowe Pythona, w tym pliki .pth i sitecustomize.py. Do uruchomienia złośliwego kodu wystarczało uruchomienie interpretera w zainfekowanym środowisku, nawet bez importowania LiteLLM. Stealer zbierał m.in. klucze SSH, poświadczenia chmurowe, tokeny narzędzi AI oraz klucze API dostawców modeli przechowywane przez proxy. Drugi komponent umożliwiał pobieranie i wykonywanie kolejnego kodu. 

Zagrożenie obejmowało także obrazy kontenerowe oznaczone tagami wskazującymi na bieżące wydanie, takimi jak latest. Użytkownik mógł więc pobrać złośliwą wersję bez świadomego wybierania numeru 1.107.0. Jednocześnie kod oznaczony tagiem v1.107.0 w oficjalnym repozytorium nie zawierał złośliwych plików. Metadane obrazu kontenera wskazywały natomiast na użycie repozytorium Berri-AI/litellm, którego nazwa różniła się od prawidłowej, BerriAI/litellm, jedynie łącznikiem. 

OVHcloud i podmiana opublikowanych plików 

Podobna rozbieżność między kodem źródłowym a pobieranym oprogramowaniem wystąpiła w OVHcloud CLI. Tutaj atakujący podmienili pliki przy już opublikowanych wydaniach. Przejęte konto dewelopera na GitHub posłużyło 19 października do zastąpienia binariów wersji v0.11.0–v0.15.0 złośliwymi odpowiednikami. Kod źródłowy i proces budowania pozostały nienaruszone. Podmienione programy wykradały z dysku m.in. klucze SSH oraz dane uwierzytelniające do usług chmurowych i narzędzi infrastrukturalnych.  

Złośliwe pliki były dostępne przez około półtorej godziny. Jeszcze tego samego dnia OVHcloud opublikował czystą wersję v0.16.0 i zablokował możliwość modyfikowania opublikowanych wydań. O ekspozycji decydował moment pobrania pliku — wcześniejsze kopie tych samych wersji nie były objęte podmianą. OpenSourceMalware wskazali na możliwy związek ataku z GlassWorm. Konto GitHub HassenBF, wykorzystane 19 października do podmiany plików OVHcloud CLI, nosiło ślady wcześniejszego przejęcia. Już 5 i 6 marca 2026 r. do osobistych repozytoriów jego właściciela dodano złośliwy kod wykorzystujący portfel Solana znany z kampanii GlassWorm. Wykorzystanie tego samego konta w obu przypadkach nie wystarcza jednak do potwierdzenia, że za marcowymi zmianami i październikowym atakiem stały te same osoby. 

ConnectWise i uprawnienia prowadzące do klientów 

O ile w LiteLLM i OVHcloud celem były sekrety dostępne w środowisku uruchamiającym narzędzie, o tyle w ConnectWise kluczową rolę odegrał dostęp dostawcy do środowisk klientów. Firma wykryła problem 14 października, a 16 października ujawniła incydent dotyczący Cloud Backup, znanego wcześniej jako SkyKick. Nowością z 21 października była atrybucja Microsoftu, który przypisał operację Storm-0940, grupie powiązanej z Chinami. Atakujący wykorzystywali tożsamości aplikacji mających już uprawnienia w Microsoft 365 klientów. Pozwalało to uwierzytelniać się bez interaktywnego logowania użytkownika. Microsoft opisał próby dostępu do ponad 2250 tenantów, zastrzegając, że udane uwierzytelnienie samo w sobie nie potwierdza kradzieży danych.  

Storm-0940 korzystała przy tym z ARTEX, frameworka agentowego AI automatyzującego m.in. rozpoznanie, próby odgadnięcia haseł i nadużywanie aplikacji OAuth. Wiz opisał zbieżną aktywność wymierzoną również w innych dostawców IT i oprogramowania, obejmującą systemy tożsamości oraz integracje Microsoft 365. ARTEX pojawił się także w atakach na południowokoreańskie instytucje finansowe z końca września i początku października. W tym przypadku CrowdStrike wskazał jednak nieustalonego sprawcę. Publicznie potwierdzone powiązanie dotyczy więc wykorzystanego narzędzia, a wspólna atrybucja tych operacji pozostaje niepotwierdzona. 

eMudhra i błąd w infrastrukturze zaufania 

W ConnectWise atakujący nadużyli dostępu aplikacji do środowisk klientów. W eMudhra problem dotyczył innej relacji zaufania — tej, dzięki której oprogramowanie może potwierdzać tożsamość usług w sieci. 17 października zgłoszono słabość ośmiu kluczy prywatnych pośrednich urzędów certyfikacji, wygenerowanych 30 kwietnia 2025 r. Klucze P-384 miały wartości mniejsze niż 256, więc można było je odtworzyć praktycznie natychmiast. Według wstępnych ustaleń eMudhra błąd w procedurze generowania utworzył dodatkowy, słaby zestaw kluczy, omyłkowo wykorzystany do przygotowania certyfikatów. W przypadku pośrednich CA przeznaczonych do TLS umożliwiało to wystawianie nieuprawnionych certyfikatów i podszywanie się pod serwisy HTTPS.  

Mozilla, Google, Microsoft i Apple wdrożyły blokady zagrożonych certyfikatów. Dodatkowo podjęto decyzje o wycofaniu zaufania do emSign ECC Root CA – G3, co oznaczało konieczność migracji około 30 tys. certyfikatów. Ta szersza reakcja miała chronić także klientów, którzy nie otrzymują informacji o unieważnieniu konkretnych certyfikatów pośrednich. Nie ma publicznego potwierdzenia wykorzystania słabych kluczy przed ujawnieniem problemu. Brak takich śladów w rejestrach Certificate Transparency nie rozstrzyga jednak sytuacji aplikacji, które nie wymagają obecności certyfikatu w tych rejestrach.

Patrząc szerzej

Skutki ataku na łańcuch dostaw mogą utrzymywać się długo po wycofaniu złośliwego wydania lub zablokowaniu przejętej aplikacji. Wykradzione sekrety mogą posłużyć do kolejnych włamań, a zmiany wprowadzone w środowisku klienta pozwalają zachować dostęp niezależny od pierwotnej drogi wejścia. W przypadku ConnectWise obserwowano dodawanie nowych danych uwierzytelniających do innych aplikacji — wyłączenie aplikacji dostawcy nie usuwało tych zmian.  

Jak przy większości ostatnich tematów w Krajobrazie Zagrożeń, nie może zabraknąć wątku AI. AI występuje tu w dwóch rolach. Środowiska korzystające z modeli językowych są atrakcyjnym źródłem poświadczeń, natomiast narzędzia takie jak ARTEX pozwalają automatyzować kolejne etapy ataku. Opisane operacje wskazują, że wzrost tempa działań opiera się w dużej mierze na znanych technikach, wykonywanych równolegle i wielokrotnie. W połączeniu z uprawnieniami wcześniej nadanymi aplikacjom dostawcy daje to możliwość szybkiego rozszerzania operacji na następne organizacje, bez konieczności przejmowania kont użytkowników w każdej z nich.

Więcej informacji:
https://socket.dev/blog/litellm-compromise 
https://safedep.io/litellm-pypi-compromise-credential-stealer-backdoor/ 
https://www.microsoft.com/en-us/security/blog/2026/10/21/storm-0940-uses-artex-agentic-ai-connectwise-supply-chain-compromise/ 
https://bugzilla.mozilla.org/show_bug.cgi?id=2083449