AktualnościMakroPHP wydaje awaryjne poprawki dwóch krytycznych błędów dotykających miliony witryn

PHP wydaje awaryjne poprawki dwóch krytycznych błędów dotykających miliony witryn

Autor: Decrypt·

Najważniejsze informacje

  • •PHP wydało 21 października wersje 8.5.12, 8.4.27, 8.3.36 i 8.2.35, aby usunąć CVE-2026-109618 i CVE-2026-109619 — dwie krytyczne wady ocenione na 9,2 w skali 10, umożliwiające atakującym wykonywanie kodu na serwerach bez logowania.
  • •Poprawka dotar około 25 minut przed schedulem po upublicznieniu szczegółów i zgłoszeniu przez Cloudflare aktywnych ataków niemal sześć godzin przed udostępnieniem poprawki.
  • •Organy rządowe w Finlandii, Holandii i Francji profilaktycznie wyłączyły witryny, a amerykańska NSA, CERT-EU oraz agencje w Australii, Japonii i Wielkiej Brytanii zalecały zamykanie lub izolowanie witryn PHP do czasu załatania.
  • •Około 884 000 hostów dostępnych z internetu z PHP 8.1 lub starszym stanowiło 59% publicznie widocznych hostów ujawniających wersję, a te przestarzałe wydania otrzymały jedynie ograniczone poprawki kodu źródłowego mimo braku regularnych oficjalnych aktualizacji.
  • •Automatyczne aktualizacje WordPress nie zastosują tej poprawki, więc operatorzy witryn muszą potwierdzić załatanie samego PHP, a PHP 8.2 osiągnie koniec życia 31 grudnia 2026 roku.
PHP wydaje awaryjne poprawki dwóch krytycznych błędów dotykających miliony witryn

PHP wydało 21 października wersje 8.5.12, 8.4.27, 8.3.36 i 8.2.35, aby usunąć CVE-2026-109618 i CVE-2026-109619 — dwie podatności ocenione na 9,2 w skali 10, umożliwiające nieuwierzytelnione zdalne wykonanie kodu.

Podatności skłoniły Finlandię, Holandię i Francję do profilaktycznego wyłączenia rządowych witryn po przedwczesnym ujawnieniu szczegółów. Cloudflare zgłosiło także ataki na kilka godzin przed publikacją poprawki. Amerykańska Agencja Bezpieczeństwa Narodowego zaleciła organizacjom korzystającym z PHP wyłączenie witryn, a agencje w Australii, Japonii i Wielkiej Brytanii wydały podobne zalecenia.

Większość użytkowników internetu nie musi niczego instalować. Odpowiedzialność za zastosowanie poprawki spoczywa na operatorach witryn, firmach hostingowych i organizacjach utrzymujących serwery PHP. Wersje PHP 8.1 i starsze nie otrzymują regularnych oficjalnych wydań, choć zedu na powagę problemu zespół bezpieczeństwa PHP opublikował ograniczone poprawki kodu źródłowego dla części starszych wersji.

Według W3Techs PHP obsługuje około 70% witryn o znanym języku po stronie serwera. Ten język programowania działa na serwerach, gdzie pomaga przechowywać witryny i generować strony żądane przez odwiedzających. Witryny WordPress, na przykład, powszechnie bazują na serwerach PHP — według firmy zajmującej się bezpieczeństwem WordPress, Wordfence.

Oba błędy mogą pozwolić atakującemu na wykonywanie poleceń na serwerze PHP bez logowania. Ten typ wady nazywany jest nieuwierzytelnionym zdalnym wykonaniem kodu. W zależności od serwera i przechowywanych danych skuteczny atak może ujawnić dane kont, adresy, historię zamówień lub inne wrażliwe informacje.

Dostawca hostingu GoDaddy ostrzegł, że podatności mogą umożliwić atakującym kradzież danych, zdewastowanie witryn lub przejęcie pełnej kontroli nad dotkniętymi serwerami.

