Kritične ranjivosti u PHP-u (CVE-2026-109618 i CVE-2026-109619): što se dogodilo i što učiniti

Dana 21. listopada 2026. projekt PHP objavio je ispravke za dvije kritične greške, a CERT-EU je istoga dana objavio upozorenje 2026-018. Obje su ocijenjene s 9,2 i obje su opisane kao udaljeno izvršavanje koda bez autentifikacije. Ako upravljate WordPress stranicom, web-trgovinom ili bilo kojom drugom PHP aplikacijom, ovo se tiče Vas, a rješenje je ažuriranje, a ne neka postavka. Ovaj članak objašnjava što je poznato, kako napad dolazi do cilja i što učiniti. Stanje: 22. listopada 2026., prema verziji 1.1 upozorenja CERT-EU.

Što se dogodilo

PHP je 20. listopada najavio sigurnosno izdanje, a ispravke je objavio 21. listopada u 13:30 UTC. CERT-EU je svoje upozorenje naslovio „Critical Vulnerabilities in PHP” i navodi dvije oznake CVE: CVE-2026-109618 i CVE-2026-109619, svaku s ocjenom 9,2. CERT-EU također piše da se tehnički detalji već javno raspravljaju i da je počeo kružiti prvi proof-of-concept kôd. Upozorenje ne potvrđuje napade u stvarnom svijetu, ali navodi da je zbog toga vjerojatnije da napadači te greške već iskorištavaju. Postupajte kao da je hitno.

Tko je pogođen

Pogođena je svaka verzija PHP-a niža od ispravljene u podržanoj grani te svaka grana kojoj je podrška istekla.

CERT-EU navodi PHP-FPM, Apache s mod_php, php-cgi, FrankenPHP i LiteSpeed. Prema timu PHP-a, najveći rizik nosi mod_php. Pogođeni mogu biti i proizvodi koji ugrađuju PHP; CERT-EU upućuje na popis nizozemskog NCSC-a na kraju ovog članka. Računa se svaka instalacija koja poslužuje web-zahtjeve, bez obzira ima li obrazac za učitavanje datoteka ili ne.

Kako napadač dolazi do prve greške

Nitko se ne mora prijaviti. Prema CERT-EU-u, prikazani postupak iskorištavanja pokazuje da jedan jedini zahtjev bez prijave može pokrenuti napad prije nego što se izvrši ijedan kôd aplikacije. To je točka koju većina ljudi previdi: nije važno je li Vaš WordPress ažuran, jesu li dodatci zakrpani i je li Vaš kontaktni obrazac zaštićen. Zahtjev prvo stiže do PHP-ova jezgrenog dijela.

Prva greška, CVE-2026-109618, djeluje ovako:

1. Zahtjev stiže na adresu koju poslužuje PHP. Bez prijave, bez korisničkog računa.
2. PHP počinje čitati tijelo zahtjeva. CERT-EU kao primjer navodi obradu učitavanja datoteka putem obrasca.
3. PHP svoj memory_limit provodi pomoću longjmp(). Kad se ograničenje prekorači, skače iz onoga što je radio i završava zahtjev.
4. Ako se to dogodi usred postavljanja internih podataka zahtjeva, ti su podatci izgrađeni samo napola.
5. Čišćenje nakon toga neispravne podatke smatra ispravnima i oslobađa memoriju koja nikad nije inicijalizirana. Ta memorija još može sadržavati podatke iz ranijih alokacija koje je kontrolirao napadač.
6. Odatle upozorenje opisuje udaljeno izvršavanje koda na poslužitelju.

Namjerno ne opisujemo kako napadač usmjerava posljednji korak. Dovoljno je znati da ulazna točka nije Vaša aplikacija, a upravo zato ništa unutar Vaše aplikacije to ne može zaustaviti.

Druga greška: stanje koje nadživi svoju memoriju

CVE-2026-109619 je drugačiji mehanizam s istim ishodom. PHP za svaki zahtjev vodi interno stanje. Nakon određenih pogrešaka, primjerice kobne pogreške, to stanje može ostati iako je memorija ispod njega oslobođena. Sljedeći zahtjev koji obradi isti radni proces tada može upotrijebiti to zastarjelo stanje prije nego što se ono uobičajeno ponovno postavi. Napadaču trebaju dva zahtjeva koja završe na istom radnom procesu; CERT-EU ishod ocjenjuje jednako kao kod prve greške: udaljeno izvršavanje koda.

Što učiniti danas

