← Grįžti į blogą

PHP2Shell (CVE-2026-109618, CVE-2026-109619): kas pažeidžiama ir kaip apsisaugoti, kol atnaujinate PHP?

Spalio 21 d. PHP išleido skubias pataisas dviem kritinėms spragoms, kurios gavo PHP2Shell pavadinimą. Abi leidžia nuotoliniu būdu vykdyti kodą be jokio prisijungimo (RCE) ir paveikia beveik visas PHP versijas, kurios aptarnauja web užklausas, nuo 5.4 iki 8.5. Detalės nutekėjo dar prieš oficialų paskelbimą, o pirmieji atakų bandymai užfiksuoti keturiomis dienomis anksčiau nei pataisos.

Šiame straipsnyje: kas pažeidžiama, kaip greitai patikrinti savo serverius, ką nustatyti, jei atnaujinti šiandien negalite, ir ar jus apsaugo WAF.

1. Kas yra PHP2Shell?

Tai dvi atminties valdymo klaidos pačiame PHP, ne kuriame nors įskiepyje ar aplikacijoje [1][2]:

Svarbiausia: ataka vyksta dar prieš paleidžiant jūsų aplikacijos kodą. Todėl WordPress, Laravel ar kitų įskiepių atnaujinimas čia nepadeda, reikia atnaujinti patį PHP. Antroji spraga dar ir nutekina PHP proceso atmintį, kurioje gali būti slaptažodžių, sesijų žetonų ir API raktų.

Spragas surado ir pranešė Wiz, Calif.io, OpenAI ir Quarkslab tyrėjai [1][2].

2. Kaip viskas vyko?

• Rugpjūčio 19 d. – rasta pirmoji klaida, rugpjūčio 24 d. pranešta PHP.
• Spalio 17 d. – Amazon pastebi pirmus išnaudojimo bandymus savo spąstuose (honeypot), keturiomis dienomis prieš pataisas [15].
• Spalio 20 d. – detalės nutekėja socialiniuose tinkluose, PHP paskelbia išankstinį pranešimą, CERT-EU – įspėjimą.
• Spalio 21 d., 03:02 UTC – Cloudflare įjungia WAF taisykles visiems klientams, įskaitant nemokamą planą [3].
• Spalio 21 d., 14:00 UTC – PHP išleidžia pataisas. Tą pačią dieną spąstuose fiksuojamas abiejų spragų išnaudojimas.
• Spalio 23 d. – PHP paskelbia apie dar vieną susijusią spragą (CVE-2026-115560), kurios spalio 21 d. versijos nesutaiso. Pataisos jai dar nėra [16].

Qualys duomenimis, per pirmas 12 valandų buvo atnaujinta tik apie 199 tūkst. iš 156 mln. jų matomų PHP diegimų, o 71 % jų veikia su nebepalaikomomis PHP šakomis [4].

3. Ar mano svetainė pažeidžiama?

Jei svetainė veikia su PHP ir versija žemesnė nei nurodyta lentelėje – taip [1][2].

Pažeidžiami visi būdai, kuriais PHP aptarnauja web užklausas: Apache mod_php, PHP-FPM, php-cgi, LiteSpeed, FrankenPHP. Skubiausia – Apache mod_php: ten ataka paprasčiausia. Su PHP-FPM sėkmė priklauso nuo konfigūracijos, bet tai nėra priežastis laukti [5].

Kaip patikrinti:

php -v                       # CLI versija (gali skirtis nuo web!)
php-fpm -v                   # FPM versija

Patikimiausia – sukurti laikiną puslapį su phpinfo() arba žiūrėti X-Powered-By antraštę, nes CLI ir web gali naudoti skirtingus PHP. Linux platinimų (Debian, Ubuntu, RHEL) paketuose pataisa dažnai įdedama nekeičiant versijos numerio, tad tikrinkite savo platinimo saugumo pranešimą, ne tik numerį.

Jei svetainė pas hostingo tiekėją, paklauskite jo tiesiai: ar PHP atnaujintas į pataisytą versiją ir kada.

4. Ką daryti dabar?

1. Atnaujinti PHP

Tai vienintelis patikimas sprendimas. PHP komanda aiškiai sako, kad joks nustatymas spragų visiškai nepašalina [1][2]. Atnaujinę paleiskite iš naujo visus PHP procesus (FPM, Apache), kitaip seni procesai veiks su sena versija.

2. Jei atnaujinti šiandien negalite

PHP rekomenduoja šiuos laikinus nustatymus. Juos reikia nustatyti php.ini, FPM pool'e arba web serverio konfigūracijoje, ne per ini_set() ar .user.ini [1][2]:

; CVE-2026-109619: išjungti sesijos įkėlimo progresą
; (rekomenduojama palikti išjungtą ir po atnaujinimo, jei nenaudojate)
session.upload_progress.enabled = Off

