Kritiskas PHP ievainojamības – atjauniniet tagad (CVE-2026-109618 un CVE-2026-109619)

1. oktobrī PHP projekts paziņoja par drošības izlaidumu divām kritiskām ievainojamībām. 21. oktobrī plkst. 13.30 UTC labojumi tika publicēti. Abas ievainojamības ļauj veikt neautentificētu attālinātu koda izpildi ar CVSS 9,2, un publisks proof-of-concept kods jau cirkulē.

Šī nav ievainojamība, ko plānojat nākamajā apkopes logā. Šī ir ievainojamība, ko novēršat šodien.

Īsumā

• Atjauniniet uz PHP 8.5.12, 8.4.27, 8.3.36 vai 8.2.35.
• Ietekmēts ir viss PHP, kas apstrādā tīmekļa pieprasījumus – PHP-FPM, mod_php, php-cgi, FrankenPHP un LiteSpeed.
• Var pietikt ar vienu neautentificētu pieprasījumu, un tas var iedarboties vēl pirms jūsu lietotnes koda izpildes.
• PoC kods ir publisks. Rēķinieties ar plašu skenēšanu stundu, nevis nedēļu laikā.
• Ja nevarat labot uzreiz: izolējiet internetā pieejamos servisus, līdz labojums ir ieviests un pārbaudīts.

Kas notika

1. oktobrī PHP projekts paziņoja, ka drošības izlaidums ir ceļā. Nākamajā dienā, 21. oktobrī plkst. 13.30 UTC, labojumi tika publicēti četrās versijās vienlaikus: 8.5.12, 8.4.27, 8.3.36 un 8.2.35. CERT-EU tajā pašā dienā izdeva drošības brīdinājumu un aicināja organizācijas nekavējoties atjaunināt.

Tas, ka labojums parādījās ātri, ir labi. Tas, ka tehniskais apraksts vienlaikus kļuva publisks, nozīmē, ka laiks no „labojums ir pieejams” līdz „uzbrucēji mēģina” tiek mērīts stundās.

Ko ievainojamības faktiski dara

CVE-2026-109618 – atmiņas bojājums pie atmiņas robežas

PHP aptur pieprasījumu, kas pārsniedz memory_limit, pārtraucot to ar longjmp(). Tas nozīmē, ka pārtraukums var notikt iekšējas darbības vidū, kamēr pieprasījuma dati ir tikai daļēji inicializēti – piemēram, analizējot faila augšupielādi formā.

Pēc tam pieprasījuma uzkopšana var apstrādāt nederīgus datus kā derīgus un atbrīvot atmiņu, kas nekad netika inicializēta. Tajā atmiņā joprojām var būt uzbrucēja kontrolēti dati no iepriekšējām atvēlēm. Rezultāts ir atmiņas bojājums, kas var novest pie koda izpildes.

CVE-2026-109619 – atlikušais globālais stāvoklis

Vienam pieprasījumam piederošs iekšējais stāvoklis var saglabāties pēc tam, kad tā atmiņa ir atbrīvota – piemēram, pēc fatālas kļūdas. Vēlāks pieprasījums, ko apstrādā tas pats darba process, var izmantot atlikušo stāvokli, pirms parastā inicializācija paspējusi to atiestatīt.

Tātad neviena ievainojamība nav atkarīga no tā, vai jūsu lietotnē ir kļūda. Tās atrodas pašā PHP pieprasījumu apstrādē.

Demonstrēts exploit parāda, ka viens neautentificēts pieprasījums var izraisīt uzbrukumu pirms jebkāda lietotnes koda izpildes.

Kas ir ietekmēts

Visas PHP instalācijas, kas apkalpo tīmekļa trafiku. PHP komanda uzskata, ka mod_php ir vismazāk aizsargātā konfigurācija.

• PHP 8.5 pirms 8.5.12
• PHP 8.4 pirms 8.4.27
• PHP 8.3 pirms 8.3.36
• PHP 8.2 pirms 8.2.35
• Beigušie atzari (PHP 8.1 un vecākas), kas vairs nesaņem regulārus atjauninājumus

Turklāt: daudzi komerciāli un atvērtā koda produkti izmanto PHP savā pamatā. Tie var būt ietekmēti arī tad, ja jūs paši neuzturat PHP instalāciju. NCSC-NL ir publicējis trešo pušu programmatūras sarakstu, kurā PHP ir iekļauts.

Biežākā kļūda, ko redzam: tiek skaitīti tikai tie serveri, ko paši uzstādījāt. Neaizmirstiet konteinerus, CI attēlus, ierīces, iekšējos rīkus un piegādātāju pārvaldītos pakalpojumus.

Pārbaudiet situāciju – piecas minūtes vienai videi

1. Palaidiet php -v katrā resursdatorā un katrā konteinerā. Ne tikai vienā.
2. Uzskaitiet izpildvides: PHP-FPM pūli, Apache ar mod_php, php-cgi, FrankenPHP, LiteSpeed.
3. Pārbūvējiet konteineru attēlus – noteicošais ir bāzes attēls, nevis darbojošais eksemplārs.
4. Jautājiet piegādātājiem, kas jūsu vietā pārvalda ar PHP saistītus produktus: kādu versiju izmantojat un kad būsiet atjauninājuši?
5. Atrodiet beigušos atzarus. PHP 8.1 un vecākas nesaņem regulārus labojumus.

Novērsiet

