zdalne wykonanie kodu (RCE)

Zdalne wykonanie kodu (RCE, remote code execution) to podatność, która pozwala atakującemu uruchomić własny kod na cudzym systemie bez wcześniejszego dostępu do tej maszyny. Może chodzić o serwer, na którym działa strona, albo o komputer użytkownika, który otworzył spreparowany plik w podatnej aplikacji ^[7]. RCE nie jest jedną słabością, tylko skutkiem: prowadzi do niego wiele różnych błędów. W katalogu CWE najbliższa mu jest słabość CWE-94, czyli wstrzyknięcie kodu, której skutkiem MITRE nazywa między innymi wykonanie dowolnego kodu ^[1].

Jak działa

Każda droga do RCE kończy się tym samym: dane od atakującego zostają potraktowane jak kod albo jak polecenie. MITRE opisuje CWE-94 jako sytuację, w której produkt buduje fragment kodu z danych pochodzących z zewnątrz i nie neutralizuje elementów, które mogą zmienić jego składnię lub działanie ^[1]. W PHP klasycznym przykładem jest konstrukcja eval(). Podręcznik PHP ostrzega, że jest bardzo niebezpieczna, bo pozwala wykonać dowolny kod PHP, odradza jej używanie i zaznacza, by nie przekazywać do niej danych od użytkownika bez uprzedniej walidacji ^[3].

Na serwerze WWW typowy przebieg ataku wygląda jak na schemacie poniżej.

RYS. 1RCE przez przesłanie pliku

Odmiany

Do zdalnego wykonania kodu prowadzą różne klasy błędów. Tabela zestawia najczęstsze w aplikacjach PHP.

Deserializacja zasługuje na osobną uwagę. Podręcznik PHP ostrzega, by nie przekazywać danych od użytkownika do unserialize() niezależnie od opcji allowed_classes, bo odtwarzanie obiektów może załadować i wykonać kod ^[4]. Zaleca zamiast tego format JSON ^[4]. W WordPressie ten mechanizm znany jest jako PHP object injection.

RCE bywa też skutkiem łańcucha błędów. Race condition w obsłudze pliku tymczasowego może dać atakującemu chwilę na uruchomienie skryptu, zanim aplikacja go usunie ^[6]; zob. race condition.

W WordPressie

W WordPressie większość luk prowadzących do RCE dotyczy wtyczek i motywów; zob. podatność we wtyczce. Najgroźniejsze są te, które atakujący wykorzysta bez logowania, czyli podatność wykorzystywana bez uwierzytelnienia. Częsty wzorzec to formularz albo punkt końcowy przyjmujący pliki bez sprawdzenia typu: przesłany skrypt PHP staje się webshellem.

RCE może też wynikać z przejęcia konta administratora. Dokumentacja WordPressa zwraca uwagę, że kokpit domyślnie pozwala administratorom edytować pliki PHP wtyczek i motywów, i że jest to często pierwsze narzędzie, po które sięga atakujący po zalogowaniu, bo pozwala wykonać kod ^[5]. Dlatego edytor plików motywów i wtyczek warto wyłączyć stałą w pliku wp-config.php ^[5].

// wp-config.php: wyłącza edytor plików w kokpicie
define( 'DISALLOW_FILE_EDIT', true );

Dokumentacja ostrzega też, że prawo zapisu do plików jest potencjalnie niebezpieczne, zwłaszcza na hostingu współdzielonym, i zaleca możliwie ścisłe uprawnienia plików ^[5].

Zagrożenia i skutki

RCE to zwykle najcięższy możliwy skutek podatności, bo kod atakującego działa z uprawnieniami aplikacji. MITRE wymienia wśród skutków wstrzyknięcia kodu obejście mechanizmów ochrony, przejęcie uprawnień lub tożsamości, wykonanie dowolnego kodu i ukrywanie działań przed logami ^[1]. Na przejętym serwerze WordPressa atakujący może:

• zostawić tylną furtkę (backdoor) i utworzyć nieautoryzowane konto administratora;
• odczytać wp-config.php, a z nim dane dostępowe do bazy;
• wstrzyknąć SEO spam albo złośliwe przekierowania;
• dołączyć serwer do botnetu albo uruchomić cryptojacking.

Jak się bronić

Podstawą jest usuwanie przyczyn. MITRE zaleca przebudowę kodu tak, by nie generował kodu dynamicznie, ścisłą walidację wejścia z listą dozwolonych wartości, uruchamianie kodu w izolowanym środowisku i testy dynamiczne ^[1]. W PHP oznacza to rezygnację z eval() ^[3] i z unserialize() na danych od użytkownika ^[4].

RYS. 2Warstwy obrony przed RCE

Na poziomie strony liczą się:

1. szybka łatka (patch) po publikacji informacji o luce; dokumentacja WordPressa zaleca aktualizację rdzenia, oprogramowania serwera i usuwanie nieużywanych wtyczek ^[5];
2. blokada wykonywania PHP w katalogu uploads;
3. zasada najmniejszych uprawnień dla użytkownika bazy, procesu serwera i kont w panelu;
4. WAF i wirtualne patchowanie (virtual patching) jako warstwa na czas przed wydaniem poprawki.

Historia i przykłady

W zestawieniu CWE Top 25 za 2024 rok wstrzyknięcie kodu (CWE-94) zajęło 11. miejsce, awansując o 12 pozycji z 23. miejsca rok wcześniej ^[2]. Dziesiąte miejsce zajęło nieograniczone przesyłanie plików niebezpiecznego typu (CWE-434), a siódme wstrzyknięcie poleceń systemu operacyjnego (CWE-78) ^[2].

CERT Polska 19 maja 2026 roku opisał CVE-2026-42099 w serwerze Pro Cloud Server firmy Sparx Systems: aplikacja zapisywała tymczasowo plik na dysku, a atakujący mógł drugim żądaniem uruchomić złośliwy plik PHP przed jego usunięciem, co prowadziło do zdalnego wykonania kodu ^[6].

RCE dotyczy też programów na komputerach użytkowników. Sekurak w lipcu 2026 roku opisał CVE-2026-14266, przepełnienie bufora na stosie w obsłudze archiwów xz w programie 7-Zip ^[7]. Skuteczne wykorzystanie może prowadzić do zdalnego wykonania kodu, a do ataku wystarczy, że ofiara otworzy spreparowane archiwum ^[7]. Sekurak zalecał natychmiastową aktualizację do wersji 26.02 ^[7].