Īsi: pagaidu risinājums PHP ievainojamībai PHP2Shell var samazināt risku, bet atjauninājumu neaizstāj. php.net šim nolūkam min stingras atmiņas un augšupielādes robežas, session upload progress izslēgšanu un PHP 8.5 fatal_error_backtraces=0. Ja arī tas īsā laikā nav iespējams, BSI iesaka tīmekļa serveri uz laiku atvienot no tīkla.
Ko pagaidu risinājums var paveikt un ko ne
php.net pagaidu pasākumiem jāapgrūtina apstākļi, kādos ievainojamības CVE-2026-109618 un CVE-2026-109619 ir izmantojamas. Tie tieši ir nav pilnīga aizsardzība. Ievainojamības ir novērstas tikai PHP 8.5.12, 8.4.27, 8.3.36 un 8.2.35 vai jūsu sniedzēja apstiprinātā backport.
Pasākumi ir lietderīgi, ja atjauninājums konkrēta iemesla dēļ vēl nav iespējams: apkopes logs vēl nav pienācis, lietojumprogramma vispirms jātestē, vai arī darbinat PHP 8.1 vai vecāku, kam oficiāla atjauninājuma vairs nav. Tad tie ir tilts, nevis mērķis.
Tāpēc kopā ar pagaidu risinājumu plānojiet arī atjauninājumu: kas to īsteno, kurā apkopes logā un kas pēc tam pārbauda, ka visi darbprocesi ir pārstartēti? Pāreja bez beigu datuma draud kļūt par pastāvīgu stāvokli.
1. variants: serveri uz laiku atvienot no tīkla
BSI ir izsludinājis 3. brīdinājuma līmeni (oranžs) un iesaka skartos tīmekļa serverus uz laiku atvienot no tīkla, ja atjauninājums nav iespējams nekavējoties. Daži sniedzēji to ir izdarījuši piesardzības nolūkos; tas nenozīmē, ka šīs vietnes ir uzlauztas.
Daudziem uzņēmumiem veikala vai portāla pārtraukums ir dārgs. Lietderīgs var būt izvērtējums: piekļuve tikai caur VPN vai atļautām IP adresēm, statiska apkopes lapa PHP lietojumprogrammas vietā vai atsevišķu, nevajadzīgu vietņu izslēgšana serverī. Jo mazāk PHP ir sasniedzams no ārpuses, jo mazāka uzbrukuma virsma.
Svarīgi lēmumu pieņemt apzināti un to fiksēt: kurš un kad ir izlēmis serveri atstāt tiešsaistē un ar kādiem aizsardzības pasākumiem? Tas vēlāk palīdz attiecībās ar apdrošinātāju, datu aizsardzību un vadību.
php.net pagaidu pasākumi
| Pasākums | Vērtība | Piezīme |
|---|---|---|
memory_limit |
-1, nepārrakstāms |
atmiņas ierobežojumu tad iestatīt ar konteineru vai cgroup |
post_max_size |
8M bez augšupielādēm, 32M ar augšupielādēm |
upload_max_filesize zemāk |
| Atmiņas ierobežojums | ar konteineru/cgroup | nevis ar RLIMIT_AS vai RLIMIT_DATA |
session.upload_progress.enabled |
0 |
php.ini, pūlā vai servera konfigurācijā, nevis ar ini_set() vai .user.ini |
fatal_error_backtraces |
0 |
tikai PHP 8.5 |
Iestatījums session.upload_progress.enabled=0 ir arī pretlīdzeklis 23. oktobrī paziņotajai ievainojamībai CVE-2026-115560.
Pagaidu risinājuma PHP ievainojamībai pareiza iestatīšana
Izšķirošā ir vieta. Vērtībām jābūt iestatītām tā, lai lietojumprogramma tās nevarētu pārrakstīt. Ceļi un pakalpojumu nosaukumi atšķiras pa distributīviem; piemēri pieņem PHP 8.3.
PHP-FPM, pūlā (piem., /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
; tikai PHP 8.5:
; php_admin_flag[fatal_error_backtraces] = off
Apache ar mod_php, servera konfigurācijā vai 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
Atmiņas ierobežojums ar cgroup, šeit ar systemd FPM pakalpojumam. Vērtību pielāgojiet savam serverim:
# sudo systemctl edit php8.3-fpm
[Service]
MemoryMax=2G
Pēc tam pārstartējiet visus darbprocesus, citādi nekas no tā nedarbojas: systemctl restart php8.3-fpm vai mod_php gadījumā Apache. Kā pārbaudīt, ka vecs process vairs nedarbojas, rakstīts lapā PHP-FPM un visu darbprocesu pārstartēšana. Vispārīgu konfigurācijas nostiprināšanu apraksta php.ini droša konfigurēšana.
Pēc pārslēgšanas pārbaudiet augšupielādes un lielas veidlapas. Pārāk šaurs post_max_size var bloķēt pasūtījumus, pieteikuma veidlapas vai mediju augšupielādes. Tas ir viens no iemesliem, kāpēc atjauninājumu nevajadzētu atlikt ilgi.
Papildu aizsardzības slāņi
Web Application Firewall vai virtuālā ielāpošana var palīdzēt kā papildu slānis. Cloudflare ir ieviesis aizsardzības noteikumus, taču pats brīdina, ka noteikumi, kas balstīti tikai uz pieprasījuma datiem, nepietiek. WAF tāpēc ir papildinājums, nevis aizstājējs. Vairāk lasiet sadaļā WAF un virtuālā ielāpošana.
Saglabājiet arī servera žurnālus no 20. oktobra. Saskaņā ar plašsaziņas līdzekļu ziņojumiem pirmais uzbrukuma mēģinājums tika novērots jau 17. oktobrī; žurnāli ir pamats, ja vēlāk jānoskaidro, vai pirms ielāpa kaut kas ir noticis.
Kā PHP SOS palīdz konkrēti?
- Noskaidrot situāciju: Mēs pārbaudām, vai atjauninājums ir iespējams īsā laikā vai vajadzīga pāreja, un apspriežam ar jums variantu daļu serveru atvienot no tīkla.
- Ieviest pasākumus: Mēs ierakstām php.net vērtības pareizajā vietā, iestatām cgroup robežu un pārstartējam visus darbprocesus.
- Pārbaudīt funkcijas: Veidlapas, augšupielādes un pasūtījumu procesus pārbaudām pēc pārslēgšanas.
- Novest līdz ielāpam: Ar PHP ielāpu pakalpojumu plānojam atjauninājumu un pēc tam kontrolēti atceļam pārejas vērtības, kur tās traucē.
Biežāk uzdotie jautājumi
Vai pagaidu risinājums pilnībā aizsargā pret PHP2Shell?
Nē. php.net pasākumus tieši dēvē par pāreju, nevis pilnīgu aizsardzību. Tie samazina risku, līdz ir instalēts atjauninājums. BSI iesaka serverus bez ielāpa uz laiku atvienot no tīkla.
Vai iestatījumus varu iestatīt ar .htaccess vai .user.ini?
Attiecībā uz session.upload_progress.enabled php.net ini_set() un .user.ini tieši izslēdz. Arī memory_limit gadījumā spēkā ir: vērtībai jābūt iestatītai tā, lai lietojumprogramma to nevarētu pārrakstīt. Tas izdodas php.ini, FPM pūlā ar php_admin_value vai Apache servera konfigurācijā.
Vai Web Application Firewall kā pagaidu risinājums pietiek?
Kā papildu slānis tā var palīdzēt. Cloudflare ir ieviesis aizsardzības noteikumus, taču pats norāda, ka noteikumi, kas balstīti tikai uz pieprasījuma datiem, nepietiek. WAF neaizstāj ne atjauninājumu, ne pagaidu pasākumus serverī.
Ko darīt, ja man ir tikai koplietošanas hostings?
Tad php.ini un pārstartēšana ir hostinga sniedzēja pusē. Jautājiet konkrēti, vai atjauninājums ir instalēts vai pagaidu pasākumi iestatīti un vai visi PHP procesi ir pārstartēti.