# CVE-2026-109618: RCE dėl atminties pritrūkimo būsenos

> CVE-2026-109618 paaiškinta: kaip atminties pritrūkimo būsena PHP gali lemti kodo vykdymą, kurios versijos ištaisytos ir ką administratoriai daro dabar.

Šaltinis: https://phpsos.de/lt/php2shell/cve-2026-109618/  
Būsena: 2026-10-25  
Teikėjas: PHP SOS, PHP avarinė pagalba ir serverio sauga. Skubi pagalba per „WhatsApp“: https://wa.me/491736494914?text=Sveiki%2C%20PHP%20SOS%2C%20mums%20reikia%20pagalbos%20su%20m%C5%ABs%C5%B3%20PHP%20serveriu.%20%C4%AEmon%C4%97%3A%20%E2%80%A6%20Svetain%C4%97%3A%20%E2%80%A6

**Trumpai:** CVE-2026-109618 yra viena iš dviejų spragų už PHP2Shell. Atminties pritrūkimo (Out-of-Memory) būsena gali nutraukti PHP, kai užklausos duomenys inicializuoti tik iš dalies; valant atmintį neteisingi duomenys gali būti laikomi galiojančiais. Tai leidžia vykdyti kodą be prisijungimo. Klaida ištaisyta PHP 8.5.12, 8.4.27, 8.3.36 ir 8.2.35 versijose.

## Kas yra CVE-2026-109618?