„Taka wada może pozwolić atakującemu na uruchomienie własnego kodu na dotkniętym serwerze przez internet, co może prowadzić do kradzieży danych, zdewastowania witryny lub pełnego przejęcia” — powiedziało GoDaddy w aktualizacji bezpieczeństwa.

Ogłoszenie bezpieczeństwa PHP

PHP Foundation, organizacja non-profit finansująca rozwój języka, wydała ostrzeżenie z wyprzedzeniem 20 października. W oświadczeniu opublikowanym na X stwierdziła:

„Zespół bezpieczeństwa PHP uprzedza: nadchodzące wydanie bezpieczeństwa w środę, 21 października 2026, 14:00 UTC, dwie krytyczne podatności, obie ocenione na CVSSv4 9.2. Użytkownicy PHP powinni przygotować się do aktualizacji. Wcześniejsze wydanie, jeśli szczegóły staną się publiczne lub pojawią się dowody aktywnego wykorzystania.”

The PHP security team is giving advance notice: Upcoming security release Wed, Oct 21st 2026, 14:00UTC, two critical vulnerabilities, both rated CVSSv4 9.2. PHP users are encouraged to prepare to update. Earlier release if details become public or active exploit evidence. — The PHP Foundation (@ThePHPF) October 20, 2026

Common Vulnerability Scoring System, czyli CVSS, ocenia podatności w skali od 0 do 10 na podstawie czynników takich jak łatwość wykorzystania przez internet i potencjalny wpływ. Wyniki od 9,0 wzwyż klasyfikowane są jako krytyczne.

PHP wydało poprawkę około 13:35 UTC 21 października, około 25 minut przed ogłoszoną godziną. Adewis bezpieczeństwa brzmiał: „Wszyscy użytkownicy PHP zdecydowanie powinni natychmiast zaktualizować oprogramowanie.” Wydanie przyspieszono o jeden dzień po upublicznieniu informacji o podatnościach i pojawieniu się dowodów ataków.

Jak działają podatności

CVE-2026-109618 występuje, gdy PHP kończy mu się pamięć podczas przetwarzania żądania, a później traktuje częściowo zbudowane dane jako kompletne. CVE-2026-109619 pozwala resztkom żądania jednego odwiedzającego pozostać pamięci po tym, jak powinny zostać usunięte, co umożliwia kolejnemu żądaniu interakcję z tymi pozostałościami.

Ryzyko jest najwyższe na serwerach używających mod_php — popularnej konfiguracji Apache. PHP poinformowało, że zademonstrowany exploit działa „zanim uruchomi się jakikolwiek kod aplikacji”, co oznacza, że zabezpieczenia wdrożone przez samą witrynę — takie jak ekrany logowania i wtyczki bezpieczeństwa WordPress — mogą nie mieć możliwości interwencji.

Badacze z PHP Foundation zidentyfikowali funkcję upload-progress PHP jako jedną z potwierdzonych dróg wejścia w podatność. Funkcja śledzi postęp przesyłania pliku, jest domyślnie włączona od ponad dekady i niewiele witryn faktycznie jej używa.

Dalsze informacje techniczne są dostępne w archiwum bezpieczeństwa PHP, analizie watchTowr oraz wpisie NVD dotyczącym CVE-2026-109619. Dokumentacja PHP opisuje również powiązaną konfigurację sesji.

Wyciek przed poprawką

Ujawnienie początkowo nie miało nastąpić przed zaplanowanym wydaniem. We wtorek użytkownik opublikował na forum Hacker News informację, że dwie podatności PHP zostaną ujawnione w czwartek, przyznając jednocześnie, że twierdzenie nie miało „żadnych dowodów poza «źródło: uwierź mi, stary»”. Post jest dostępny tutaj.

