Kritiskas PHP ievainojamības (CVE-2026-109618 un CVE-2026-109619): kas noticis un kas jādara

2026. gada 21. oktobrī PHP projekts izlaida labojumus divām kritiskām kļūdām, un CERT-EU tajā pašā dienā publicēja drošības paziņojumu 2026-018. Abām kļūdām vērtējums ir 9,2, un abas tiek raksturotas kā attālināta koda izpilde bez autentifikācijas. Ja izmantojat WordPress vietni, interneta veikalu vai citu PHP lietojumprogrammu, tas skar arī Jūs, un risinājums ir atjauninājums, nevis iestatījums. Šajā rakstā skaidrojam, kas ir zināms, kā uzbrukums nonāk iekšā un kas jādara. Stāvoklis: 2026. gada 22. oktobris, pamatojoties uz CERT-EU paziņojuma versiju 1.1.

Kas noticis

PHP 20. oktobrī paziņoja par drošības izlaidumu un labojumus publicēja 21. oktobrī plkst. 13:30 UTC. CERT-EU savu paziņojumu nosauca „Critical Vulnerabilities in PHP“ un min divus CVE: CVE-2026-109618 un CVE-2026-109619, katram vērtējums 9,2. CERT-EU raksta arī, ka tehniskās detaļas tagad tiek apspriestas publiski un sāk izplatīties pirmais koncepcijas pierādījuma kods (angļu val. proof of concept). Paziņojums neapstiprina uzbrukumus reālā vidē, taču norāda, ka tādēļ ir ticamāk, ka uzbrucēji šīs kļūdas jau izmanto. Uztveriet to kā steidzamu.

Kam tas attiecas

Apdraudēts ir katrs PHP laidiens, kas ir vecāks par labotu versiju atbalstītā atzarā, un visi atzari, kuriem atbalsts beidzies.

CERT-EU min PHP-FPM, Apache ar mod_php, php-cgi, FrankenPHP un LiteSpeed. Pēc PHP komandas teiktā, vislielākais risks ir mod_php. Apdraudēti var būt arī produkti, kas PHP iebūvē sevī; CERT-EU norāda uz Nīderlandes NCSC sarakstu šī raksta beigās. Der katra instalācija, kas apkalpo tīmekļa pieprasījumus, neatkarīgi no tā, vai tajā ir augšupielādes veidlapa.

Kā uzbrucējs sasniedz pirmo kļūdu

Nevienam nav jāpiesakās. Pēc CERT-EU datiem, demonstrēts ekspluatācijas piemērs rāda, ka viens neautentificēts pieprasījums var izraisīt uzbrukumu pirms jebkāda lietojumprogrammas koda izpildes. Tieši to vairums nepamana: nav nozīmes, vai Jūsu WordPress ir aktuāls, vai Jūsu spraudņi ir salaboti, vai Jūsu kontaktu veidlapa ir aizsargāta. Pieprasījums vispirms nonāk pie PHP dzinēja.

Pirmā kļūda, CVE-2026-109618, darbojas šādi:

1. Pieprasījums ierodas adresē, ko apkalpo PHP. Nekādas pieteikšanās, nekāda konta.
2. PHP sāk lasīt pieprasījuma pamatdaļu. CERT-EU kā piemēru min uz veidlapām balstītu failu augšupielādes apstrādi.
3. PHP savu memory_limit nodrošina ar longjmp(). Kad robeža tiek pārsniegta, tas izlec no tā, ko darīja, un beidz pieprasījumu.
4. Ja tas notiek pieprasījuma iekšējo datu izveides vidū, šie dati paliek tikai daļēji izveidoti.
5. Pēc tam veiktā tīrīšana nederīgus datus uzskata par derīgiem un atbrīvo atmiņu, kas nekad nav bijusi inicializēta. Šajā atmiņā vēl var atrasties dati no iepriekšējām piešķirēm, kurus kontrolēja uzbrucējs.
6. No šejienes paziņojumā tiek aprakstīta attālināta koda izpilde serverī.

Mēs apzināti neaprakstām, kā uzbrucējs vada pēdējo soli. Pietiek zināt, ka ieejas punkts nav Jūsu lietojumprogramma, un tāpēc nekas Jūsu lietojumprogrammas iekšienē to nevar apturēt.

Otrā kļūda: stāvoklis, kas pārdzīvo savu atmiņu

CVE-2026-109619 ir cits mehānisms ar to pašu rezultātu. PHP katram pieprasījumam glabā iekšēju stāvokli. Pēc dažām kļūmēm, piemēram, letālas kļūdas, šis stāvoklis var saglabāties, kaut gan tam apakšā esošā atmiņa jau ir atbrīvota. Nākamais tā paša darba procesa pieprasījums var izmantot šo novecojušo stāvokli, pirms tas ir parastā kārtā atiestatīts. Uzbrucējam vajadzīgi divi pieprasījumi, kas nonāk vienā darba procesā; CERT-EU rezultātu vērtē tāpat kā pirmo kļūdu: attālināta koda izpilde.