Distribūciju pakotnes. Linux distribūcijām un LTS piegādātājiem labojumi bija pieejami iepriekš. Atjauniniet, izmantojot pakotņu pārvaldnieku, un restartējiet darba procesus.

Konteineri. Atjauniniet bāzes attēlu un pārbūvējiet. Vecā attēla restartēšana neko neatrisina.

Pašu kompilēts. Atjauniniet uz 8.5.12, 8.4.27, 8.3.36 vai 8.2.35.

Beigušās versijas. PHP komanda ir publicējusi minimālus backportus 7.4, 8.0 un 8.1 versijām tiem, kas kompilē no pirmkoda vai kam nav LTS piegādātāja. Ja jums ir LTS piegādātājs: vispirms sazinieties ar to.

rpms.remirepo.net: šis brīvprātīgi uzturētais repozitorijs izlaišanas dienā nesaņem atjauninājumus. PHP komanda aicina lietotājus pāriet uz distribūcijas pakotnēm vai kompilēt no pirmkoda.

Pēc atjaunināšanas restartējiet PHP-FPM un pārējos darba procesus. Jauns binārais fails bez restarta joprojām ir vecais process.

Ja šodien nevarat labot

Turpmākie pasākumi samazina pakļautību konkrētiem uzbrukuma ceļiem. Tie nepadara instalāciju drošu. Tikai atjauninājums aizver ievainojamību.

Pret CVE-2026-109618:

• Iestatiet memory_limit=-1 tā, lai lietotne to nevarētu pārrakstīt, piemēram, php_admin_value FPM pūlā vai Apache konfigurācijā. Pārbaudiet, vai neviens pūls, direktorija vai lietotnes iestatījums neatgriež robežu.
• Iestatiet zemu post_max_size: 8M lietotnēm bez failu augšupielādes, 32M tur, kur augšupielāde ir nepieciešama. Turiet upload_max_filesize mazāku par post_max_size.
• Iestatiet tīmekļa servera vai starpniekservera ierobežojumus atkodētā pieprasījuma izmēram, lauku skaitam, multipart daļu skaitam, galveņu skaitam un ligzdošanas dziļumam. Ierobežojumiem jāaptver arī pieprasījumi bez izmantojama Content-Length.
• Izmantojiet konteinera vai cgroup atmiņas ierobežojumu kā pieejamības robežu, vēlams ar politiku, kas nogalina tikai skarto darba procesu. Neizmantojiet RLIMIT_AS vai RLIMIT_DATA – tie var izraisīt ievainojamo atvēlēšanas ceļu.

Pret CVE-2026-109619:

• Iestatiet session.upload_progress.enabled=0 un restartējiet katru darba procesu. Iestatiet to php.ini, FPM pūlā vai servera konfigurācijā, lai tas būtu spēkā pirms pieprasījuma analīzes. Nepaļaujieties uz ini_set() vai FPM .user.ini.
• PHP 8.5 gadījumā: iestatiet fatal_error_backtraces=0 un restartējiet katru darba procesu.
• Noņemiet nederīgus vai novecojušus pieprasījuma līmeņa iestatījumus, kas pirms inicializācijas izvada diagnostiku. Diagnostikas slēpšana ar error_reporting, display_errors vai @ nepalīdz.
• Labojiet fatālas kļūdas un izpildes laika ierobežojumus, kurus uzbrucējs var sasniegt – atzvanos, augšupielādē, importā un uzkopšanā.

Kāpēc nevajadzētu gaidīt

Trīs lietas atšķir šo notikumu no parasta labojuma:

1. Autentifikācija nav nepieciešama. Nav pieteikšanās, aiz kuras paslēpties.
2. Uzbrukums notiek pirms jūsu koda. Lietotnes loģika, WAF noteikumi un tiesību modelis šeit nav aizsardzības barjera.
3. PoC jau ir publisks. Tas, kas parasti prasa nedēļas, jau ir izdarīts kāda cita vietā.

Labojuma un restarta izmaksas šodien ir niecīgas salīdzinājumā ar ielaušanās izmaksām. Tas jo īpaši attiecas uz jums, ja uz jums attiecas NIS2, kur par būtisku incidentu jāziņo 24 stundu laikā.

Pēc labojuma – trīs lietas

1. Pārbaudiet katrā mezglā. Versiju – ne tikai to, ka pakotņu pārvaldnieks pateica OK.
2. Lasiet žurnālus atpakaļ. Multipart POST pieprasījumi, negaidītas 500 atbildes, sabrukuši darba procesi un trafiks no nezināmiem avotiem pēdējās dienās.
3. Pie mazākajām aizdomām: palaidiet incidenta procedūru. Izolējiet, nodrošiniet žurnālus, novērtējiet, vai nepieciešama ziņošana.

Avoti

• CERT-EU, Security Advisory 2026-018: https://cert.europa.eu/publications/security-advisories/2026-018/
• PHP 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35: https://www.php.net/
• GHSA-w8hw-w9fx-j79w: https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w
• GHSA-6wmf-4rv5-p3rp: https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp
• NCSC-NL, produktu saraksts ar iekļautu PHP: https://github.com/NCSC-NL/php2shell

---

Šādas ievainojamības pašas par sevi ir arguments nepārtrauktai drošībai: atjauninājumi, pārbaude un uzraudzība, kas notiek visu laiku – nevis ikgadēja pārskatīšana. Lasiet vairāk par to, ko nepārtrauktā drošība nozīmē praksē.