Īsi sakot: Pēc PHP2Shell vēl ziņojumi par PHP ir ticami, jo jau divas dienas pēc ielāpa nāca trešā norāde, pilns advisory vēl nav publicēts un distributīvi savas pakotnes piegādā pa posmiem. Kas tagad ierīko stabilu norisi novērošanai, vērtēšanai, atjaunināšanai un pārstartēšanai, uz nākamo jauno PHP drošības ievainojamību reaģē stundās, nevis dienās.
Ielāps nebija stāsta beigas
- gada 21. oktobrī PHP projekts aizvēra abas kritiskās ievainojamības CVE-2026-109618 un CVE-2026-109619 ar versijām 8.5.12, 8.4.27, 8.3.36 un 8.2.35. Daudzi atbildīgie pēc tam ielika ķeksīti. Divas dienas vēlāk, 23. oktobrī, tomēr sekoja vēl viena php.net norāde par CVE-2026-115560.
Šī trešā norāde skar tikai neparastu sesiju konfigurāciju. Taču tā rāda paraugu, ko pazīst no lieliem drošības gadījumiem: ja komponente pēkšņi nonāk uzmanības centrā, daudzi speciālisti vienlaikus skatās uzmanīgāk. Vai no tā rodas jaunas ievainojamības, šodien nezina neviens. Ticami gan, ka ziņu plūsma neapsīks.
Jums kā operatoram tas nozīmē: rēķinieties ar sekojošiem ziņojumiem, nevis ļaujiet katram sevi pārsteigt. Līdzšinējo notikumu gaitu apkopo mūsu PHP2Shell hronoloģija.
Kāpēc papildu ziņojumi ir ticami
Šis vērtējums balstās uz publiski zināmiem faktiem. Tā nav konkrētu ievainojamību prognoze.
- Advisory vēl nav publicēts. php.net CVE-2026-115560 izskata regulārajā laidienu ciklā un ir paziņojis, ka pilnu advisory publicēs ar nākamo laidienu. Līdz tam kā pagaidu risinājums darbojas
session.upload_progress.enabled=0. - Detaļas bija publiskas agri. Saskaņā ar vairākiem ziņojumiem detaļas kļuva zināmas pirms embargo beigām. Saskaņā ar ziņojumiem watchTowr pēc paša teiktā ir atveidojis CVE-2026-109618. Šādi darbi bieži noved pie turpmākiem jautājumiem par kaimiņu koda vietām.
- Distributīvi piegādā pa posmiem. Ubuntu 21. oktobrī ar USN-8948-1 apgādāja aktuālos laidienus un ar USN-8948-2 labojumus versijām no 14.04 līdz 20.04 papildus nodrošināja caur Ubuntu Pro. Red Hat savā biļetenā rakstīja, ka daži atjauninājumi ir pieejami, citi tiek izstrādāti.
- Ir skarta izstrādes versija. Saskaņā ar php.net labojumus satur arī PHP 8.6.0 RC4. Kas testē pirmslaidiena versijas, tam jāatjaunina arī šīs vides.
- Vecās versijas paliek atvērtas. PHP 8.1 un vecākām ir tikai minimāli pirmkoda backport labojumi. Katrs pakalpojuma sniedzējs, kas šādas versijas piegādā, par savu stāvokli ziņo patstāvīgi un savos laikos.
Kā jauna PHP drošības ievainojamība jūs sasniedz
Ziņojumi nāk dažādos ceļos un ar dažādu uzticamību. Secība gandrīz vienmēr ir tāda pati: vispirms PHP projekts, tad distributīvi un hostinga sniedzēji, pēc tam iestādes un mediji.
| Avots | Ko tur uzzināt | Cik uzticams |
|---|---|---|
| php.net | Skartie atzari, labotās versijas, pagaidu pasākumi | Primārais avots |
| Ubuntu, Debian, Red Hat | Pakotņu stāvoklis katram laidienam, piegādes laiks | Primārais avots jūsu sistēmai |
| Hostinga sniedzēji un paneļu piegādātāji | Paša PHP būvējumu stāvoklis | Saistošs tikai rakstiski |
| BSI, CERT-Bund (Vācijas valdības CERT) | Situācijas novērtējums, brīdinājuma līmenis, ieteikumi | Iestādes vērtējums |
| Speciālā prese un drošības uzņēmumi | Uzbrukumu novērojumi, skaitļi, fona informācija | Noderīgi, atzīmēt kā ziņojumu |
Svarīga ir atšķirība starp “ir ielāps” un “manai sistēmai ir ielāps”. Pirmais apgalvojums ir php.net. Otrais jums katram serverim jāapliecina pašam.
Abonējiet php.net un sava distributīva ziņojumus ar RSS vai e-pasta sarakstu un novirziet tos kopīgā pastkastē vai kanālā, ko lasa vairāk nekā viena persona. Atvaļinājums un slimība ir biežākie vēlinātu atjauninājumu iemesli.
Ko sagatavot pirms nākamā ziņojuma
PHP2Shell pieredze rāda, kur zūd laiks: serveru meklēšanā, atbildību noskaidrošanā un aizmirstā pārstartēšanā. Visu to var paveikt iepriekš.
- Inventārs: Saraksts ar visiem serveriem un vietnēm ar PHP atzaru, darbības režīmu (PHP-FPM, mod_php, LiteSpeed) un pakotņu avotu. Bez šī saraksta katrs ziņojums sākas ar meklēšanu. Kā tas izdodas, apraksta raksts Visu vietņu un serveru inventārs.
- Atbildība: Katrai sistēmai ir noteikts, kurš ielāpo, kurš pārstartē un kurš apstiprina. Hostinga sniedzēju un aģentūru gadījumā tas pieder līgumā.
- Vērtēšanas režģis: Pirmajam vērtējumam pietiek ar trim jautājumiem. Vai mūsu atzars ir skarts? Vai mēs izmantojam skarto funkciju vai darbības režīmu? Vai ir ielāps vai tikai pagaidu pasākumi?
- Testa ceļš: Staging vide, kurā PHP atjauninājumu var pārbaudīt īsā laikā.
- Apliecinājums: Noteikts formāts, kurā fiksē pakotņu stāvokli, changelog atbilsmi un pārstartēšanas laiku.
Kā šāda norise darbojas kā rutīna, nevis ugunsdzēsēju izbraukums, lasāms sadaļā Ielāpu pārvaldība kā process. Fonu par to, kā PHP projekts izturas pret ievainojamībām, sniedz lapa Kā PHP projekts apstrādā drošības ievainojamības.
Paša konfigurācija kā agrīnās brīdināšanas sistēma
Daļa sekojošo ziņojumu skar tikai noteiktus iestatījumus. CVE-2026-115560 ir piemērs: php.net kā priekšnoteikumu min to, ka lietojumprogramma izpildes laikā pārslēdz sesiju serializatoru, kamēr augšupielādes progress ir aktīvs. Lietojumprogrammas, kas to nekad nedara, saskaņā ar php.net nav skartas.
Kas zina savu spēkā esošo konfigurāciju, tas šādus ziņojumus var ātrāk klasificēt. Tāpēc katram atzaram fiksējiet, kuras vērtības ir iestatītas servera pusē un kuras lietojumprogrammas drīkst tās pārrakstīt. Palīdz jau vienkāršs aktīvo iestatījumu salīdzinājums:
# Komandrindas spēkā esošās vērtības (tīmekļa konfigurācija var atšķirties)
php -i | grep -E "session.upload_progress.enabled|session.serialize_handler|memory_limit|post_max_size"
# FPM pūlos iestatītās vērtības (ceļš atkarībā no distributīva atšķiras)
grep -RhE "php_(admin_)?value" /etc/php/*/fpm/pool.d/ 2>/dev/null
Komandrinda ne vienmēr rāda to, kas ir spēkā tīmekļa kontekstā. Skaidrību dod pūla vai VirtualHost konfigurācija un, īslaicīgi un aizsargāti, phpinfo lapa.
Vēl viena priekšrocība: kas zina, kuras pagaidu vērtības vēl ir iestatītas kopš PHP2Shell nedēļas, tās pēc nākamā regulārā laidiena var apzināti pārbaudīt. Daži iestatījumi, piemēram, izslēgts augšupielādes progress, var palikt pastāvīgi saprātīgi. Citus, piemēram, ļoti šaurus augšupielādes ierobežojumus, pēc saskaņošanas ar nozaru nodaļām vajadzētu atkal pielāgot faktiskajai vajadzībai.
Kā PHP SOS palīdz konkrēti?
- Mēs sekojam php.net, distributīvu un BSI ziņojumiem un novērtējam jaunās norādes jūsu konkrētajām sistēmām.
- Mēs kopā ar jums veidojam visu PHP instalāciju inventāru un nosakām atbildības katram serverim.
- Drošības apkopes līguma ietvaros mēs ieviešam atjauninājumus, pārstartējam visus procesus un dokumentējam stāvokli.
- Ziņojumu gadījumā bez ielāpa mēs ieviešam pagaidu pasākumus, kurus nevar pārrakstīt, un pārbaudām tos.
Biežāk uzdotie jautājumi
Vai pēc PHP2Shell jau ir jauna PHP drošības ievainojamība?
2026. gada 23. oktobrī php.net publicēja norādi par CVE-2026-115560. Koda izpilde pēc tās ir iespējama tikai neparastas sesiju konfigurācijas gadījumā. Pilnam advisory jāseko ar nākamo regulāro laidienu.
Vai pēc katra jauna ziņojuma man jārīkojas nekavējoties?
Ne katrs ziņojums prasa vienādu steigu. Izšķirošs ir smaguma pakāpe, jūsu konfigurācijas skartība un tas, vai ielāps ir pieejams. Noteikta norise palīdz to novērtēt minūtēs, nevis dienās.
Kur vispirms uzzināt par jaunām PHP ievainojamībām?
Primārie avoti ir php.net paziņojumi un jūsu distributīva drošības norādes, piemēram, Ubuntu Security Notices, Debian Security Tracker vai Red Hat. BSI (Vācijas Federālais informācijas drošības birojs) informē ar brīdinājuma ziņojumiem. Mediju ziņojumi ir noderīgi, bet bieži vēlāki un mazāk precīzi.
Kāpēc distributīvi dažkārt ziņo dienām vēlāk nekā php.net?
Distributīviem labojums jāpārņem savās pakotnēs, jāpārbūvē un jātestē. Vecākiem laidieniem tas var aizņemt ilgāk vai notikt tikai ar papildu piedāvājumiem. Tāpēc vērts abus avotus sekot atsevišķi.