# CVE-2026-109619: RCE zbog zastarjelog globalnog stanja

> CVE-2026-109619 razumljivo: zašto interno stanje između zahtjeva postaje opasno, koje su verzije PHP-a ispravljene i kako se osigurati.

Izvor: https://phpsos.de/hr/php2shell/cve-2026-109619/  
Stanje: 25.10.2026  
Pružatelj: PHP SOS, PHP hitna pomoć i sigurnost poslužitelja. Hitna pomoć putem WhatsAppa: https://wa.me/491736494914?text=Pozdrav%20PHP%20SOS%2C%20trebamo%20pomo%C4%87%20s%20na%C5%A1im%20PHP%20poslu%C5%BEiteljem.%20Tvrtka%3A%20%E2%80%A6%20Web-stranica%3A%20%E2%80%A6

**Ukratko:** CVE-2026-109619 je druga ranjivost iza PHP2Shella. Interno stanje koje pripada zahtjevu može ostati nakon oslobađanja memorije; kasniji zahtjev u istom workeru može ga iskoristiti prije nego što se resetira. Posljedica je izvršavanje koda bez prijave. Mjera: ažuriranje na PHP 8.5.12, 8.4.27, 8.3.36 ili 8.2.35 i ponovno pokretanje svih workera.

## Što je CVE-2026-109619?