1. Utvrdite koja verzija PHP-a doista poslužuje Vašu stranicu. php -v u naredbenom retku prikazuje verziju naredbenog retka, koja se može razlikovati od one koju koristi Vaš web-poslužitelj. Provjerite php-fpm -v, upravljačku ploču svog hostinga ili stranicu koja poziva phpinfo(). Na zajedničkom hostingu pitajte svog pružatelja usluge.
2. Ažurirajte na ispravljenu verziju: 8.5.12, 8.4.27, 8.3.36 ili 8.2.35. Distribucije često prenose ispravke bez promjene broja verzije, stoga u sigurnosnoj obavijesti svog dobavljača potražite oznake CVE. U kontejnerima ponovno izgradite sliku iz ažurirane osnovne slike. Tim PHP-a napominje da rpms.remirepo.net na dan izdanja nije imao ažuriranja te preporučuje pakete distribucije ili izgradnju iz izvornog koda.
3. Ponovno pokrenite sve PHP radne procese. Ažuriranje na disku ne mijenja procese koji već rade. Ponovno pokrenite PHP-FPM ili web-poslužitelj, a zatim ponovno provjerite verziju koja radi.
4. Ako danas ne možete ažurirati, izolirajte poslužitelj od javnih mreža dok ispravak ne bude postavljen i provjeren. CERT-EU jasno kaže da te greške u potpunosti otklanja samo ažuriranje.
5. Ako koristite PHP 8.1 ili stariji, od svog dobavljača zatražite povratni ispravak ili prijeđite na podržanu granu. Te verzije ne dobivaju redovita ažuriranja.

Zaobilazna rješenja koja smanjuju rizik, ali ne otklanjaju grešku

CERT-EU navodi mjere koje napad otežavaju. Izričito navodi da instalaciju ne čine sigurnom. Koristite ih dok pripremate ažuriranje, a ne umjesto njega.

• Protiv CVE-2026-109618: postavite memory_limit=-1 tako da ga aplikacije ne mogu nadjačati, primjerice pomoću php_admin_value u FPM skupu, te provjerite da nijedan skup, direktorij ili unos aplikacije ponovno ne postavlja konačno ograničenje. Postavite nizak post_max_size (8M bez učitavanja datoteka, 32M s njima) i držite upload_max_filesize ispod njega. Ograničite veličinu zahtjeva, broj polja, broj dijelova multiparta, broj zaglavlja i dubinu ugniježđenja na web-poslužitelju ili proxyju. Ograničenje memorije kontejnera ili cgroupa koristite kao granicu dostupnosti, ali ne RLIMIT_AS ili RLIMIT_DATA, koji mogu izazvati ranjivi neuspjeh alokacije.
• Protiv CVE-2026-109619: postavite session.upload_progress.enabled=0 u php.ini, FPM skupu ili konfiguraciji poslužitelja koja se primjenjuje prije obrade zahtjeva (ne pomoću ini_set() ili .user.ini) te ponovno pokrenite sve radne procese. Na PHP-u 8.5 postavite i fatal_error_backtraces=0. Uklonite neispravne ili zastarjele postavke po zahtjevu koje ispisuju dijagnostiku prije inicijalizacije te otklonite kobne pogreške i istekle vremenske limite izvršavanja do kojih napadač može doći.

Što SilentShield ovdje može, a što ne može

Ovo nije problem botova i radije to kažemo nego da stranica proizvoda nešto drugo nagovijesti. Napad pogađa PHP prije nego što zahtjev vidi bilo što naše ili bilo koji CAPTCHA, dodatak ili pravilo vatrozida unutar Vaše aplikacije. Zaštita od botova na obrascu to ne zaustavlja i nitko Vam ne bi smio reći da zaustavlja. Jedino potpuno rješenje je ažuriranje PHP-a.

API i nadzorna ploča SilentShielda nisu napisani u PHP-u. WordPress dodatak i PHP SDK rade unutar Vašeg vlastitog PHP-a, pa se za njih ažuriranje mora obaviti na Vašem poslužitelju. Nakon ažuriranja uobičajena zaštita od botova i neželjenih poruka putem obrazaca korisna je kao i prije; samo nikad nije bila odgovor na ovo.

Izvori

• CERT-EU Security Advisory 2026-018: Critical Vulnerabilities in PHP
• Najava PHP-a od 20. listopada 2026.
• GHSA-w8hw-w9fx-j79w (CVE-2026-109618)
• GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
• NCSC-NL php2shell: proizvodi koji ugrađuju PHP