Trumpai: Laikinas PHP2Shell sprendimas (workaround) gali sumažinti riziką, bet atnaujinimo nepakeičia. php.net nurodo fiksuotas atminties ir įkėlimo ribas, sesijos įkėlimo eigos išjungimą, o PHP 8.5 fatal_error_backtraces=0. Jei ir to trumpam laikui padaryti neįmanoma, BSI rekomenduoja žiniatinklio serverį laikinai atjungti nuo tinklo.
Ką laikinas sprendimas gali atlikti ir ko ne
php.net pereinamosios priemonės turi apsunkinti sąlygas, kuriomis spragos CVE-2026-109618 ir CVE-2026-109619 išnaudojamos. Jos aiškiai nėra visiška apsauga. Spragos ištaisytos tik PHP 8.5.12, 8.4.27, 8.3.36 ir 8.2.35 versijose arba jūsų teikėjo patvirtintame atgaliniame perkėlime (backport).
Priemonės prasmingos, kai atnaujinimas dėl konkrečios priežasties dar neįmanomas: dar laukiamas priežiūros langas, programą pirmiausia reikia išbandyti arba eksploatuojate PHP 8.1 ar senesnę, kuriai oficialaus atnaujinimo nebėra. Tuomet jos yra tiltas, o ne tikslas.
Todėl kartu su laikinu sprendimu planuokite ir atnaujinimą: kas jį įgyvendins, kokiame priežiūros lange ir kas po to patikrins, kad visi darbiniai procesai (worker) paleisti iš naujo? Pereinamasis laikotarpis be pabaigos datos rizikuoja tapti nuolatine būsena.
1 variantas: serverį laikinai atjungti nuo tinklo
BSI paskelbė 3 įspėjimo lygį (oranžinis) ir rekomenduoja paveiktus žiniatinklio serverius laikinai atjungti nuo tinklo, jei atnaujinti iš karto neįmanoma. Kai kurie teikėjai tai padarė iš atsargumo; tai nereiškia, kad tos svetainės buvo nulaužtos.
Daugeliui įmonių parduotuvės ar portalo išjungimas brangus. Gali būti prasminga svarstyti: prieiga tik per VPN ar patvirtintus IP adresus, statinis priežiūros puslapis vietoj PHP programos arba pavienių, nereikalingų serverio svetainių išjungimas. Kuo mažiau PHP pasiekiama iš išorės, tuo mažesnis atakos paviršius.
Svarbu sprendimą priimti sąmoningai ir jį užfiksuoti: kas ir kada nusprendė palikti serverį prijungtą ir su kokiomis apsaugos priemonėmis? Tai vėliau padeda kalbantis su draudiku, duomenų apsauga ir vadovybe.
php.net pereinamosios priemonės
| Priemonė | Reikšmė | Pastaba |
|---|---|---|
memory_limit |
-1, neperrašomai |
atminties ribą tada nustatyti per konteinerį ar cgroup |
post_max_size |
8M be įkėlimų, 32M su įkėlimais |
upload_max_filesize žemiau |
| Atminties riba | per konteinerį/cgroup | ne per RLIMIT_AS ar RLIMIT_DATA |
session.upload_progress.enabled |
0 |
php.ini, baseine ar serverio konfigūracijoje, ne per ini_set() ar .user.ini |
fatal_error_backtraces |
0 |
tik PHP 8.5 |
Nustatymas session.upload_progress.enabled=0 kartu yra priemonė nuo spalio 23 d. pranešytos spragos CVE-2026-115560.
PHP saugumo spragos laikinas sprendimas: teisingas nustatymas
Lemia vieta. Reikšmės turi būti nustatytos taip, kad programa jų negalėtų perrašyti. Keliai ir tarnybų pavadinimai skiriasi pagal distribuciją; pavyzdžiai remiasi PHP 8.3.
PHP-FPM, baseine (pvz., /etc/php/8.3/fpm/pool.d/www.conf):
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M
php_admin_value[upload_max_filesize] = 6M
php_admin_flag[session.upload_progress.enabled] = off
; tik PHP 8.5:
; php_admin_flag[fatal_error_backtraces] = off
Apache su mod_php, serverio konfigūracijoje ar VirtualHost:
php_admin_value memory_limit -1
php_admin_value post_max_size 32M
php_admin_value upload_max_filesize 24M
php_admin_flag session.upload_progress.enabled off
Atminties riba per cgroup, čia per systemd FPM tarnybai. Reikšmę pritaikykite savo serveriui:
# sudo systemctl edit php8.3-fpm
[Service]
MemoryMax=2G
Po to paleiskite iš naujo visus darbinius procesus, kitaip niekas iš to neveiks: systemctl restart php8.3-fpm arba esant mod_php Apache. Kaip patikrinti, kad nebeveikia senas procesas, aprašyta puslapyje PHP-FPM ir visų darbinių procesų paleidimas iš naujo. Bendrą konfigūracijos sustiprinimą aprašo Saugus php.ini konfigūravimas.
Po perjungimo išbandykite įkėlimus ir dideles formas. Per mažas post_max_size gali užblokuoti užsakymus, paraiškų formas ar medijos įkėlimus. Tai viena iš priežasčių neatidėlioti atnaujinimo ilgam.
Papildomi apsaugos sluoksniai
Žiniatinklio programų ugniasienė (WAF) ar virtualus pataisymas gali padėti kaip papildomas sluoksnis. Cloudflare išleido apsaugos taisykles, bet pats perspėja, kad vien taisyklių pagal užklausos duomenis nepakanka. Todėl WAF yra papildymas, o ne pakaitalas. Daugiau puslapyje WAF ir virtualus pataisymas.
Be to, išsaugokite serverio žurnalus nuo spalio 20 d. Pagal žiniasklaidos pranešimus pirmas atakos bandymas buvo pastebėtas jau spalio 17 d.; žurnalai yra pagrindas, jei vėliau reikės išsiaiškinti, ar prieš pataisą kas nors įvyko.
Kaip PHP SOS padeda konkrečiai?
- Išsiaiškinti padėtį: Tikriname, ar atnaujinimas trumpam laikui įmanomas, ar reikalingas pereinamasis laikotarpis, ir aptariame su jumis galimybę dalį atjungti nuo tinklo.
- Nustatyti priemones: php.net reikšmes įrašome tinkamoje vietoje, nustatome cgroup ribą ir paleidžiame iš naujo visus darbinius procesus.
- Išbandyti funkcijas: Formas, įkėlimus ir užsakymų procesus po perjungimo tikriname.
- Nuvesti iki pataisos: Per PHP pataisų paslaugą suplanuojame atnaujinimą ir po to kontroliuojamai atšaukiame pereinamąsias reikšmes, kur jos trukdo.
Dažni klausimai
Ar laikinas sprendimas visiškai saugo nuo PHP2Shell?
Ne. php.net šias priemones aiškiai vadina pereinamosiomis, o ne visiška apsauga. Jos mažina riziką, kol įdiegiamas atnaujinimas. BSI (Vokietijos federalinė informacijos saugumo tarnyba) rekomenduoja serverius be pataisos laikinai atjungti nuo tinklo.
Ar nustatymus galiu nustatyti per .htaccess ar .user.ini?
Dėl session.upload_progress.enabled php.net aiškiai atmeta ini_set() ir .user.ini. Ir dėl memory_limit galioja: reikšmė turi būti nustatyta taip, kad programa jos negalėtų perrašyti. Tai pavyksta php.ini, FPM baseine su php_admin_value arba Apache serverio konfigūracijoje.
Ar kaip laikinam sprendimui pakanka žiniatinklio programų ugniasienės (WAF)?
Kaip papildomas sluoksnis ji gali padėti. Cloudflare išleido apsaugos taisykles, bet pats nurodo, kad vien taisyklių pagal užklausos duomenis nepakanka. WAF nepakeičia nei atnaujinimo, nei pereinamųjų priemonių serveryje.
Ką daryti, jei turiu tik bendrą talpinimą (shared hosting)?
Tuomet php.ini ir paleidimas iš naujo yra talpintojo rankose. Paklauskite konkrečiai, ar atnaujinimas įdiegtas ar pereinamosios priemonės nustatytos ir ar visi PHP procesai paleisti iš naujo.