PHP2Shell
PHP2Shell – dwie poważne luki bezpieczeństwa (CVE-2026-109618 i CVE-2026-109619) w PHP w wersjach od 5.4 do 8.5, które pozwalają na zdalne wykonanie kodu (RCE)[1][2]. Ich istnienie ogłoszono publicznie 20 października 2026 roku[3][4]. Następnego dnia twórcy PHP wydali awaryjne poprawki dla wersji 8.2, 8.3, 8.4 i 8.5 oraz opublikowali szczegóły luk[2].
Odkrycie
[edytuj | edytuj kod]Luki występują w PHP od wersji 5.4, wydanej w 2012 roku[1][5]. Według firmy Wiz błędy, z których wynikają, tkwiły w kodzie od dziesięcioleci, ale wykazanie, że da się je wykorzystać, wymagało wyjątkowo złożonego łańcucha kroków[1]. W 2024 roku jeden z głównych programistów PHP usuwał błąd wykryty podczas zewnętrznego audytu i natrafił przy tym na pierwsze ślady błędu braku pamięci (OOM), z którego wynika luka CVE-2026-109618. Błędu nie naprawiono: zespół nie zdołał uzgodnić, jak to najlepiej poprawić, a nikt nie znalazł konkretnego sposobu ataku, więc sprawa nie miała wysokiego priorytetu[6][4].
Luki wykryły niezależnie od siebie trzy zespoły: Calif, OpenAI i Wiz[7][4]. Kalifornijska firma Calif[8] prowadziła audyt PHP w ramach programu „Patch the Planet”, który zainicjowało OpenAI[9][4]. Firma znalazła luki 1 sierpnia 2026 roku z pomocą dużego modelu językowego[10][7]. 11 sierpnia Calif zgłosiła twórcom PHP pierwszy błąd[4][7]. Pod opisem badań na stronie Calif podpisuje się Ryan Austin[7]. Według OpenAI Calif korzystała przy tym z modelu GPT-5.6 Sol[11]. Calif podała natomiast, że przy odkryciu używano wyłącznie modeli dostępnych publicznie[10][7]. Tego samego dnia OpenAI niezależnie zgłosiło błąd o tej samej przyczynie[4][9]. 24 sierpnia kolejne sposoby ataku zgłosiła firma Wiz[4], która należy do koncernu Alphabet i wchodzi w skład Google Cloud[10][12]. Jej badacze korzystali z dużych modeli językowych Gemini 4 Argon i GPT-5.6 Sol oraz z własnego narzędzia Wiz Atlas[1][10].
Twórcy PHP ocenili obie luki na 9,2 w dziesięciopunktowej skali CVSS v4.0 (poziom krytyczny)[13], a firma watchTowr – na 10,0[14].
Poprawki
[edytuj | edytuj kod]Opiekunowie PHP wydali poprawione wersje 8.2.35, 8.3.36, 8.4.27 i 8.5.12[2]. Projekt PHP nie aktualizuje już wersji 8.1 i starszych, ale ze względu na wagę luk zespół bezpieczeństwa przygotował minimalne poprawki kodu źródłowego dla wersji 7.4, 8.0 i 8.1[2]. Opublikowano też tymczasowe środki zaradcze. Opiekunowie zastrzegli jednak, że ograniczają one tylko niektóre drogi ataku, a pełną ochronę daje wyłącznie aktualizacja[2]. Poprawki kodu źródłowego trafiły do repozytorium php-src w serwisie GitHub 21 października 2026 roku o 13:34 UTC, razem z biuletynami bezpieczeństwa opisującymi obie luki[15][16][17]. Stało się to 26 minut przed zapowiedzianym terminem wydania[13].
Luki miały zostać ujawnione 22 października[4], ale 20 października na forum Hacker News pojawił się wpis zapowiadający dwie luki RCE w PHP[18][19]. Kilka godzin później firma watchTowr potwierdziła, że luki są prawdziwe[19][14]. Identyfikatory CVE krążyły wtedy na forach i w mediach społecznościowych, razem z błędnym terminem wydania i błędną oceną 10,0 w skali CVSS[4]. W odpowiedzi opiekunowie PHP opublikowali zapowiedź aktualizacji wcześniej, niż planowali, i przyspieszyli wydanie poprawek o jeden dzień, na 21 października, godz. 14:00 UTC[4]. W zapowiedzi zachęcili użytkowników, by przygotowali się do aktualizacji i zainstalowali ją od razu po wydaniu[13]. Firma Sansec przewidywała, że „masowe ataki zaczną się w ciągu 15 minut od wydania”[15].
20 października około 20:00 UTC firma Calif omyłkowo opublikowała nagranie, które pokazywało działanie jej exploita typu proof of concept na kilku celach. Calif usunęła nagranie, ale jego kopie krążyły w mediach społecznościowych. Według fundacji The PHP Foundation nagranie przyspieszyło powstawanie publicznych exploitów[4][6]. 21 października, jeszcze przed końcem embarga informacyjnego, krążyły już exploity typu proof of concept[20][4] i opisy częściowych środków zaradczych[14]. Tego dnia o 7:41 UTC, ponad sześć godzin przed uzgodnionym terminem, firma Chainguard opublikowała obrazy oprogramowania z poprawką. Podobnie jak inni dystrybutorzy otrzymała poprawkę wcześniej. Publikacja obrazów pozwoliła atakującym przeanalizować zmiany, zanim pozostali użytkownicy PHP mogli je zainstalować[4][6].
Zespół Amazon Threat Intelligence firmy Amazon wykrył w danych telemetrycznych systemu MadPot próbę wykorzystania PHP2Shell z 17 października 2026 roku, cztery dni przed publicznym ujawnieniem luk[20]. Cloudflare jeszcze przed wydaniem poprawek odnotował pierwsze ataki i wdrożył reguły zapory aplikacji internetowych (WAF). Zastrzegł przy tym, że są one tylko rozwiązaniem doraźnym[21][22][23]. Firma watchTowr podała, że do 21 października jej sieć honeypotów zarejestrowała rzeczywiste ataki[24]. Tego samego dnia amerykańska Cybersecurity and Infrastructure Security Agency (CISA) poinformowała, że nie zaobserwowała jeszcze wykorzystania luk[25].
Skutki
[edytuj | edytuj kod]
Według serwisu W3Techs z PHP korzysta 69% wszystkich stron internetowych, w tym strony oparte na systemach zarządzania treścią, takich jak Drupal, Joomla! i WordPress, dlatego luki mogły mieć bardzo szerokie skutki[25][9]. PHP jest też częścią urządzeń różnych producentów, paneli administracyjnych hostingu, takich jak cPanel i Plesk, oraz niektórych aplikacji dla systemu Windows[19].
Agencje bezpieczeństwa wzywały organizacje, które nie mogą od razu zainstalować poprawek, by rozważyły wyłączenie stron[9]. Amerykańska National Security Agency (NSA) zaleciła w takim wypadku wyłączenie systemu, dopóki zagrożenie nie zostanie w pełni usunięte[26][11]. Brytyjskie National Cyber Security Centre (NCSC) wydało podobne zalecenie i wezwało do sprawdzenia, czy atakujący nie zainstalowali w systemach backdoorów[27][10]. Unijny zespół CERT-EU zalecił, by organizacje rozważyły odizolowanie aplikacji dostępnych z internetu od sieci publicznych[25]. Wiele organizacji w Europie zapobiegawczo wyłączyło strony do czasu wydania poprawek[9][28], między innymi holenderski portal rządowy Overheid.nl, publiczne serwisy internetowe rządu Finlandii i strony francuskich prefektur, które wyłączyło Ministerstwo Spraw Wewnętrznych[29][9]. W Japonii urząd rządowy ds. cyberbezpieczeństwa (National Cybersecurity Office) wezwał do jak najszybszego działania[30].
Wikimedia Foundation wyłączyła narzędzia pomocnicze[29]. Według NBC News fora 4chan i Something Awful przestały działać do czasu wydania poprawki[25], a według serwisu Mashable 4chan przeszedł w tryb tylko do odczytu[29]. W Japonii prace konserwacyjne ogłosiły gry Umamusume: Pretty Derby, Granblue Fantasy i Princess Connect! Re:Dive[29], a także serwisy handlowe, między innymi BASE[30]. Internet Archive na krótko wyłączyło serwisy, aby zająć się problemem[31].
Oceny
[edytuj | edytuj kod]Badacze z Wiz porównali wagę problemu do luki Heartbleed z 2014 roku, która dotyczyła technologii szyfrowania używanej według szacunków przez dwie trzecie stron WWW[32]. Dziennik „The Guardian” zwrócił uwagę, że fundacja The PHP Foundation utrzymuje się z wpłat darczyńców, a do rozwijania języka PHP ma tylko 13 inżynierów zatrudnionych na pełny etat lub w niepełnym wymiarze, podczas gdy w rozwój sztucznej inteligencji zainwestowano miliardy[33].
Przypisy
[edytuj | edytuj kod]- 1 2 3 4 PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet | Wiz Blog. wiz.io, 2026-10-21. [dostęp 2026-10-22]. (ang.).
- 1 2 3 4 5 PHP: News Archive - 21 Oct 2026. www.php.net, 2026-10-21. [dostęp 2026-10-21]. (ang.).
- ↑ PHP: News Archive - 20 Oct 2026. www.php.net, 2026-10-20. [dostęp 2026-10-21]. [zarchiwizowane z tego adresu (2026-10-20)]. (ang.).
- 1 2 3 4 5 6 7 8 9 10 11 12 13 Today's PHP Security Release, and How We're Strengthening PHP Security. thephp.foundation. [dostęp 2026-10-21]. (ang.).
- ↑ PHP: Releases. www.php.net. [dostęp 2026-10-22]. (ang.).
- 1 2 3 Ana Maria Constantin: PHP knew about one of the flaws in 2024 but could not agree a fix. The Next Web, 2026-10-21. [dostęp 2026-10-21]. (ang.).
- 1 2 3 4 5 Ryan Austin: A tale of two PHP remote vulnerabilities. Calif Research. [dostęp 2026-10-22]. (ang.).
- ↑ Calif | Hackers gonna hack. Calif. [dostęp 2026-10-22]. (ang.).
- 1 2 3 4 5 6 Tom Gerkin: Websites taken down worldwide as critical PHP cyber-security update issued. BBC News, 2026-10-21. [dostęp 2026-10-21]. (ang.).
- 1 2 3 4 5 Robert Booth, Aisha Down: Flaw in PHP computer language leads to shutdown of websites around world. The Guardian, 2026-10-21. [dostęp 2026-10-21]. (ang.).
- 1 2 Michael Kan: This Flaw Is So Serious Websites Should Consider Going Offline, NSA Says. PCMAG, 2026-10-21. [dostęp 2026-10-21]. [zarchiwizowane z tego adresu (2026-10-21)]. (ang.).
- ↑ Google Completes Acquisition of Wiz. Alphabet, 2026-03-11. [dostęp 2026-10-22]. (ang.).
- 1 2 3 php.announce: [ANNOUNCE Upcoming Critical PHP Security Release]. news-web.php.net. [dostęp 2026-10-21]. (ang.).
- 1 2 3 Lawrence Abrams: PHP warns admins of two critical flaws, emergency patches coming tomorrow. BleepingComputer. [dostęp 2026-10-21]. (ang.).
- 1 2 Dan Goodin: PHP warns it plans to release 2 emergency patches imminently. Ars Technica, 2026-10-20. [dostęp 2026-10-21]. [zarchiwizowane z tego adresu (2026-10-21)]. (ang.).
- ↑ RCE via OOM corruption. 2026-10-21. [dostęp 2026-10-21]. (ang.).
- ↑ RCE via stale global state. 2026-10-21. [dostęp 2026-10-21]. (ang.).
- ↑ Tell HN: 2x PHP RCE CVEs with CVSS 10.0 Incoming | Hacker News. news.ycombinator.com. [dostęp 2026-10-22]. [zarchiwizowane z tego adresu (2026-10-21)]. (ang.).
- 1 2 3 John Hammond: Rapid Response: php2shell, Leaked Critical PHP Vulnerabilities (CVE-2026-109618 & CVE-2026-109619). Huntress, 2026-10-21. [dostęp 2026-10-21]. (ang.).
- 1 2 Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot | AWS Security Blog. aws.amazon.com, 2026-10-21. [dostęp 2026-10-22]. (ang.).
- ↑ Sergiu Gatlan: PHP ships emergency patches for critical PHP2Shell flaws. BleepingComputer, 2026-10-21. [dostęp 2026-10-21]. (ang.).
- ↑ Hold on to your butts: Web admins braced for emergency PHP updates to plug leaked exploits. PC Gamer, 2026-10-21. [dostęp 2026-10-21]. (ang.).
- ↑ Dane Knecht: Dane Knecht 🦭 (@dok2001) on X. X, 2026-10-21. [dostęp 2026-10-22]. (ang.).
- ↑ PHP RCE FAQ: PHP2Shell CVE-2026-109618 & CVE-2026-109619. watchTowr, 2026-10-20. [dostęp 2026-10-21]. (ang.).
- 1 2 3 4 Kevin Collier: Critical vulnerabilities in commonly used web code spark rush to update systems. NBC News, 2026-10-21. [dostęp 2026-10-21]. (ang.).
- ↑ NSA Advisory: PHP Updates. National Security Agency, 2026-10-21. [dostęp 2026-10-21]. [zarchiwizowane z tego adresu (2026-10-21)]. Cytat: If an immediate update is not feasible, it is recommended that organizations take the system offline until it can be fully mitigated. (ang.).
- ↑ Critical security issue affecting PHP. National Cyber Security Centre, 2026-10-21. [dostęp 2026-10-22]. (ang.).
- ↑ Josse Van Dessel: Major websites go offline as critical PHP vulnerability triggers security fears. The Brussels Times, 2026-10-21. [dostęp 2026-10-21]. (ang.).
- 1 2 3 4 Olivia Tauber: PHP vulnerability: Which websites and services are affected?. Mashable, 2026-10-21. [dostęp 2026-10-21]. (ang.).
- 1 2 著名ITサービス相次いで緊急メンテへ コドモン、シャドバ、BASE、さくらのレンタルサーバなど 「PHP」脆弱性に起因か. ITmedia, 2026-10-21. [dostęp 2026-10-21]. (jap.).
- ↑ Zacharias Szumer: Why are so many websites down and when will they return?. SBS News, 2026-10-22. [dostęp 2026-10-22]. (ang.).
- ↑ Lisa Eadicicco: Global websites shut down after AI found a critical flaw affecting 70% of the internet | CNN Business. CNN, 2026-10-21. [dostęp 2026-10-22]. (ang.).
- ↑ Josh Taylor: What is PHP, and how bad is the computer language flaw causing website shutdowns globally?. The Guardian, 2026-10-22. [dostęp 2026-10-22]. (ang.).