~/ / Artykuły o AI / AI pomogła znaleźć PHP2Shell: krytyczne podatności PHP z października 2026

AI pomogła znaleźć PHP2Shell: krytyczne podatności PHP z października 2026

Według doniesień prasowych modele AI pomogły badaczom znaleźć dwie krytyczne podatności w samym PHP, CVE-2026-109618 i CVE-2026-109619, które mogą umożliwiać nieuwierzytelnione zdalne wykonanie kodu. PHP wydało wersje z poprawkami 21 października 2026. Ten artykuł podsumowuje, co oficjalne komunikaty i doniesienia mówią o tych lukach i o udziale AI, oraz pozwala sprawdzić, czy używane przez Ciebie PHP ma poprawkę.

Sprawdzono z oficjalnymi komunikatami dnia 2026-10-24. Ta strona nie jest oficjalnym biuletynem bezpieczeństwa, a szczegóły mogą się zmieniać, więc śledź źródła na dole strony.

Co zrobić najpierw

Zaktualizuj PHP do wydania z poprawką (8.5.12, 8.4.27, 8.3.36 lub 8.2.35) albo do pakietu z poprawką z Twojej dystrybucji Linuksa. PHP twierdzi, że nie ma kompletnych sposobów łagodzenia skutków i że jedynym bezpiecznym wyborem jest aktualizacja.
Po aktualizacji uruchom ponownie PHP-FPM, Apache i wszystkie długo działające procesy robocze PHP, aby wczytały poprawiony kod. Usługa uruchomiona przed aktualizacją nadal wykonuje stary kod.
Jeśli PHP pochodzi z pakietu dystrybucji, sprawdź pełną wersję pakietu, wraz z częścią po pierwszym myślniku. Dystrybucje mogą zawierać poprawkę bez zmiany pierwszej części numeru.
Jeśli nie możesz zaktualizować od razu, zobacz poniższe środki łagodzące. PHP twierdzi, że zmniejszają one narażenie na określone ścieżki ataku, ale nie czynią instalacji bezpieczną.

Co się stało

21 października 2026 PHP wydało wersje 8.5.12, 8.4.27, 8.3.36 i 8.2.35. Naprawiają one dwie krytyczne podatności, obie ocenione na 9.2 w skali CVSS v4.0.

CVE-2026-109618, nazwana RCE via OOM corruption: obsługa braku pamięci może przerwać działanie PHP, gdy wewnętrzne dane żądania są zainicjowane tylko częściowo, a czyszczenie po żądaniu może wtedy potraktować nieprawidłowe dane jako prawidłowe.

CVE-2026-109619, nazwana RCE via stale global state: wewnętrzny stan należący do żądania może przetrwać po zwolnieniu pamięci, która go przechowywała, a późniejsze żądanie obsłużone przez ten sam proces roboczy może użyć tego nieaktualnego stanu.

CVE-2026-109618 · CVSS 4.0 9.2
CVE-2026-109619 · CVSS 4.0 9.2

Rola AI

Według The Next Web firma zajmująca się bezpieczeństwem Calif znalazła pierwszy błąd w sierpniu z pomocą modelu OpenAI, podczas audytu kodu źródłowego PHP sfinansowanego przez OpenAI. Wiz oświadczył, że znalazł te błędy niezależnie, kilka tygodni później, używając narzędzi AI, w tym modeli Gemini od Google.

Witryna php2shell.com wskazuje jako autorów badań Wiz Research, OpenAI Codex Security i Calif. Calif oświadczył, że użył ogólnie dostępnych modeli oraz że znajomość historii PHP miała większe znaczenie niż sam model.

Ten sam artykuł informuje, że Cloudflare włączył reguły WAF dla swoich klientów około dziewięć godzin przed ujawnieniem, a następnie w sieci zaczął krążyć exploit typu proof-of-concept. Witryna php2shell.com podaje, że reguły WAF lub CDN nie należy traktować jako zamiennika aktualizacji PHP.

Oś czasu

2026-10-20PHP zapowiada nadchodzące krytyczne wydanie bezpieczeństwa, zaplanowane na 21 października o 14:00 UTC.
2026-10-21Wydano PHP 8.5.12, 8.4.27, 8.3.36 i 8.2.35 wraz z biuletynem bezpieczeństwa, a Ubuntu publikuje USN-8948-1.
2026-10-23PHP publikuje biuletyn informacyjny dotyczący session.upload_progress.enabled, w sprawie kolejnego, mało prawdopodobnego wektora śledzonego jako CVE-2026-115560.

Kogo to dotyczy

PHP twierdzi, że zagrożone są wszystkie instalacje PHP obsługujące żądania webowe, w tym PHP-FPM, Apache z mod_php, php-cgi, FrankenPHP i LiteSpeed. Za najbardziej narażone uznaje mod_php, gdzie nieuwierzytelnione żądanie może wywołać atak, zanim uruchomi się jakikolwiek kod aplikacji.

Biuletyny GitHub wskazują jako podatne wersje poniżej 8.2.35, 8.3.36, 8.4.27 i 8.5.12. Witryna php2shell.com, wskazana jako prowadzona przez Wiz, podaje, że dotknięte wydania sięgają wstecz aż do PHP 5.4.

PHP 8.1 i starsze nie otrzymują już aktualizacji od projektu PHP. Niektóre dystrybucje i dostawcy LTS udostępniają przeniesione wstecz poprawki, a PHP udostępniło minimalne przeniesienia poprawek w źródłach dla PHP 7.4, 8.0 i 8.1 dla osób, które budują PHP ze źródeł.

