wstrzyknięcie poleceń (command injection)

Wstrzyknięcie poleceń (command injection) to podatność, w której aplikacja buduje polecenie systemu operacyjnego z danych pochodzących z zewnątrz i nie neutralizuje w nich znaków specjalnych ^[1]. Atakujący dopisuje wtedy do polecenia własne komendy, które serwer wykonuje. OWASP opisuje cel takiego ataku jako wykonanie dowolnych poleceń w systemie operacyjnym hosta za pośrednictwem podatnej aplikacji ^[2]. W katalogu CWE odpowiada mu słabość CWE-78, która w zestawieniu CWE Top 25 za 2025 rok zajęła 9. miejsce ^[4].

Jak działa

Aplikacja wywołuje program systemowy, na przykład narzędzie do konwersji plików albo kopii bazy, i skleja jego argumenty z tekstu od użytkownika. Powłoka traktuje część znaków jako składnię: średnik i pionowa kreska rozdzielają polecenia. MITRE opisuje, że atakujący wstrzykuje takie separatory do argumentu i w ten sposób uruchamia dodatkowe komendy ^[1]. Przyczyną jest według OWASP niewystarczająca walidacja danych wejściowych ^[2].

Różnicę widać na przykładzie w PHP. Pierwsza linia wkleja parametr do polecenia wprost, druga opakowuje go funkcją escapeshellarg().

system( 'ping -c 1 ' . $_GET['host'] );                  // podatne
system( 'ping -c 1 ' . escapeshellarg( $_GET['host'] ) ); // argument w cudzysłowie

Parametr host=example.com; id w pierwszym wariancie uruchamia dwa polecenia. Przebieg ataku pokazuje schemat poniżej.

RYS. 1Wstrzyknięcie polecenia przez parametr

Wstrzyknięcie poleceń trzeba odróżnić od wstrzyknięcia kodu. OWASP podkreśla, że przy wstrzyknięciu kodu atakujący dodaje własny kod programu, a przy wstrzyknięciu poleceń rozszerza domyślne działanie aplikacji, która i tak wykonuje polecenia systemowe, bez potrzeby wstrzykiwania kodu ^[2].

Odmiany

MITRE wyróżnia dwa warianty tej słabości ^[1]. Ściąga OWASP dodaje trzeci, pokrewny przypadek ^[3].

W zestawieniu CWE Top 25 osobno liczona jest ogólniejsza słabość CWE-77, wstrzyknięcie polecenia w dowolnym interpreterze; w 2025 roku zajęła 23. miejsce ^[4]. Pokrewną klasą jest SQL injection, w której interpreterem jest baza danych, a nie powłoka.

W WordPressie

W WordPressie to ryzyko dotyczy przede wszystkim podatności we wtyczkach, które wywołują zewnętrzne programy: narzędzia kopii zapasowych, konwertery obrazów, generatory PDF. PHP udostępnia do tego funkcje exec(), system() i operator odwróconego apostrofu, a dokumentacja zaleca, by każdy argument od użytkownika przepuszczać przez escapeshellarg() ^[5].

Przykładem jest wtyczka WP Database Backup. WPScan opisał w kwietniu 2019 roku podatność „Unauthenticated OS Command Injection” we wszystkich wersjach przed 5.2 ^[7]. Według opisu zgłoszenia błąd we wtyczce do tworzenia kopii zapasowej pozwalał wykonywać polecenia systemowe bez uwierzytelnienia; zob. podatność wykorzystywana bez uwierzytelnienia. Naprawę przyniosła wersja 5.2 ^[7].

Administrator może ograniczyć funkcje wywołujące powłokę dyrektywą disable_functions w php.ini. Działa ona tylko na funkcje wbudowane i musi być ustawiona w php.ini, a nie w httpd.conf ^[6]. Dokumentacja PHP ostrzega, że tę dyrektywę da się obejść i nie należy jej traktować jako wystarczającego zabezpieczenia na hostingu współdzielonym ^[6].

Zagrożenia i skutki

MITRE wymienia jako skutki wykonanie nieautoryzowanych poleceń, odczyt i modyfikację plików, odmowę usługi oraz ukrywanie działań atakującego, które wyglądają wtedy jak czynności samej aplikacji ^[1]. OWASP zwraca uwagę, że wstrzyknięte polecenia działają zwykle z uprawnieniami podatnej aplikacji ^[2]. Im szersze uprawnienia procesu, tym większa szkoda; MITRE zaznacza, że waga błędu rośnie w procesach uprzywilejowanych ^[1].

• Zdalne wykonanie kodu na serwerze, często pierwszy krok do pełnego przejęcia strony.
• Zapis webshella, który zostaje na serwerze po usunięciu pierwotnej luki.
• Odczyt pliku wp-config.php z danymi dostępu do bazy.
• Eskalacja uprawnień, gdy proces działa z konta uprzywilejowanego.

Jak się bronić

Ściąga OWASP ustawia obronę warstwowo ^[3]. Kolejność kroków pokazuje schemat poniżej.

RYS. 2Warstwy obrony przed wstrzyknięciem poleceń

Pierwsza zasada to unikanie wywołań systemowych: zamiast polecenia mkdir w powłoce lepiej użyć wbudowanej funkcji mkdir() ^[3]. Gdy wywołanie jest konieczne, OWASP zaleca oddzielenie danych od polecenia oraz walidację zarówno polecenia, jak i argumentów według listy dozwolonych wartości ^[3]. To odmiana sanityzacji danych wejściowych i escapowania dopasowanego do kontekstu.

Ściąga porównuje dwie funkcje PHP: escapeshellarg() traktuje dane jako jeden parametr, a escapeshellcmd() blokuje łączenie poleceń, ale dopuszcza wiele parametrów, więc chroni słabiej ^[3]. Sama escapeshellarg() nie chroni przed wstrzyknięciem argumentu, czyli wartością zaczynającą się od myślnika; dokumentacja PHP radzi wtedy użyć separatora -- ^[5]. MITRE dodaje uruchamianie kodu z minimalnymi uprawnieniami, piaskownicę i zapory aplikacyjne ^[1], czyli zasada najmniejszych uprawnień i WAF.

Historia i przykłady

MITRE ocenia prawdopodobieństwo wykorzystania tej słabości jako wysokie ^[1]. W zestawieniu CWE Top 25 za 2025 rok CWE-78 spadła o dwie pozycje względem roku poprzedniego ^[4].

CERT Polska 10 lipca 2026 roku opublikował informację o podatnościach w systemie R-SOFT DMS. CVE-2026-41876 to OS Command Injection w konwerterze dokumentów, który wykonuje polecenia powłoki z niezabezpieczonymi ścieżkami plików; uwierzytelniony atakujący może wykonać dowolne polecenia systemowe ^[8]. Ta sama publikacja opisuje CVE-2026-41880, wstrzyknięcie poleceń w module OCR, pozwalające wykonywać komendy z uprawnieniami roota ^[8]. Wersje v3.19-2752 i v3.17-2580 usuwają pierwszą z tych luk ^[8]; każda z nich ma własny identyfikator CVE, a naprawą jest łatka (patch) producenta.