CVE-2026-109618 (GitHub identifikatorius GHSA-w8hw-w9fx-j79w) yra atminties klaidos spraga PHP branduolyje. Pagal CVSS v4.0 ji įvertinta 9,2 balo. Kartu su [CVE-2026-109619](https://phpsos.de/lt/php2shell/cve-2026-109619/) ji sudaro tai, ką žiniasklaida vadina [PHP2Shell](https://phpsos.de/lt/php2shell/was-ist-php2shell/).

Poveikis yra vadinamasis „unauthenticated Remote Code Execution“: užpuolikas gali nuotoliniu būdu ir be naudotojo paskyros vykdyti kodą žiniatinklio serveryje. Todėl spraga priklauso pavojingiausiai pažeidžiamumų klasei, kokią gali turėti žiniatinklio serveris.

## Kaip spraga iš esmės atsiranda

Kai PHP apdoroja žiniatinklio užklausą, vidujai sukuria tai užklausai skirtas duomenų struktūras, pavyzdžiui, pateiktiems formos duomenims. Jei PHP čia pasiekia atminties ribą, jis nutrūksta su atminties pritrūkimo (Out-of-Memory) būsena. Pasak php.net, tai gali nutikti, kai užklausos duomenys inicializuoti tik iš dalies.

Kiekvienos užklausos pabaigoje PHP sutvarko ir atlaisvina atmintį. Būtent čia glūdi klaida: valymas gali neteisingus, tik iš dalies sukurtus duomenis traktuoti kaip galiojančius. Iš tokio netinkamo elgesio tam tikromis sąlygomis galima išvesti kodo vykdymą.

Kodėl tokia klaida rimta? Atminties klaida programavimo kalboje paveikia visas ja veikiančias programas, nepriklausomai nuo to, kaip kruopščiai jos programuotos. Prižiūrėtas WordPress diegimas su naujausiais įskiepiais paveiktas lygiai taip pat kaip sena nuosavo kūrimo programa. Todėl čia nepadeda programos atnaujinimas, o tik PHP atnaujinimas.

Tolesnių techninių išnaudojimo detalių sąmoningai neskelbiame. Gynybai jų nereikia: lemia tai, ar jūsų serveris naudoja ištaisytą versiją ir ar nauji procesai tikrai veikia.

## Paveiktos versijos ir veikimo režimai

| PHP šaka | Paskutinė būsena prieš taisymą | Ištaisyta nuo |
|---|---|---|
| 8.5 | 8.5.11 | 8.5.12 |
| 8.4 | 8.4.26 | 8.4.27 |
| 8.3 | 8.3.35 | 8.3.36 |
| 8.2 | 8.2.34 | 8.2.35 |
| 8.1 ir senesnės | oficialaus atnaujinimo nėra | tik minimalūs šaltinio kodo atgaliniai perkėlimai 7.4, 8.0, 8.1 |

Paveikti veikimo režimai PHP-FPM, Apache su mod_php, php-cgi, FrankenPHP ir LiteSpeed. PHP komanda riziką vertina didžiausią esant mod_php. Distribucijos ir talpintojai kartais įdiegia atgalinius perkėlimus (backports), todėl rodoma senesnė versija, nors klaida ištaisyta. Lemia paketų būsena ir teikėjo patvirtinimas.

Dėl mastelio: Palo Alto Networks (Unit 42) suskaičiavo daugiau nei 22,6 milijono viešai pasiekiamų, potencialiai pažeidžiamų egzempliorių. BSI paskelbė 3 įspėjimo lygį (oranžinis) ir laukė greito plataus išnaudojimo.

## CVE-2026-109618 šalinimas: atnaujinimas ir paleidimas iš naujo

Vienintelė visiška priemonė yra atnaujinimas. Pirmiausia patikrinkite versiją ir paketų būseną. Paketų pavadinimai priklauso nuo distribucijos; pavyzdžiai remiasi PHP 8.3:

```bash
php -v
apt policy php8.3-fpm          # Debian/Ubuntu
dnf info php-fpm               # RHEL, AlmaLinux, Rocky, Fedora
rpm -q --changelog php-fpm | grep -i "CVE-2026-109618"
```

Jei paketo pakeitimų žurnale (changelog) nurodytas CVE numeris, atgalinis perkėlimas įdiegtas. Jei jo nėra, tai automatiškai nereiškia, kad paketas pažeidžiamas; tuomet padeda palyginimas su versijų lentele arba užklausa teikėjui.

Po atnaujinimo reikia paleisti iš naujo visus PHP procesus, pavyzdžiui, su `systemctl restart php8.3-fpm` arba esant mod_php iš naujo paleidus Apache. Kaip užtikrinti, kad nebeveiktų senas darbinis procesas (worker), aprašyta puslapyje [PHP-FPM ir visų darbinių procesų paleidimas iš naujo](https://phpsos.de/lt/php2shell/php-fpm-neustart/).

## Pereinamosios priemonės, kai atnaujinti dar negalima

php.net dėl PHP2Shell paskelbė pereinamąsias priemones. Jos galioja abiem spragoms kartu ir aiškiai nėra visiška apsauga. Tai, kad kelios jų susijusios su atminties ribomis, dera su CVE-2026-109618 atminties pritrūkimo sukėlėju; tačiau oficialaus atskirų priemonių priskyrimo atskiriems CVE nėra.

```ini
; FPM baseino pavyzdys, pvz. /etc/php/8.3/fpm/pool.d/www.conf (kelias priklauso nuo distribucijos)
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M          ; 32M, jei reikia įkėlimų
php_admin_value[upload_max_filesize] = 6M    ; immer unter post_max_size
php_admin_flag[session.upload_progress.enabled] = off
```

Reikšmės turi būti nustatytos taip, kad programos jų negalėtų perrašyti, todėl `php_admin_value`. Su `memory_limit=-1` tarnybai reikia atminties ribos iš išorės, per konteinerį ar cgroup, o ne per `RLIMIT_AS` ar `RLIMIT_DATA`. PHP 8.5 papildomai taikoma `fatal_error_backtraces=0`. Visos detalės pateiktos puslapyje [Skubios priemonės, kai dar negalite pataisyti](https://phpsos.de/lt/php2shell/sofortmassnahmen-ohne-patch/).

> **Svarbu:**
> Jei nei atnaujinimas, nei pereinamosios priemonės iš karto neįmanomos, BSI rekomenduoja paveiktus žiniatinklio serverius laikinai atjungti nuo tinklo.

## Kaip PHP SOS padeda konkrečiai?

Per savo [PHP pataisų paslaugą](https://phpsos.de/lt/leistungen/php-patch-service/) CVE-2026-109618 uždarome struktūruotai:

- **Užfiksuoti esamą būklę:** PHP šaka, veikimo režimas, paketų šaltinis ir atgalinio perkėlimo būklė kiekviename serveryje.
- **Įdiegti atnaujinimą** iš tinkamo paketų šaltinio arba, kur to nepavyksta, tvarkingai nustatyti pereinamąsias priemones baseino ar serverio konfigūracijoje.
- **Patikrinti paleidimą iš naujo:** Kontroliuojame, kad nebeveikia seni PHP procesai.
- **Įrodymas:** Gaunate dokumentaciją su versijomis ir paketų būsenomis prieš įsikišimą ir po jo, pavyzdžiui, vadovybei, draudikui ar duomenų apsaugai.


## Dažni klausimai

**Kiek kritinė yra CVE-2026-109618?**  
Spraga pagal CVSS v4.0 įvertinta 9,2 balo ir todėl yra kritinė. Ji leidžia nuotoliniu būdu vykdyti kenkėjišką kodą be prisijungimo. BSI (Vokietijos federalinė informacijos saugumo tarnyba) dėl PHP2Shell paskelbė 3 įspėjimo lygį (oranžinis).

**Ar pakanka padidinti memory_limit?**  
Ne. php.net nurodo memory_limit=-1, nustatytą tvirtai serverio konfigūracijoje, kaip vieną iš kelių pereinamųjų priemonių. Ji aiškiai nėra visiška apsauga ir reikalauja atminties ribos per konteinerį ar cgroup. Sprendimas lieka atnaujinimas.

**Koks GHSA identifikatorius priklauso CVE-2026-109618?**  
GitHub Security Advisory spraga vedama pavadinimu GHSA-w8hw-w9fx-j79w. Antroji PHP2Shell spraga, CVE-2026-109619, turi identifikatorių GHSA-6wmf-4rv5-p3rp.

## Šaltiniai

- [php.net: saugumo pranešimai](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)
- [BSI (Vokietijos federalinė informacijos saugumo tarnyba)](https://www.bsi.bund.de/)