Wersje z poprawką

Wersja równa wydaniu z poprawką dla swojej gałęzi lub nowsza zawiera poprawkę. Pakiet dystrybucji jest naprawiony według wersji pakietu, więc dla Ubuntu i Debiana użyj drugiej tabeli.

Własne wydania PHP

Gałąź	Pierwsze wydanie z poprawką
PHP 8.5	8.5.12
PHP 8.4	8.4.27
PHP 8.3	8.3.36
PHP 8.2	8.2.35

Pakiety Ubuntu i Debiana

Dystrybucja	Pakiet	Wersja pakietu z poprawką	Komunikat
Ubuntu 26.10	php8.5	8.5.9-0ubuntu2.1	USN-8948-1
Ubuntu 26.04 LTS	php8.5	8.5.4-0ubuntu1.5	USN-8948-1
Ubuntu 24.04 LTS	php8.3	8.3.6-0ubuntu0.24.04.13	USN-8948-1
Ubuntu 22.04 LTS	php8.1	8.1.2-1ubuntu2.28	USN-8948-1
Debian 12 (bookworm)	php8.2	8.2.35-1~deb12u1	DLA-4848-1
Debian 13 (trixie)	php8.4	8.4.27-1~deb13u1	DSA-6574-1

Tabele pokazują tylko to, co wymieniają oficjalne komunikaty. W przypadku innych dystrybucji sprawdź komunikat bezpieczeństwa swojego dostawcy.

Sprawdź swoje PHP

Wybierz, skąd pochodzi Twoje PHP, wklej tekst z wersją, a narzędzie porówna go z wersjami z poprawką podanymi wyżej. Ocenia wyłącznie wklejony tekst. Nie widzi, jaka wersja jest uruchomiona, więc potwierdź także, że usługa została uruchomiona ponownie po aktualizacji.

Polecenia pokazujące wersję

php -v
dpkg -l 'php*' | grep ^ii
apt-cache policy php8.3-fpm | grep Installed

Skąd pochodzi Twoje PHP?

Tekst z wersją

Wszystko działa w Twojej przeglądarce. Wklejony tekst nie jest przesyłany.

Jeśli nie możesz zaktualizować od razu

PHP wymienia te środki. Twierdzi, że zmniejszają one narażenie na określone ścieżki ataku, ale nie czynią instalacji bezpieczną, oraz że kompletnym rozwiązaniem jest wyłącznie aktualizacja.

CVE-2026-109618

Ustaw memory_limit=-1, najlepiej w sposób, którego aplikacje nie mogą nadpisać, na przykład przez php_admin_value w puli FPM lub w konfiguracji Apache. Błąd alokacji na niższym poziomie nadal może doprowadzić do podatnej ścieżki.
Ustaw niski post_max_size: 8M dla aplikacji, które nie potrzebują przesyłania plików, i 32M, jeśli przesyłanie plików jest potrzebne. Utrzymuj upload_max_filesize poniżej post_max_size.
Egzekwuj limity na serwerze WWW lub proxy dla rozmiaru zdekodowanego żądania, liczby pól wejściowych, liczby części multipart, liczby nagłówków i głębokości zagnieżdżenia.
Używaj limitu kontenera lub cgroup jako granicy dostępności. Nie używaj RLIMIT_AS ani RLIMIT_DATA, ponieważ mogą wywołać błąd alokacji prowadzący do podatnej ścieżki.

CVE-2026-109619

Ustaw session.upload_progress.enabled=0 w php.ini, w puli FPM lub w konfiguracji serwera i uruchom ponownie każdy proces roboczy. Nie polegaj na ini_set() ani na pliku .user.ini w FPM.
W PHP 8.5 ustaw fatal_error_backtraces=0 i uruchom ponownie każdy proces roboczy.
Usuń nieprawidłowe lub przestarzałe ustawienia stosowane dla pojedynczego żądania, które emitują komunikaty diagnostyczne przed inicjalizacją. Ukrywanie komunikatów diagnostycznych nie pomaga.
Napraw błędy krytyczne i przekroczenia czasu wykonania, do których może dotrzeć atakujący.

Biuletyn informacyjny z 23 października

PHP sugeruje ustawienie session.upload_progress.enabled=0 do czasu następnego regularnego wydania z poprawkami błędów, aby w pełni zabezpieczyć się przed mało prawdopodobnym kolejnym wektorem zdalnego wykonania kodu. Jeśli zastosowano to już zgodnie z biuletynem z 21 października, pozostaw to ustawienie.

PHP podaje, że problem może wystąpić tylko przy nietypowym połączeniu warunków: aplikacja ustawia w konfiguracji session.serialize_handler na php_binary lub php_serialize, przełącza go w czasie działania na php za pomocą ini_set() przed session_start(), a postęp przesyłania w sesji jest nadal włączony. PHP opublikuje pełny biuletyn dla CVE-2026-115560 wraz z następnym wydaniem.

Czego ta strona nie robi

Nie jest oficjalnym biuletynem i nie podaje szczegółów exploitów. Autorytetem są oficjalne komunikaty i biuletyny wymienione poniżej.
Nie potrafi stwierdzić, czy system został zaatakowany. Witryna php2shell.com zauważa, że brak podejrzanej aktywności nie dowodzi, że system nie jest dotknięty.
Narażenie zależy od wersji, konfiguracji i konkretnej podatności. Środki łagodzące mogą wpływać na działanie aplikacji.