; Tik PHP 8.5
fatal_error_backtraces = Off

; CVE-2026-109618: mažinti užklausų dydį
post_max_size = 8M            ; 32M, jei svetainėje yra failų įkėlimas
upload_max_filesize = 6M      ; mažiau nei post_max_size
expose_php = Off

Papildomai:

• web serveryje ar proxy ribokite užklausos dydį ir blokuokite multipart/form-data, jei svetainėje nėra failų įkėlimo;
• PHP-FPM: jei leidžia našumas, pm.max_requests = 1 (kiekviena užklausa naujame procese – antroji spraga nebeturi „kitos“ užklausos);
• atminties ribą nustatykite per konteinerio / cgroup ribą, ne per RLIMIT_AS;
• pašalinkite klaidas, kurias lankytojas gali sukelti (fatal errors, timeouts), ir .htaccess / php_value nustatymus, kurie generuoja įspėjimus;
• ko neįmanoma greitai atnaujinti – paslėpkite nuo interneto (VPN, IP apribojimas) arba izoliuokite.

memory_limit = -1 PHP taip pat mini kaip laikiną priemonę nuo pirmosios spragos, bet ji didina riziką, kad serveris užstrigs dėl atminties stygiaus, todėl naudokite tik kartu su cgroup riba.

3. Patikrinti, ar nebuvote atakuoti

Bandymai prasidėjo spalio 17 d., todėl logus peržiūrėkite nuo tos datos. Saugumo tyrėjų minimi požymiai [5][6]:

• multipart/form-data POST užklausos su lauku PHP_SESSION_UPLOAD_PROGRESS iš nepažįstamų adresų;
• labai ilgi ar neįprasti PHPSESSID slapukai;
• PHP klaidos apie atminties ribą užklausos pradžioje ir 500 atsakymų bangos;
• nauji ar pakeisti .php failai, nežinomi procesai, išeinantys ryšiai iš serverio.

Jei matote įtartinų požymių, vien atnaujinimo neužtenka: pakeiskite slaptažodžius ir API raktus, kurie galėjo būti PHP atmintyje, ir patikrinkite, ar serveryje neliko web shell'ų.

5. Ar WAF apsaugo?

Iš dalies – ir tai geras pavyzdys, kodėl WAF yra laikas, o ne sprendimas.

Ar pažeidžiamas pats F5 BIG-IP?

Taip. BIG-IP valdymo sąsaja (Configuration utility) ir APM naudoja PHP, todėl F5 paskelbė, kad pažeidžiami patys įrenginiai [7]:

Nepažeidžiami: BIG-IQ, F5OS, BIG-IP Next, NGINX, F5 Distributed Cloud.

Kol neatnaujinote, F5 rekomenduoja:

• sukurti /etc/php.ini.d/K000163821.ini su PHP rekomenduojamais nustatymais (memory_limit = -1, post_max_size = 8M, upload_max_filesize = 7M, session.upload_progress.enabled = 0) ir perkrauti httpd (APM – ir httpd_sam, tai gali nutraukti webtop sesijas). Nustatymai neišlieka atnaujinus TMOS, o HA grupėje juos reikia pakartoti kiekviename įrenginyje;
• uždaryti valdymo sąsają nuo nepatikimų tinklų: self IP adresams Port Lockdown nustatyti Allow None arba Allow Custom be 443 prievado, valdymo sąsają leisti tik iš patikimų adresų.

Ką papildomai nustatyti BIG-IP Advanced WAF / ASM?

Be parašų, F5 siūlo politikos nustatymus, kurie mažina atakos galimybes, bet, F5 žodžiais, nepakeičia PHP atnaujinimo [7]:

• jei aplikacijai nereikia failų įkėlimo, uždrausti multipart turinį (Header-Based Content Profiles → Disallow);
• riboti POST duomenų ir visos užklausos ilgį (F5 rekomenduoja iki 8 MB, nes numatytasis WAF buferis yra 10 MB);
• įjungti HTTP protokolo atitikties patikras: parametrų ir antraščių skaičiaus ribas, blogai suformuotų multipart užklausų blokavimą, kelių Content-Length antraščių ir chunked su Content-Length blokavimą;
• jei nenaudojamas sesijos įkėlimo progresas, blokuoti parametrą PHP_SESSION_UPLOAD_PROGRESS (arba pavadinimą iš session.upload_progress.name) su visas reikšmes atmetančia reguliariąja išraiška;
• politiką perjungti į Blocking, pašalinti staging išimtis ir užtikrinti, kad serverio negalima pasiekti aplenkiant BIG-IP.

Kodėl WAF neužtenka?