Firma bezpieczeństwa watchTowr potwierdziła później, że podatności są prawdziwe i objęte embargiem — porozumieniem mającym utrzymać szczegóły techniczne w tajemnicy do czasu przygotowania poprawki. PHP przyspieszyło wtedy wydanie.

Dyrektor techniczny Cloudflare Dane Knecht powiedział na X w środę nad ranem, że ataki już się rozpoczęły — niemal sześć godzin przed publikacją poprawki. Cloudflare wdrożyło awaryjne reguły zapory aplikacji internetowej dla swoich klientów, w tym klientów planów darmowych, ale Knecht określił te reguły jako jedynie tymczasowe.

„PHP sites behind Cloudflare already have an initial set of WAF rules deployed for the known exploit vectors in these vulnerabilities. The rules are available to all customers, including free. We are seeing early attacks emerging and are updating mitigations as new vectors show… — Dane Knecht 🦭 (@dok2001) October 21, 2026”

Oryginalny post jest również dostępny na koncie X Dane'a Knechta.

Rządy wyłączają witryny

Fińskie państwowe centrum IT, Valtori, rozpoczęło profilaktyczne wyłączanie publicznych usług internetowych — według publicznego nadawcy Yle. Holenderska narodowa agencja cyberbezpieczeństwa również wyłączyła swoją witrynę.

Francuskie Ministerstwo Spraw Wewnętrznych poinformowało, że witryny prefektur zostały „tymczasowo wyłączone do czasu publikacji poprawki bezpieczeństwa przez wydawcę frameworka”.

Unijny zespół ds. sytuacji kryzysowych w cyberbezpieczeństwie, CERT-EU, zalecił organizacjom niemogącym zastosować poprawki, aby „rozważyły odizolowanie aplikacji dostępnych z internetu od sieci publicznych do czasu udostępnienia poprawki”.

Reuters poinformował, że agencje w Australii, Japonii i Wielkiej Brytanii wydały podobne zalecenia. Raport Reutersa wskazywał także, że witryny mogą wymagać wyłączenia, podczas gdy operatorzy przygotowują się do instalacji poprawek.

Twierdzenia dotyczące dotkniętych wersji PHP

Posty krążące na X twierdziły, że podatne są wersje PHP „sięgające 2004 roku”. Twierdzenie to pochodziło z wczesnych szacunków, że dotknięta jest każda wersja od PHP 5 — oceny, która, jak przyznało CERT-EU, opierała się na postach w mediach społecznościowych.

Firma bezpieczeństwa e-commerce Sansec oszacowała, że dotknięte są wersje PHP 5.4 i nowsze, co przesuwa zakres do 2012, a nie 2004 roku. PHP oficjalnie dostarcza bieżące wydania tylko dla wersji 8.2 i nowszych. Jednak ze względu na powagę tych podatności zespół bezpieczeństwa opublikował także podstawowe poprawki kodu źródłowego dla PHP 7.4, 8.0 i 8.1, a dystrybucje Linuksa rozpoczęły niezależne wprowadzanie poprawek.

Firma bezpieczeństwa Mallory zliczyła około 884 000 hostów dostępnych z internetu zgłaszających PHP 8.1 lub starsze 20 października. Stanowiło to 59% z około 1,5 miliona publicznie widocznych hostów ujawniających wersję PHP. Liczba dotkniętych witryn jest wyższa, ponieważ pojedynczy serwer hostingu współdzielonego może obsługiwać wiele witryn. Badania Mallory są dostępne tutaj, a analiza Sansec tutaj.

Niektóre posty w sieci włączyły do dyskusji także Node.js. Node.js to odrębna technologia internetowa, która akurat miała zaplanowaną na ten sam dzień własną, niezwiązaną aktualizację bezpieczeństwa.

PHP Foundation ostrzegła, że poprawione wersje nie będą dostępne wszędzie jednocześnie. „If you rely on the volunteer maintained we urge you to move to distro packages or building from source now, so you can immediately apply updates. The repo will not have updates today” — stwierdziła w oświadczeniu, odnosząc się do prowadzonego przez wolontariuszy źródła pakietów PHP dla serwerów Linuksa w stylu Red Hat. Repozytorium pakietów jest dostępne pod adresem

