# CVE-2026-109618: RCE mälupuuduse (Out-of-Memory) seisundi tõttu

> CVE-2026-109618 selgitatud: kuidas mälupuuduse (Out-of-Memory) seisund PHP-s võib viia koodi käivitamiseni, millised versioonid on parandatud ja mida teha.

Allikas: https://phpsos.de/et/php2shell/cve-2026-109618/  
Seis: 25.10.2026  
Pakkuja: PHP SOS, PHP hädaabi ja serveri turvalisus. Kohene abi WhatsAppis: https://wa.me/491736494914?text=Tere%2C%20PHP%20SOS%2C%20vajame%20abi%20oma%20PHP-serveriga.%20Ettev%C3%B5te%3A%20%E2%80%A6%20Veebisait%3A%20%E2%80%A6

**Lühidalt:** CVE-2026-109618 on üks kahest PHP2Shelli taga olevast turvaaugust. Mälupuuduse (Out-of-Memory) seisund võib PHP katkestada, kui päringuandmed on alles osaliselt lähtestatud; koristamisel võidakse siis kehtetuid andmeid pidada kehtivateks. See võimaldab koodi käivitamist ilma sisselogimata. Viga on parandatud versioonides PHP 8.5.12, 8.4.27, 8.3.36 ja 8.2.35.

## Mis on CVE-2026-109618?

