Ukratko: Nakon PHP2Shella sama prikazana verzija PHP-a malo dokazuje jer pružatelji hostinga ispravke često ugrađuju kao backport. Zato zatražite pisanu potvrdu PHP ažuriranja od pružatelja hostinga: stanje paketa po PHP grani, trenutak instalacije i ponovno pokretanje svih PHP procesa. Predložak za kopiranje nalazi se u nastavku.
Zašto je pisana potvrda važna upravo sada
PHP projekt je 21.10.2026. objavio zakrpe za dvije kritične ranjivosti poznate pod imenom PHP2Shell. Obje omogućuju izvršavanje zlonamjernog koda izdaleka bez prijave. BSI (njemački Savezni ured za sigurnost informacijske tehnologije) proglasio je razinu upozorenja 3 / narančasta i preporučuje hitno ažuriranje.
Tko web-stranicu vodi kod pružatelja hostinga, često ne može sam primijeniti ažuriranje. Istodobno kao operater snosite odgovornost za podatke svojih klijenata. Pisana, konkretna potvrda pružatelja stoga je više od formalnosti. Ona je sastavni dio Vaše dokumentacije, primjerice prema službenicima za zaštitu podataka, osiguravateljima ili upravi.
Uz to: zakrpa ne uklanja zlonamjerni softver koji je prethodno ubačen. Prema medijskim izvješćima već je 17.10. opažen prvi pokušaj napada. Točan trenutak od kojeg je Vaš poslužitelj bio zaštićen stoga je važan za pitanje morate li dalje provjeravati.
Zašto prikazana verzija PHP-a nije dovoljna
Ispravljene su verzije PHP 8.5.12, 8.4.27, 8.3.36 i 8.2.35. Mnoge distribucije i pružatelji hostinga ispravak ipak preuzimaju kao backport u vlastiti paket. Tada sučelje poput Plesk i dalje prikazuje 8.2.34 iako je poslužitelj zakrpan.
Obrnuto, ispravan broj verzije može zavarati. Nove datoteke same ne štite dok stari PHP procesi rade u memoriji. Tek nakon ponovnog pokretanja svih workera aktivno je novo stanje. Više u članku Ispravna provjera verzije PHP-a i razine zakrpe.
| Izjava pružatelja | Što dokazuje | Što još nedostaje |
|---|---|---|
| „Svi sustavi su ažurni.“ | malo | Verzija ili stanje paketa, datum, ponovno pokretanje |
| „PHP 8.3.36 je instaliran.“ | Verzija | Datum, ponovno pokretanje, pogođeni poslužitelji |
| „Backport u paketu xy, ponovno pokretanje dana …“ | Zakrpa i aktivacija | po potrebi podaci o PHP-u 8.1 i starijem |
Koje podatke trebate od pružatelja hostinga
Zatražite odgovore na ove točke, ako je moguće po web-stranici ili ugovoru:
- Koje su PHP grane i verzije aktivne za Vaše web-stranice, i starije koje rade samo za pojedine direktorije?
- Jesu li ispravci za CVE-2026-109618 i CVE-2026-109619 uključeni, kao službena verzija ili kao backport?
- Kada je ažuriranje instalirano i kada su ponovno pokrenuti svi PHP procesi (FPM poolovi, Apache, LiteSpeed)?
- Je li
session.upload_progress.enabledzbog CVE-2026-115560 isključen? - Koji način rada koristi Vaš paket, primjerice PHP-FPM ili Apache s mod_php? Kod mod_php-a PHP tim vidi najveći rizik.
- Koji se logovi pristupa i pogrešaka od 20.10.2026. čuvaju i kako ih možete dobiti?
Ako neka web-stranica još radi na PHP-u 8.1 ili starijem, pitajte zasebno. Za te grane više nema službenih ažuriranja, samo minimalni backportovi izvornog koda za 7.4, 8.0 i 8.1.
Predložak: zatražite potvrdu PHP ažuriranja od hostinga
Kopirajte tekst u tiket podrške ili e-poruku svom pružatelju hostinga. Dopunite podatke u uglatim zagradama.
Predmet: Molba za potvrdu stanja PHP zakrpe (PHP2Shell, CVE-2026-109618 / CVE-2026-109619)
Poštovani,
kod Vas imamo sljedeće web-stranice / ugovore:
[Korisnički broj, ugovor, domene]
U vezi s PHP sigurnosnim ranjivostima CVE-2026-109618 i
CVE-2026-109619 (PHP2Shell, zakrpe od 21.10.2026.) te obavijesti
o CVE-2026-115560 od 23.10.2026. molimo pisanu potvrdu
sljedećih točaka:
1. Koje su PHP verzije odnosno stanja paketa aktivne za naše web-stranice?
2. Sadrže li one ispravke (službena verzija ili backport)?
3. Datum i vrijeme instalacije.
4. Datum i vrijeme ponovnog pokretanja svih PHP procesa (FPM, Apache,
LiteSpeed i sl.).
5. Je li session.upload_progress.enabled isključen na razini poslužitelja?
6. Koji se PHP način rada koristi (npr. PHP-FPM, mod_php)?
7. Čuvaju li se logovi pristupa i pogrešaka od 20.10.2026. i
kako ih možemo dobiti?
8. Ako neka web-stranica još koristi PHP 8.1 ili stariji: Koja zaštita
tamo postoji i koji prelazak preporučujete?
Ove podatke trebamo za vlastitu internu dokumentaciju.
Hvala Vam i srdačan pozdrav
[Ime, tvrtka, funkcija]
Kako ispravno ocijeniti odgovor i sami ga provjeriti
Dobar odgovor navodi konkretna stanja, datume i vremena. Opće formulacije poput „reagirali smo“ nisu dovoljne za Vašu dokumentaciju. U tom slučaju ljubazno pitajte za točke koje nedostaju.
Ako Vaš paket to dopušta, dodatno provjerite i sami. S SSH pristupom obično su dovoljne ove naredbe:
# Verzija naredbenog retka (može se razlikovati od web-verzije)
php -v
# Stanje paketa na Debianu/Ubuntuu
dpkg -l | grep -E "php[0-9.]*-(fpm|cli|common)"
# Stanje paketa na RHEL, Alma, Rocky
rpm -qa | grep -i php
# Od kada rade PHP-FPM procesi?
ps -eo pid,lstart,cmd | grep "[p]hp-fpm"
Ako je vrijeme pokretanja PHP procesa prije potvrđenog datuma instalacije, ponovno pokretanje nije bilo potpuno.
Ako pružatelj hostinga ne odgovori ili odgovara izbjegavajući
Ako odgovor izostane ili nedostaju ključni podaci, stanje ne smijete smatrati razjašnjenim. BSI preporučuje privremeno isključiti web-poslužitelje s mreže ako ažuriranje nije odmah moguće. Je li to za Vašu web-stranicu razmjerno, odlučuje uprava, idealno pisano i s datumom.
Usporedno se isplati pogledati moguće tragove napada jer trenutak zakrpe ostaje otvoren. Uporišta daje članak Jesam li već kompromitiran?. Bez SSH pristupa pisana potvrda ostaje Vaš najvažniji dokaz. Koje su obveze kod pružatelja, a koje kod Vas, objašnjava stranica Shared hosting: što radi pružatelj; za upravljane poslužitelje pomaže Upravljani poslužitelj: razjasnite odgovornost.
Upit, odgovor i vlastite rezultate provjere pohranite s datumom u jednu mapu. Ta će mapa kasnije pomoći kod pitanja osiguravatelja ili službenika za zaštitu podataka.
Kako PHP SOS konkretno pomaže?
- S Vama formuliramo upit pružatelju hostinga i stručno ocjenjujemo odgovor.
- Gdje postoji pristup, sami provjeravamo stanje paketa, aktivni način rada i ponovno pokretanje PHP procesa.
- Ako ostanu praznine, provodimo privremene mjere ili planiramo prelazak na podržanu verziju.
- Rezultat i trenutke bilježimo u dokazu koji možete proslijediti interno.
Kako ažuriranje s ponovnim pokretanjem i dokazom teče, opisuje naša PHP usluga zakrpa.
Česta pitanja
Je li dovoljno da moj pružatelj hostinga napiše da je sve ažurno?
Za Vašu dokumentaciju vjerojatno nije. Zatražite konkretne podatke: stanje paketa ili verziju po PHP grani, datum instalacije i datum ponovnog pokretanja svih PHP procesa. Tek time možete suziti razdoblje ranjivosti.
Zašto moje hosting sučelje i dalje prikazuje PHP 8.2.34?
Distribucije i pružatelji hostinga sigurnosne ispravke djelomično ugrađuju kao backport, bez promjene broja verzije. Plesk tada može i dalje prikazivati 8.2.34 iako je poslužitelj zakrpan. Jasnoću daje samo potvrda pružatelja o stanju paketa.
Što učiniti ako pružatelj hostinga ne odgovori?
Dokumentirajte svoj upit s datumom i nakon razumnog vremena ponovno pitajte. Usporedno provjerite možete li sami postaviti privremene mjere te s upravom dogovorite hoće li se web-stranica do razjašnjenja isključiti s mreže, kako BSI preporučuje za nezakrpane poslužitelje.
Zatvara li ažuriranje WordPressa ili shopa također ranjivost?
Ne. PHP2Shell je u samom PHP-u. Ažuriranje CMS-a ili softvera shopa ne mijenja PHP interpreter koji radi na poslužitelju.