Potencjalny wpływ na witryny i aktywa cyfrowe

Skompromitowana witryna nie musi bezpośrednio komunikować się z blockchainem, aby narazić aktywa cyfrowe użytkowników. W 2024 roku atakujący przekierowali frontendy protokołów DeFi Compound i Celer do stron zaprojektowanych w celu opróżniania połączonych portfeli. Curve Finance padł ofiarą podobnego ataku w 2025 roku. Te incydenty dotyczyły porwań DNS, a nie podatności PHP, ale efekt może wyglądać podobnie dla odwiedzającego: witryna i adres URL wyglądają wiarygodnie, a akcja zatwierdzenia wysyła tokeny gdzie indziej.

Skompromitowany serwer PHPógłby zostać użyty do serwowania dokładnie takiej fałszywej strony. Relację między podatną infrastrukturą internetową a kradzieżą kryptowalut omówił także przedsiębiorca @levelsio, który powiedział na X, że odłączył swoje witryny i serwery VPS w oczekiwaniu na poprawkę.

“I pre-emptively disconnected ALL my sites / VPS servers from the web I'll wait for the patch to hit at 2 PM UTC If you have a PHP website, probably good to take them down until you patch PHP 69.3% of the web runs on PHP so this is going to be intense! Good time maybe to buy… — @levelsio (@levelsio) October 21, 2026”

Post jest również dostępny na X. Wcześniejsze raporty Decrypt o incydencie Compound i Celer oraz ataku na Curve są dostępne tutaj i tutaj.

Podatności pojawiły się także w momencie, gdy graniczne modele sztucznej inteligencji są coraz częściej wykorzystywane do wykrywania wad oprogramowania. Eksperci powiedzieli Decryptowi w czerwcu, że rozprzestrzenianie się takich narzędzi może prowadzić do odkrycia znacznie większej liczby podatności. Raport Decrypt jest dostępny tutaj.

Co powinni zrobić operatorzy witryn

Po upublicznieniu poprawki atakujący mogą porównać podatny i poprawiony kod, aby ustalić, co zmieniono. Zespół kryminalistyczny Sansec powiedział, że spodziewa się „masowych ataków rozpoczętych w ciągu 15 minut od wydania”. Gdy inna podatność PHP została ujawniona w czerwcu 2024 roku, Akamai odnotował próby wykorzystania na swoich serwerach-pułapkach w ciągu 24 godzin. Analiza Akamai jest dostępna tutaj.

Telefony, przeglądarki i osobiste laptopy nie wymagają aktualizacji PHP. Praca spoczywa na organizacjach prowadzących witryny i serwery. Właściciele witryn powinni zapytać dostawców hostingu, czy PHP został zaktualizowany, i ustalić, kto odpowiada za utrzymanie serwera.

Wordfence ostrzegł, że automatyczne aktualizacje WordPress nie zastosują tej poprawki. Właściciele witryn muszą zatem upewnić się, że samo PHP zostało załatane, zamiast zakładać, że aktualizacja WordPress rozwiąże problem.

Twórca rdzenia PHP Gina Peter Banyard powiedziała na Mastodonie: „Jedyne, co mogę powiedzieć, to że jedyną mitigacją jest załatanie / aktualizacja PHP”, dodając: „Niestety wiem za dużo.” Post jest dostępny tutaj.

Organizacje korzystające z PHP 8.1 lub starszego muszą zaplanować aktualizację, ponieważ te wersje nie otrzymują regularnych oficjalnych wydań. Użytkownicy PHP 8.2 także stają przed zbliżającym się terminem: PHP 8.2 osiąga koniec życia 31 grudnia 2026 roku, po czym nie będzie już otrzymywać poprawek bezpieczeństwa.