CVE-2026-109618 (GitHubi tähis GHSA-w8hw-w9fx-j79w) on mälu vea turvaauk PHP tuumas. See on hinnatud CVSS v4.0 järgi 9,2. Koos [CVE-2026-109619](https://phpsos.de/et/php2shell/cve-2026-109619/)-ga moodustab see selle, mida meedias nimetatakse [PHP2Shelliks](https://phpsos.de/et/php2shell/was-ist-php2shell/).

Mõju on nn unauthenticated Remote Code Execution: ründaja saab kaugelt ja ilma kasutajakontota veebiserveris koodi käivitada. Sellega kuulub turvaauk kõige ohtlikumasse nõrkuste klassi, mis veebiserveril olla võib.

## Kuidas turvaauk põhimõtteliselt tekib

Kui PHP töötleb veebipäringut, loob see sisemiselt selle päringu jaoks andmestruktuure, näiteks edastatud vormiandmete jaoks. Kui PHP jõuab seejuures oma mälupiirini, katkeb töö mälupuuduse (Out-of-Memory) seisundiga. php.net-i järgi võib see juhtuda, kui päringuandmed on alles osaliselt lähtestatud.

Iga päringu lõpus PHP koristab ja vabastab mälu. Just seal peitub viga: koristamine võib käsitleda kehtetuid, ainult pooleldi loodud andmeid kehtivatena. Sellest veast saab teatud tingimustel tuletada koodi käivitamise.

Miks on selline viga nii tõsine? Mäluviga programmeerimiskeeles puudutab kõiki sellel töötavaid rakendusi, olenemata sellest, kui hoolikalt need on programmeeritud. Hooldatud WordPressi paigaldus värskete pluginatega on sama mõjutatud kui vana oma arendus. Seetõttu ei aita siin rakenduse uuendus, vaid ainult PHP uuendus.

Täiendavaid tehnilisi üksikasju ekspluateerimise kohta me teadlikult ei avalda. Kaitseks pole need vajalikud: otsustav on, kas teie server kasutab parandatud versiooni ja kas uued protsessid tegelikult töötavad.

## Mõjutatud versioonid ja töörežiimid

| PHP haru | Viimane seis enne parandust | Parandatud alates |
|---|---|---|
| 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 ja vanemad | ametlikku uuendust pole | ainult minimaalsed lähtekoodi tagasiportimised versioonidele 7.4, 8.0, 8.1 |

Mõjutatud on töörežiimid PHP-FPM, Apache koos mod_php-ga, php-cgi, FrankenPHP ja LiteSpeed. PHP meeskond hindab riski mod_php puhul kõige suuremaks. Distributsioonid ja veebimajutajad portivad parandusi osaliselt tagasi, nii et kuvatakse vanemat versiooninumbrit, kuigi viga on parandatud. Määrav on paketi seis ja pakkuja kinnitus.

Suurusjärgust: Palo Alto Networks (Unit 42) luges kokku üle 22,6 miljoni avalikult ligipääsetava, potentsiaalselt haavatava instantsi. BSI on välja kuulutanud hoiatustaseme 3 (oranž) ja arvestas kiire laiaulatusliku ärakasutamisega.

## CVE-2026-109618 kõrvaldamine: uuendus ja taaskäivitus

Ainus täielik abinõu on uuendus. Kontrollige kõigepealt versiooni ja paketi seisu. Paketinimed erinevad distributsiooniti; näited lähtuvad PHP 8.3-st:

```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"
```

Kui paketi muudatuslogis on CVE-number nimetatud, on tagasiportimine paigaldatud. Kui seda pole, ei tähenda see automaatselt, et pakett on haavatav; siis aitab võrdlus versioonitabeliga või päring pakkujalt.

Pärast uuendust tuleb kõik PHP protsessid uuesti käivitada, näiteks käsuga `systemctl restart php8.3-fpm` või mod_php puhul Apache'i taaskäivitusega. Kuidas tagada, et ükski vana tööprotsess enam ei tööta, on kirjas lehel [PHP-FPM-i ja kõigi tööprotsesside taaskäivitus](https://phpsos.de/et/php2shell/php-fpm-neustart/).

## Ajutised meetmed, kui uuendus veel ei õnnestu

php.net on PHP2Shelli kohta avaldanud ajutised meetmed. Need kehtivad mõlema turvaaugu kohta ühiselt ja ei ole selgesõnaliselt täielik kaitse. See, et mitu neist puudutab mälupiire, sobib CVE-2026-109618 mälupuuduse (Out-of-Memory) käivitajaga; ametlikku üksikute meetmete seostamist üksikute CVE-dega aga ei ole.

```ini
; Näide FPM-i poolist, nt /etc/php/8.3/fpm/pool.d/www.conf (tee on distributsiooniti erinev)
; post_max_size: 32M, kui üleslaadimised on vajalikud; upload_max_filesize alati väiksem kui post_max_size
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M          ; 32M, kui üleslaadimised on vajalikud
php_admin_value[upload_max_filesize] = 6M    ; alati väiksem kui post_max_size
php_admin_flag[session.upload_progress.enabled] = off
```

Väärtused tuleb määrata nii, et rakendused ei saa neid üle kirjutada, seetõttu `php_admin_value`. Seadega `memory_limit=-1` vajab teenus väljastpoolt mälupiirangut, konteineri või cgroupi kaudu, mitte `RLIMIT_AS` või `RLIMIT_DATA` kaudu. PHP 8.5 puhul lisandub `fatal_error_backtraces=0`. Kõik üksikasjad on lehel [Kohesed meetmed, kui te veel paigata ei saa](https://phpsos.de/et/php2shell/sofortmassnahmen-ohne-patch/).

> **Oluline:**
> Kui ei uuendus ega ajutised meetmed ole kohe võimalikud, soovitab BSI mõjutatud veebiserverid ajutiselt võrgust maha võtta.

## Kuidas PHP SOS konkreetselt aitab?

Oma [PHP paikamisteenuse](https://phpsos.de/et/leistungen/php-patch-service/) kaudu sulgeme CVE-2026-109618 struktureeritult:

- **Tegeliku seisu kaardistamine:** PHP haru, töörežiim, paketiallikas ja tagasiportimise seis iga serveri kohta.
- **Uuenduse paigaldamine** sobivast paketiallikast või, kus see ei õnnestu, ajutiste meetmete korrektne seadmine poolis või serveri seadistuses.
- **Taaskäivituse kontroll:** Kontrollime, et vanu PHP protsesse enam ei tööta.
- **Tõend:** Saate dokumentatsiooni versioonide ja paketi seisudega enne ja pärast sekkumist, näiteks juhtkonnale, kindlustajale või andmekaitsele.


## Korduma kippuvad küsimused

**Kui kriitiline on CVE-2026-109618?**  
Turvaauk on hinnatud CVSS v4.0 järgi 9,2 ja seega kriitiliseks. See võimaldab kahjuliku koodi kaugkäivitust ilma sisselogimata. BSI on PHP2Shelli kohta välja kuulutanud hoiatustaseme 3 (oranž).

**Kas piisab memory_limit'i tõstmisest?**  
Ei. php.net nimetab seadet memory_limit=-1, seadistatuna kindlalt serveri seadistuses, ühe mitmest ajutisest meetmest. See ei ole selgesõnaliselt täielik kaitse ja vajab mälupiirangut konteineri või cgroupi kaudu. Lahenduseks jääb uuendus.

**Milline GHSA-tähis kuulub CVE-2026-109618 juurde?**  
GitHub Security Advisory's on turvaauk kirjas tähisega GHSA-w8hw-w9fx-j79w. Teisel PHP2Shelli turvaaugul, CVE-2026-109619, on tähis GHSA-6wmf-4rv5-p3rp.

## Allikad

- [php.net: turvateated](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)
- [BSI: Saksamaa föderaalne infoturbeamet](https://www.bsi.bund.de/)