CVE-2026-109619 (GitHub oznaka GHSA-6wmf-4rv5-p3rp) ocijenjen je s 9,2 prema CVSS-u v4.0. Zajedno s [CVE-2026-109618](https://phpsos.de/hr/php2shell/cve-2026-109618/) čini PHP2Shell. Obje ranjivosti nalaze se u samom PHP-u, a ne u aplikaciji.

Učinak je isti kao kod sestrinske ranjivosti: napadač može izdaleka, bez lozinke i bez korisničkog računa, izvršavati kod na poslužitelju. Uzrok je međutim drukčiji.

## Zašto je zastarjelo stanje u workeru opasno

PHP web-poslužitelj ne pokreće novi proces za svaki zahtjev. Kod PHP-FPM-a, Apachea s mod_php, LiteSpeeda ili FrankenPHP-a jedan worker obrađuje mnogo zahtjeva jedan za drugim. Između dva zahtjeva PHP resetira svoje interno stanje kako ništa iz zahtjeva A ne bi dospjelo u zahtjev B.

Kod CVE-2026-109619 to resetiranje ne uspijeva potpuno. Prema php.net-u interno stanje koje pripada zahtjevu može ostati nakon oslobađanja memorije. Kasniji zahtjev u istom workeru može to zastarjelo stanje iskoristiti prije nego što se resetira. Pojednostavljeno: nešto se i dalje koristi što zapravo više nije valjano.

S gledišta rada to je značajno. Ponovna uporaba workera je željena jer web-poslužitelje čini brzima: worker se ne mora za svaki zahtjev iznova pokretati, učitavati proširenja i stvarati memoriju. Ranjivost dakle pogađa svojstvo koje ima praktički svaka produkcijska PHP instalacija. php.net ne navodi konfiguraciju koja problem u potpunosti izbjegava; zato put vodi preko ažuriranja.

Pojedinosti o iskorištavanju ne objavljujemo. Za operatere vrijedi: svaki način rada u kojem worker poslužuje više zahtjeva treba imati na oku, a upravo su ti načini uobičajeni.

## Dvije PHP2Shell ranjivosti u usporedbi

| Svojstvo | CVE-2026-109618 | CVE-2026-109619 |
|---|---|---|
| GitHub oznaka | GHSA-w8hw-w9fx-j79w | GHSA-6wmf-4rv5-p3rp |
| Ocjena | CVSS v4.0 9,2 | CVSS v4.0 9,2 |
| Okidač | Out of Memory tijekom inicijalizacije podataka zahtjeva | Interno stanje ostaje nakon oslobađanja |
| Učinak | Izvršavanje koda bez prijave | Izvršavanje koda bez prijave |
| Ispravljeno u | 8.5.12, 8.4.27, 8.3.36, 8.2.35 | 8.5.12, 8.4.27, 8.3.36, 8.2.35 |

Pogođeni su PHP-FPM, Apache s mod_php, php-cgi, FrankenPHP i LiteSpeed. Najviši rizik PHP tim vidi kod mod_php; zašto, objašnjavamo na stranici [Zašto mod_php nosi najviši rizik](https://phpsos.de/hr/php2shell/mod-php-risiko/).

## Zatvaranje CVE-2026-109619: ažuriranje, zatim ponovno pokretanje svih workera

Upravo je kod ove ranjivosti ponovno pokretanje odlučujuće. Dok stari workeri rade u memoriji, poslužitelj nastavlja raditi s neispravnim kodom, iako nove datoteke odavno leže na disku.

Provjerite verziju i stanje paketa. Nazivi paketa razlikuju se po distribuciji i sučelju pružatelja hostinga:

```bash
php -v
php-fpm8.3 -v                  # FPM binarna datoteka može imati drugu verziju od CLI-ja
apt policy php8.3-fpm          # Debian/Ubuntu
dnf info php-fpm               # obitelj RHEL
rpm -q --changelog php-fpm | grep -i "CVE-2026-109619"
```

Zatim ponovno pokrenite sve pogođene usluge:

```bash
sudo systemctl restart php8.3-fpm     # za svaku instaliranu verziju PHP-a
sudo systemctl restart apache2        # kod mod_php; u RHEL-u usluga se zove httpd
```

Ako Vaša distribucija ili pružatelj hostinga ugradi backport, prikazani broj verzije može ostati isti. Tada vrijede changelog paketa i pisana potvrda pružatelja. Provjeru korak po korak pronaći ćete na stranici [Ponovno pokretanje PHP-FPM-a i svih workera](https://phpsos.de/hr/php2shell/php-fpm-neustart/).

> **Savjet:**
> Zabilježite datum i sat ponovnog pokretanja. Za kasniju procjenu je li se napad dogodio prije ili poslije zakrpe, taj je trenutak najvažnija referentna točka.

## Što nakon zakrpe još preostaje

Zakrpa ne dokazuje da se prije nije ništa dogodilo. Prema medijskim izvješćima prvi je pokušaj napada uočen 17. listopada, četiri dana prije zakrpa. Čuvajte zapisnike poslužitelja od 20. listopada, kako preporučuje stručni tisak, i provjerite poslužitelj zbog upadljivosti. Napomene daje stranica [Jesam li već kompromitiran?](https://phpsos.de/hr/php2shell/bin-ich-gehackt-anzeichen/).

Pritom pomislite na doseg: kod uspješnog izvršavanja koda napadač ima prava PHP procesa. Može čitati što aplikacija smije čitati, primjerice konfiguracijske datoteke s pristupima bazama podataka ili API ključevima. Ako se incident potvrdi, ti pristupni podaci nakon čišćenja moraju se obnoviti.

## Kako PHP SOS konkretno pomaže?

Uz [uslugu PHP zakrpe](https://phpsos.de/hr/leistungen/php-patch-service/) ispravak provodimo razumljivo i provjerljivo:

- **Zabilježiti:** Koje verzije PHP-a i načini rada rade na kojem poslužitelju i koji izvor paketa ih isporučuje?
- **Zakrpati:** Ažuriranje iz ispravnog izvora ili privremene mjere prema php.net-u ondje gdje je ažuriranje još blokirano.
- **Kontrolirati ponovno pokretanje:** Proces po proces provjeravamo da radi samo još ispravljena verzija.
- **Dokumentirati:** Verzije, stanja paketa i trenutke ponovnog pokretanja kako biste stanje mogli dokazati.


## Česta pitanja

**Po čemu se CVE-2026-109619 razlikuje od CVE-2026-109618?**  
CVE-2026-109618 nastaje kad stanje Out of Memory prekine zahtjev usred inicijalizacije. CVE-2026-109619 odnosi se na stanje koje nakon završetka zahtjeva ostaje u workeru. Obje vode do izvršavanja koda bez prijave i ispravljene su u istim verzijama PHP-a.

**Pomaže li češće ponovno pokretanje PHP-FPM workera?**  
Kao zamjena za ažuriranje nije prikladno. php.net ne navodi češća ponovna pokretanja workera kao privremenu mjeru. Workere ipak morate ponovno pokrenuti nakon ažuriranja kako bi ispravljena verzija uopće radila.

**Jesam li ažuriranjem CMS-a zaštićen od CVE-2026-109619?**  
Ne. Ranjivost je u PHP-u, a ne u WordPressu, Shopwareu, TYPO3-u ili nekom drugom sustavu. Zatvara je samo PHP ažuriranje ili potvrđeni backport pružatelja.

**Postoje li poznati tragovi napada putem CVE-2026-109619?**  
Potvrđeni indikatori kompromitacije (Indicators of Compromise) do sada nisu objavljeni. Otkrivanje počiva na analizi ponašanja, primjerice novim PHP datotekama, neuobičajenim odlaznim vezama ili nepoznatim cron poslovima.

## Izvori

- [php.net: sigurnosne objave](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)
- [BSI: Savezni ured za sigurnost informacijske tehnologije](https://www.bsi.bund.de/)