• Užpuolikai keičia užklausas, kad apeitų taisykles – Cloudflare tai jau mato ir taisykles nuolat atnaujina [3].
• WAF saugo tik tai, kas eina per jį. Jei serveris pasiekiamas ir tiesiai (tiesioginis IP, kitas domenas, vidinis tinklas), WAF nepadės.
• CVE-2026-115560 (spalio 23 d.) veikia net atnaujintame PHP 8.5.12, o pataisos dar nėra: PHP ją žada kitame įprastame leidime [16]. Pažeidžiamos tik aplikacijos, kurios konfigūracijoje naudoja php_binary arba php_serialize sesijų apdorojimą ir prieš session_start() per ini_set() perjungia jį į php [14][16]. Cloudflare esama taisyklė ją stabdo, jei nepakeistas numatytasis session.upload_progress.name [3]. Apsauga ta pati: session.upload_progress.enabled = Off.

6. Kodėl vien pataisų neužtenka?

PHP2Shell rodo tris dalykus, kurie kartosis su kitomis spragomis:

1. Išnaudojimas prasidėjo prieš pataisas. Nė vienas pataisų grafikas nuo to neapsaugo.
2. Net laiku atnaujinus, po dviejų dienų atsirado nauja susijusi spraga.
3. Daugumai organizacijų reikia dienų ar savaičių, kol atnaujinami visi serveriai.

Todėl saugumas turi laikytis ne ant vieno sluoksnio, o ant kelių, kurie vienas kitą dengia:

• WAF debesyje (pvz., Cloudflare) – greitas virtualus pataisymas ir DDoS sugėrimas;
• WAF prie aplikacijos (BIG-IP, Coraza) – taisyklės, pritaikytos būtent jūsų aplikacijai, ir apsauga, jei kas nors apeina debesį;
• išeinančio srauto ribojimas – net pavykus RCE, serveris negali atsisiųsti kenkėjiško kodo ar išnešti duomenų;
• PHP ir serverio sustiprinimas, segmentacija ir logų stebėsena.

Kaip tokią architektūrą sudėlioti praktiškai, su BIG-IP ir Coraza pavyzdžiais, aprašysime kitame straipsnyje. Daugiau apie „Cloudflare“ galimybes – straipsnyje „Cloudflare WAF: nemokamas planas, taisyklės ir kada jo neužtenka“.

Dažni klausimai

Ar WordPress įskiepių atnaujinimas apsaugo nuo PHP2Shell?

Ne. Spragos yra pačiame PHP, todėl reikia atnaujinti PHP versiją serveryje (arba paprašyti hostingo tiekėjo).

Ar „Cloudflare“ nemokamas planas apsaugo nuo PHP2Shell?

Cloudflare nuo spalio 21 d. blokuoja žinomus atakų variantus ir nemokamame plane [3]. Tai sumažina riziką, bet nepakeičia PHP atnaujinimo: užpuolikai keičia užklausas, o serveris gali būti pasiekiamas ir aplenkiant Cloudflare.

Ar pažeidžiamas PHP-FPM?

Taip, nors išnaudoti sudėtingiau nei Apache mod_php ir sėkmė priklauso nuo konfigūracijos. Atnaujinti reikia visais atvejais.

Kaip sužinoti, ar mano PHP jau pataisytas?

Patikrinkite web serverio naudojamą versiją (phpinfo()) ir palyginkite su lentele. Jei PHP iš Linux platinimo paketo, tikrinkite platinimo saugumo pranešimą – pataisa gali būti įdėta nekeičiant versijos numerio.

Ką daryti, jei naudoju PHP 7.4 ar senesnę?

7.4–8.1 šakoms yra tik pataisų kodas arba platinimo / LTS tiekėjų paketai, 7.3 ir senesnėms – nieko. Kol pereisite į palaikomą versiją, apribokite prieigą iš interneto ir taikykite laikinus nustatymus iš šio straipsnio.

Šaltiniai

1. PHP — GHSA-w8hw-w9fx-j79w (CVE-2026-109618)
2. PHP — GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
3. Cloudflare — Cloudflare deploys protections against php2shell vulnerability
4. Qualys — PHP2Shell: Find, Mitigate, and Patch Now
5. watchTowr — PHP2Shell FAQ
6. SOCRadar — PHP2Shell (CVE-2026-109618 & CVE-2026-109619)
7. F5 — K000163821: PHP vulnerabilities CVE-2026-109618 and CVE-2026-109619 (atnaujinta 2026-10-24)
8. F5 — K000163878: PHP vulnerability CVE-2026-115560
9. AWS — Using AWS WAF to apply mitigations for PHP2Shell
10. Imunify360 — What Imunify360 Blocks and What Needs the PHP Update
11. OWASP CRS — PR #4893 (php2shell PoC User-Agent)
12. OWASP CRS — PR #4902 (953130)
13. frehi.be — PHP2Shell: mitigating with CRS and AppArmor before the patch
14. Astra — CVE-2026-115560
15. AWS — Amazon threat intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot
16. PHP — php.net pranešimas apie CVE-2026-115560 (2026-10-23)