{"id":22778,"date":"2026-10-22T10:17:00","date_gmt":"2026-10-22T08:17:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=22778"},"modified":"2026-10-22T10:53:36","modified_gmt":"2026-10-22T08:53:36","slug":"php2shell-ochrona-aktualizacje-zagrozone-witryny","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/pl\/tworzenie-stron-internetowych\/php2shell-ochrona-aktualizacje-zagrozone-witryny\/","title":{"rendered":"PHP2Shell: skuteczna ochrona i problem witryn bez aktualizacji"},"content":{"rendered":"

Stan na 22 pa\u017adziernika 2026 r.<\/strong> PHP2Shell dotyczy \u015brodowiska wykonawczego stanowi\u0105cego podstaw\u0119 du\u017cej cz\u0119\u015bci internetu. Dwie krytyczne podatno\u015bci w odpowiednich warunkach umo\u017cliwiaj\u0105 zdalne wykonanie kodu bez uwierzytelnienia. Aktualizacje bezpiecze\u0144stwa s\u0105 dost\u0119pne od 21 pa\u017adziernika. Najwa\u017cniejsze pytanie dotyczy obecnie rzeczywistego stanu publicznie dost\u0119pnych instalacji. [1]<\/a> [6]<\/a><\/p>

Nowe informacje: pr\u00f3by ataku przed publikacj\u0105<\/h2>

AWS informuje o pr\u00f3bie wykorzystania PHP2Shell z 17 pa\u017adziernika 2026 r., wykrytej we w\u0142asnej telemetrii MadPot jeszcze przed publicznym ujawnieniem podatno\u015bci. W przypadku kolejnych obserwowanych pr\u00f3b skuteczno\u015b\u0107 wobec rzeczywistych system\u00f3w pozostawa\u0142a niepewna. To udokumentowany sygna\u0142 ostrzegawczy, a nie globalna liczba przej\u0119tych system\u00f3w. Analiza potencjalnie dotkni\u0119tych instalacji powinna zatem obejmowa\u0107 tak\u017ce okres sprzed publikacji. AWS: w\u0142asne obserwacje i ograniczenia<\/a><\/p>\n

Co kryje si\u0119 pod nazw\u0105 PHP2Shell?<\/h2>\n

Identyfikatory podatno\u015bci to CVE-2026-109618<\/strong> oraz CVE-2026-109619<\/strong>. Pierwszy b\u0142\u0105d dotyczy nieprawid\u0142owego stanu pami\u0119ci po wyst\u0105pieniu jej niedoboru. Drugi wynika z pozostawienia wewn\u0119trznych odwo\u0142a\u0144 do ju\u017c zwolnionej pami\u0119ci. Dalsze przetwarzanie takich stan\u00f3w mo\u017ce prowadzi\u0107 do naruszenia bezpiecze\u0144stwa. Oba problemy wyst\u0119puj\u0105 w samym PHP. [3]<\/a> [4]<\/a><\/p>\n

Okre\u015blenie \u201ewszystkie wersje od PHP 5\u201d oddaje wyj\u0105tkowo szeroki zakres problemu, ale nie zast\u0119puje kontroli pakiet\u00f3w. Weryfikacji wymagaj\u0105 stare ga\u0142\u0119zie PHP 5 i 7 oraz PHP 8. Dokumentacja cPanel wymienia tak\u017ce starsze pakiety i konkretne poprawione rewizje dostawc\u00f3w. Przej\u015bcie z PHP 7 na dowolne PHP 8 nie stanowi wi\u0119c dowodu ochrony. [7]<\/a><\/p>\n

Szczeg\u00f3lnie powa\u017cny przypadek dotyczy Apache z mod_php: potwierdzona \u015bcie\u017cka ataku dzia\u0142a jeszcze przed uruchomieniem kodu aplikacji. PHP-FPM r\u00f3wnie\u017c nie stanowi bezpiecznego wyj\u0105tku; PHP Foundation informuje o potwierdzonym wykonaniu kodu przez \u015bcie\u017cki zale\u017cne od aplikacji. Logowanie do WordPressa nie zapewnia zatem skutecznej ochrony przed b\u0142\u0119dem ni\u017cszej warstwy. [2]<\/a><\/p>\n

Kt\u00f3re aktualizacje zapewniaj\u0105 ochron\u0119?<\/h2>\n

Poprawione oficjalne wydania to 8.2.35, 8.3.36, 8.4.27 i 8.5.12<\/strong>; w\u0142a\u015bciwe jest r\u00f3wnie\u017c p\u00f3\u017aniejsze poprawione wydanie odpowiedniej ga\u0142\u0119zi. PHP 8.1 i starsze nie otrzymuj\u0105 ju\u017c regularnych wyda\u0144 projektu PHP. Wyj\u0105tkowo udost\u0119pniono minimalne poprawki kodu \u017ar\u00f3d\u0142owego dla 7.4, 8.0 i 8.1. Dystrybucje oraz dostawcy LTS mog\u0105 oferowa\u0107 w\u0142asne poprawione pakiety. [1]<\/a><\/p>\n

Stary numer wersji bazowej nie dowodzi automatycznie braku poprawki. Liczy si\u0119 pe\u0142na rewizja pakietu i potwierdzenie usuni\u0119cia obu<\/em> podatno\u015bci. Z kolei samo oznaczenie \u201ePHP 8\u201d nie potwierdza bezpiecze\u0144stwa. [7]<\/a><\/p>\n

\"Cztery
Poprawka musi trafi\u0107 do dzia\u0142aj\u0105cej us\u0142ugi WWW.<\/figcaption><\/figure>\n

Od aktualizacji pakietu do ochrony us\u0142ugi<\/h2>\n
  1. Inwentaryzacja:<\/strong> Zakres obejmuje domeny, pule PHP, kontenery, zapomniane instalacje testowe i wbudowane panele administracyjne.<\/li>
  2. Potwierdzenie poprawki:<\/strong> Ka\u017cde \u015brodowisko wymaga udokumentowania \u017ar\u00f3d\u0142a pakietu, rewizji i usuni\u0119cia obu podatno\u015bci.<\/li>
  3. Wymiana dzia\u0142aj\u0105cych instancji:<\/strong> Procesy PHP musz\u0105 za\u0142adowa\u0107 poprawiony kod. W\u0142asne kontenery wymagaj\u0105 poprawionego obrazu i ponownego wdro\u017cenia. Aktualizacja hosta nie zmienia istniej\u0105cego obrazu kontenera. [8]<\/a><\/li>
  4. Kontrola obs\u0142ugi WWW:<\/strong> Wiersz polece\u0144 mo\u017ce korzysta\u0107 z innej instalacji PHP ni\u017c witryna. Weryfikacj\u0119 zamyka przypisanie domeny do faktycznie dzia\u0142aj\u0105cego \u015brodowiska i sprawdzenie podstawowych funkcji.<\/li><\/ol>\n

    W przypadku braku mo\u017cliwo\u015bci natychmiastowej aktualizacji ENISA zaleca rozwa\u017cenie izolacji publicznie dost\u0119pnych aplikacji. Statyczna strona techniczna obs\u0142ugiwana przed PHP mo\u017ce zatrzyma\u0107 ruch do podatnego \u015brodowiska. Wtyczka trybu konserwacji dzia\u0142aj\u0105ca wewn\u0105trz tej samej aplikacji PHP nie zapewnia takiego oddzielenia w spos\u00f3b niezawodny. [5]<\/a><\/p>\n

    Oficjalne \u015brodki konfiguracyjne jedynie tymczasowo ograniczaj\u0105 ekspozycj\u0119. Przyk\u0142adowo session.upload_progress.enabled=0<\/code> blokuje okre\u015blone potwierdzone \u015bcie\u017cki zwi\u0105zane z sesj\u0105, lecz nie wszystkie warianty. Zmiana limit\u00f3w pami\u0119ci r\u00f3wnie\u017c nie jest uniwersaln\u0105 napraw\u0105. Nieograniczona pami\u0119\u0107 PHP mo\u017ce zwi\u0119kszy\u0107 ryzyko niedost\u0119pno\u015bci; limity poza PHP wymagaj\u0105 odpowiedniego skoordynowania. \u017badne z tych dzia\u0142a\u0144 nie zast\u0119puje aktualizacji. [3]<\/a> [4]<\/a><\/p>\n

    Skutki braku aktualizacji<\/h2>\n

    Punktem wyj\u015bcia jest wykonanie kodu z uprawnieniami procesu WWW, a nie automatyczne uzyskanie uprawnie\u0144 root. Zale\u017cnie od uprawnie\u0144 i dost\u0119pnych sekret\u00f3w mo\u017cliwe nast\u0119pstwa obejmuj\u0105 kradzie\u017c danych dost\u0119powych do bazy, ujawnienie danych klient\u00f3w, zmian\u0119 tre\u015bci, instalacj\u0119 z\u0142o\u015bliwego oprogramowania oraz nadu\u017cycie kluczy API. Dost\u0119pne us\u0142ugi wewn\u0119trzne mog\u0105 sta\u0107 si\u0119 kolejnym celem, je\u015bli pozwalaj\u0105 na to po\u0142\u0105czenia sieciowe i uprawnienia. [3]<\/a><\/p>\n

    W sklepie internetowym zmieniona strona p\u0142atno\u015bci mo\u017ce wyrz\u0105dzi\u0107 wi\u0119ksze szkody ni\u017c widoczna awaria. Dochodz\u0105 koszty analizy, odtwarzania, przestoju i utraty zaufania. P\u00f3\u017aniejsza aktualizacja nie usuwa wcze\u015bniej zainstalowanej furtki. Konkretne \u015blady w\u0142amania wymagaj\u0105 izolacji, zabezpieczenia dowod\u00f3w, kontroli danych dost\u0119powych i odtworzenia z zaufanego stanu.<\/p>\n

    Czy administratorzy rzeczywi\u015bcie zainstaluj\u0105 poprawki?<\/h2>\n

    Ocena:<\/strong> Szybki pocz\u0105tkowy spadek liczby zagro\u017conych instalacji jest prawdopodobny; pe\u0142ne zako\u0144czenie aktualizacji w ci\u0105gu kilku dni wydaje si\u0119 ma\u0142o realne. Centralnie utrzymywane platformy mog\u0105 poprawi\u0107 wiele witryn jednocze\u015bnie. W\u0142asne serwery zale\u017c\u0105 od odpowiedzialno\u015bci, dost\u0119pno\u015bci pakiet\u00f3w, zgodno\u015bci i kontrolowanych restart\u00f3w. Google Cloud wyra\u017anie rozr\u00f3\u017cnia \u015brodowiska aktualizowane automatycznie oraz us\u0142ugi wymagaj\u0105ce ponownego wdro\u017cenia. [8]<\/a><\/p>\n

    Najtrudniejsza pozostanie zapewne grupa porzuconych projekt\u00f3w, starych wdro\u017ce\u0144 agencyjnych, kontener\u00f3w bez procesu utrzymania i aplikacji zale\u017cnych od niewspieranych ga\u0142\u0119zi. Op\u00f3\u017anienia nie oznaczaj\u0105 automatycznie zaniedbania administrator\u00f3w. Brak bud\u017cetu, niejasny podzia\u0142 odpowiedzialno\u015bci i niesprawdzone zale\u017cno\u015bci starszych aplikacji mog\u0105 organizacyjnie zablokowa\u0107 prost\u0105 technicznie poprawk\u0119. Konkretna globalna skuteczno\u015b\u0107 aktualizacji by\u0142aby obecnie spekulacj\u0105.<\/p>\n

    Ile witryn pozostanie zagro\u017conych?<\/h2>\n

    Wed\u0142ug W3Techs z 22 pa\u017adziernika PHP wyst\u0119puje w 69,3 proc. witryn o rozpoznanym j\u0119zyku programowania po stronie serwera<\/strong>. W\u015br\u00f3d rozpoznanych witryn PHP udzia\u0142 PHP 7 wynosi 26,9 proc., a PHP 5 \u2014 7,7 proc., \u0142\u0105cznie 34,6 proc. Te liczby opisuj\u0105 popularno\u015b\u0107 i starsze wersje, a nie zmierzon\u0105 liczb\u0119 instalacji bez poprawki. [9]<\/a><\/p>\n

    Nie wynika z tego wiarygodna bezwzgl\u0119dna liczba nadal zagro\u017conych witryn. Poprawki dostawc\u00f3w, r\u00f3\u017cnice konfiguracji, ukryte numery wersji oraz wiele witryn na jednym serwerze uniemo\u017cliwiaj\u0105 proste przeliczenie. Pojedyncze podstrony, domeny i serwery s\u0105 ponadto r\u00f3\u017cnymi jednostkami zliczania.<\/p>\n

    Wy\u0142\u0105cznie ilustracja rachunkowa: w grupie miliona faktycznie podatnych instalacji skuteczne uko\u0144czenie 95 proc. aktualizacji pozostawi\u0142oby 50 000 bez poprawki. To ani pomiar, ani prognoza<\/strong>. Obliczenie pokazuje jedynie, dlaczego nawet wysoki poziom uko\u0144czenia aktualizacji mo\u017ce pozostawi\u0107 znacz\u0105c\u0105 grup\u0119 zagro\u017conych system\u00f3w. Dla konkretnej witryny potwierdzony stan poprawki ma wi\u0119ksz\u0105 warto\u015b\u0107 ni\u017c globalny procent.<\/p>\n

    Linux w praktyce: inwentaryzacja faktycznie u\u017cywanego \u015brodowiska<\/h2>\n

    Poni\u017csze przyk\u0142ady dotycz\u0105 system\u00f3w Debian\/Ubuntu z APT i ju\u017c skonfigurowanymi zaufanymi repozytoriami. Odpowiednia ga\u0142\u0105\u017a PHP musi by\u0107 wcze\u015bniej zainstalowana. Systemy RPM, panele hostingowe i w\u0142asne kontenery wymagaj\u0105 procedury w\u0142a\u015bciwego dostawcy. Dodanie przypadkowego zewn\u0119trznego repozytorium nie jest wiarygodn\u0105 strategi\u0105 naprawy.<\/p>\n

    Przed zmian\u0105 potrzebne s\u0105 kopia umo\u017cliwiaj\u0105ca odtworzenie, przypisanie domen do pul PHP i kr\u00f3tki plan test\u00f3w funkcjonalnych. Instalacja pakiet\u00f3w mo\u017ce sama restartowa\u0107 us\u0142ugi, dlatego okno serwisowe rozpoczyna si\u0119 przed poleceniem instalacji. Inwentaryzacja pokazuje CLI i us\u0142ugi, ale jeszcze nie potwierdza sposobu obs\u0142ugi witryny:<\/p>\n\n

    Shell<\/span>Linux: inwentaryzacja PHP<\/span>