Kas jādara šodien

1. Noskaidrojiet, kāda PHP versija patiesībā apkalpo Jūsu vietni. php -v komandrindā rāda komandrindas versiju, kas var atšķirties no tās, ko izmanto Jūsu tīmekļa serveris. Pārbaudiet php-fpm -v, sava hostinga vadības paneli vai lapu, kas izsauc phpinfo(). Koplietošanas hostingā vaicājiet pakalpojuma sniedzējam.
2. Atjauniniet uz labotu versiju: 8.5.12, 8.4.27, 8.3.36 vai 8.2.35. Distributīvi labojumus bieži portē atpakaļ, nemainot versijas numuru, tāpēc sava piegādātāja drošības paziņojumā meklējiet CVE numurus. Konteineros pārbūvējiet no atjaunināta bāzes attēla. PHP komanda norāda, ka rpms.remirepo.net izlaiduma dienā atjauninājumu nebija, un iesaka distributīva pakotnes vai būvēšanu no pirmkoda.
3. Pārstartējiet visus PHP darba procesus. Atjauninājums diskā jau darbojošos procesus nemaina. Pārstartējiet PHP-FPM vai tīmekļa serveri, pēc tam vēlreiz pārbaudiet darbojošos versiju.
4. Ja šodien atjaunināt nevarat, izolējiet serveri no publiskajiem tīkliem, līdz labojums ir uzstādīts un pārbaudīts. CERT-EU ir skaidrs, ka šīs kļūdas pilnībā novērš tikai atjauninājums.
5. Ja izmantojat PHP 8.1 vai vecāku versiju, lūdziet piegādātājam atpakaļportējumu vai pārejiet uz atbalstītu atzaru. Šīs versijas regulārus atjauninājumus nesaņem.

Apiešanas veidi, kas samazina risku, bet to nenovērš

CERT-EU uzskaita pasākumus, kas uzbrukumu apgrūtina. Tas skaidri norāda, ka tie instalāciju nepadara drošu. Izmantojiet tos, gatavojoties atjauninājumam, nevis tā vietā.

• Pret CVE-2026-109618: iestatiet memory_limit=-1 tā, lai lietojumprogrammas to nevarētu pārrakstīt, piemēram, ar php_admin_value FPM kopā, un pārbaudiet, ka neviena kopa, direktorija vai lietojumprogrammas ieraksts atkal neiestata galīgu robežu. Iestatiet zemu post_max_size (8M bez augšupielādēm, 32M ar augšupielādēm) un turiet upload_max_filesize zem tā. Ierobežojiet pieprasījuma lielumu, lauku skaitu, daudzdaļu pieprasījuma daļu skaitu, galvņu skaitu un ligzdošanas dziļumu tīmekļa serverī vai starpniekserverī. Konteinera vai cgroup atmiņas ierobežojumu izmantojiet kā pieejamības robežu, bet ne RLIMIT_AS vai RLIMIT_DATA, kas var izraisīt ievainojamo atmiņas piešķiršanas kļūmi.
• Pret CVE-2026-109619: iestatiet session.upload_progress.enabled=0 failā php.ini, FPM kopā vai servera konfigurācijā, kas darbojas pirms pieprasījuma apstrādes (nevis ar ini_set() vai .user.ini), un pārstartējiet visus darba procesus. PHP 8.5 papildus iestatiet fatal_error_backtraces=0. Noņemiet nederīgus vai novecojušus katra pieprasījuma iestatījumus, kas izvada diagnostiku pirms inicializācijas, un labojiet letālas kļūdas un izpildes noildzes, ko uzbrucējs var sasniegt.

Ko SilentShield šeit var un ko nevar

Tā nav botu problēma, un mēs to labāk sakām skaidri, nekā ļaujam produkta lapai to ieskaidrot. Uzbrukums trāpa PHP dzinējam, pirms pieprasījumu ierauga kaut kas no mūsu puses vai jebkāds CAPTCHA, spraudnis vai ugunsmūra noteikums Jūsu lietojumprogrammas iekšienē. Veidlapas aizsardzība pret botiem to neapturēs, un nevienam nevajadzētu Jums apgalvot pretējo. Vienīgais pilnīgais risinājums ir PHP atjauninājums.

SilentShield API un vadības panelis nav rakstīti PHP. WordPress spraudnis un PHP SDK darbojas Jūsu pašu PHP, tāpēc to gadījumā atjauninājums jāveic Jūsu serverī. Kad būsiet atjauninājuši, ierastā aizsardzība pret botiem un veidlapu mēstulēm ir tikpat noderīga kā agrāk; tā vienkārši nekad nebija atbilde uz šo problēmu.

Avoti

• CERT-EU drošības paziņojums 2026-018: Critical Vulnerabilities in PHP
• PHP paziņojums, 2026. gada 20. oktobris
• GHSA-w8hw-w9fx-j79w (CVE-2026-109618)
• GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
• NCSC-NL php2shell: produkti, kas iebūvē PHP