PHP je 21. listopada 2026. objavio sigurnosne zakrpe za dvije kritične ranjivosti koje mogu omogućiti udaljeno izvršavanje koda na poslužitelju bez autentifikacije. Obje su ocijenjene s 9,2 prema sustavu CVSS v4.0. Sigurnosne tvrtke prijavile su prve pokušaje iskorištavanja, ali broj uspješno kompromitiranih sustava nije potvrđen.
Prema službenoj objavi PHP projekta, najveći je rizik utvrđen kod određenih konfiguracija Apachea, gdje se napad može pokrenuti prije izvršavanja koda web-aplikacije.
Za tvrtke koje koriste web-stranice i internetske trgovine sada je ključno provjeriti je li sigurnosni ispravak primijenjen na PHP okruženje u kojem njihova aplikacija stvarno radi. Ažuriranje WordPressa ili drugog sustava za upravljanje sadržajem samo po sebi ne uklanja ranjivost u PHP-u.
Koje PHP verzije imaju sigurnosne zakrpe?
Ranjivosti su označene kao CVE-2026-109618 i CVE-2026-109619. PHP je objavio četiri sigurnosna izdanja.
| PHP grana | Prva verzija sa zakrpom |
|---|---|
| PHP 8.5 | 8.5.12 |
| PHP 8.4 | 8.4.27 |
| PHP 8.3 | 8.3.36 |
| PHP 8.2 | 8.2.35 |
Pogođene i zakrpane verzije navedene su u službenim upozorenjima za CVE-2026-109618 i CVE-2026-109619.
Za starije grane PHP 7.4, 8.0 i 8.1 sigurnosni tim iznimno je pripremio ograničene ispravke izvornog koda. To ne znači da su te verzije ponovno dobile redovitu podršku.
Linux distribucije i dobavljači sustava s dugoročnom podrškom mogu uključiti sigurnosne ispravke u vlastite pakete. Zato oznaka PHP verzije nije uvijek dovoljan dokaz da je poslužitelj nezaštićen. Potrebno je provjeriti i sigurnosne objave dobavljača.
Zašto su ove ranjivosti posebno opasne?
Obje ranjivosti povezane su s upravljanjem memorijom u samom PHP-u.
Kod CVE-2026-109618 problem nastaje kada nedostatak memorije prekine obradu zahtjeva prije potpune inicijalizacije internih podataka. Naknadna obrada može pristupiti nevaljanom memorijskom stanju.
CVE-2026-109619 odnosi se na stanje koje može ostati dostupno nakon oslobađanja memorije prethodnog zahtjeva. Za iskorištavanje je potreban slijed operacija u kojem isti radni proces obrađuje novi zahtjev i pristupa tom stanju prije njegove pravilne ponovne inicijalizacije.
PHP je potvrdio demonstrirani napad bez autentifikacije na Apacheu s modulom mod_php. Napad se u toj konfiguraciji može aktivirati prije nego što aplikacija počne izvršavati vlastiti kod.
Kod PHP-FPM-a nalazi se razlikuju. Za prvu ranjivost utvrđena je moguća izloženost, ali nije demonstriran potpun napad na taj način rada. Za drugu su opisani i scenariji iskorištavanja povezani s PHP-FPM-om.
Zbog toga se ne može tvrditi da su sve PHP instalacije jednako izložene. Rizik ovisi o verziji, konfiguraciji i načinu obrade zahtjeva.
Što je potvrđeno o prijavljenim napadima?
Sigurnosna tvrtka Patchstack objavila je da je 21. listopada u 07:34 UTC od više hosting partnera zaprimila prijave aktivnog iskorištavanja ranjivosti.
Nekoliko minuta poslije tehnički direktor Cloudflarea Dane Knecht izvijestio je da tvrtka uočava prve napade i da je uvela početna zaštitna pravila. Cloudflare je u svojem tehničkom izvješću dodatno opisao zabilježeni napadački promet i zaštitne mjere.
Nakon objave zakrpa Patchstack je dopunio svoju vremensku crtu. Prema podacima iz 13:57 UTC, njegova telemetrija bilježila je pokušaje ispitivanja ranjivosti, ali nije pružala čvrste dokaze uspješnih kompromitacija.
To ne pobija ranije prijave hosting partnera, ali pokazuje zašto treba razlikovati pokušaj napada od potvrđenog preuzimanja sustava.
Tko je odgovoran ako je WordPress ažuriran, a PHP nije?
Za vlasnike poslovnih web-stranica sigurnosni problem ne završava ažuriranjem aplikacije.
WordPress, WooCommerce, Drupal, Joomla, Magento i Laravel koriste PHP. Njihove nadogradnje ne moraju uključivati i sigurnosne ispravke PHP-a na poslužitelju.
Tvrtka tako može imati ažuriran WordPress i sve dodatke, a njezina stranica i dalje može raditi na nezakrpanom PHP okruženju.
Tko je odgovoran za nadogradnju ovisi o ugovorenoj usluzi. Kod dijeljenog hostinga pružatelj usluge obično upravlja poslužiteljskim PHP okruženjem, dok kod vlastitih ili posebno administriranih poslužitelja tu obvezu može imati interni administrator ili vanjski izvođač.
Web-agencija koja održava sadržaj i dodatke pritom ne mora imati ovlasti za promjenu PHP konfiguracije.
Zato potvrda da je web-stranica ažurirana nije dovoljna. Potrebno je utvrditi tko održava PHP, koja je zakrpa primijenjena i koristi li je aktivna aplikacija.
Kod internetskih trgovina postoji i dodatna obveza: nakon nadogradnje treba provjeriti naručivanje, naplatu i povezivanje s vanjskim servisima. Promjena PHP okruženja može otkriti probleme kompatibilnosti s postojećim dodacima.
Koliko je zastarjelih PHP poslužitelja na internetu?
Prema analizi sigurnosne tvrtke Mallory, među 1.495.986 javno vidljivih poslužiteljskih zapisa s informacijom o PHP verziji njih 883.717 upućivalo je na PHP 8.1 ili stariju granu.
To je približno 59,1 posto analiziranog uzorka.
Podatak pokazuje prisutnost starijih PHP verzija, ali ne predstavlja broj poslužitelja za koje je potvrđeno da su ranjivi na PHP2Shell. Javno prikazana verzija ne otkriva uvijek jesu li primijenjeni sigurnosni ispravci dobavljača.
Iz te analize nije moguće izvesti ni pouzdanu procjenu broja ugroženih web-stranica u Bosni i Hercegovini.
Što ako hosting još nije primijenio zakrpu?
PHP-ov sigurnosni tim objavio je privremene konfiguracijske mjere koje mogu smanjiti izloženost pojedinim načinima napada.
Među njima je isključivanje funkcionalnosti session.upload_progress.enabled, ali PHP upozorava da takva promjena ne uklanja sve mogućnosti iskorištavanja. Potpuna zaštita od poznatih ranjivosti zahtijeva primjenu odgovarajućih sigurnosnih ispravaka.
CERT-EU u sigurnosnom upozorenju preporučuje organizacijama da provjere sve PHP instalacije, uključujući razvojna i testna okruženja, te primijene dostupne sigurnosne zakrpe.
Za javno dostupne sustave koje nije moguće odmah zakrpati CERT-EU je preporučio razmatranje privremenog ograničavanja pristupa internetu.
Nakon primjene ispravka administrator treba provjeriti aktivno PHP okruženje i ponovno pokrenuti odgovarajuće procese kada to zahtijeva postupak nadogradnje.
Ako postoje pokazatelji ranijeg napada, potrebna je i zasebna sigurnosna provjera. Instalacija zakrpe sama po sebi ne utvrđuje je li poslužitelj prethodno bio kompromitiran.
Ima li potvrđenih napada u Bosni i Hercegovini?
Za Bosnu i Hercegovinu do 21. listopada 2026. u pregledanim javno dostupnim izvorima nisu pronađene vjerodostojno potvrđene informacije o uspješnim napadima povezanima s ranjivostima CVE-2026-109618 i CVE-2026-109619.
Nema ni pouzdane javne procjene broja domaćih poslužitelja koji koriste zahvaćene PHP verzije bez odgovarajućih sigurnosnih ispravaka.
To ne dokazuje da pokušaja napada ili kompromitacija nije bilo.
Vlasnicima poslovnih web-stranica u BiH zato je najkorisnija konkretna potvrda pružatelja hostinga: koji je sigurnosni ispravak primijenjen i na kojem PHP okruženju njihova stranica stvarno radi.
Napomena uredništva: Članak je ažuriran 21. listopada 2026. nakon službene objave PHP-ovih sigurnosnih zakrpa.
Autor: financa.ba
Prilikom preuzimanja obvezno navesti izravnu poveznicu na članak.
