Ukratko: Tko sam upravlja root poslužiteljem ili vServerom, mora ga nakon PHP2Shella i sam zaštititi: PHP pakete dovesti na ispravljeno stanje, ponovno pokrenuti sve PHP procese i provjeriti rezultat. Operater podatkovnog centra u pravilu se brine samo za hardver, virtualizaciju i mrežu. Nakon toga isplati se poslužitelj trajno ojačati.
Vaša odgovornost kod vlastitog poslužitelja
Kod neupravljanog root poslužitelja ili vServera iznajmljujete računalnu snagu, a ne održavanje. Operacijski sustav, web-poslužitelj, PHP, baza podataka, vatrozid, sigurnosne kopije i nadzor u Vašim su rukama. Za upravu i vlasnike to znači: ako te zadaće nitko u tvrtki ili kod davatelja usluga nije izričito preuzeo, ne obavlja ih nitko.
PHP2Shell to čini vidljivim. Dvije ranjivosti CVE-2026-109618 i CVE-2026-109619 nalaze se u samom PHP-u i omogućuju izvršavanje koda bez prijave. PHP projekt je 21. 10. 2026. objavio verzije 8.5.12, 8.4.27, 8.3.36 i 8.2.35. BSI (njemački Savezni ured za informacijsku sigurnost) preporučuje trenutačno ažuriranje i, ako to nije moguće, privremeno odvajanje web-poslužitelja s mreže.
Zaštita vServera: provjerite popis i stanje paketa
Najprije steknite pregled koje su PHP verzije instalirane i iz kojeg izvora potječu. Mnogi poslužitelji uz pakete distribucije koriste dodatne izvore paketa. Sljedeće naredbe samo čitaju. Nazivi paketa su primjeri.
# Debian/Ubuntu: instalirani PHP paketi i njihovo podrijetlo
apt list --installed 'php*' 2>/dev/null
apt-cache policy php8.3-fpm
# AlmaLinux/Rocky/RHEL
dnf list installed 'php*'
# Koji uopće postoje PHP binarni programi?
ls /usr/bin/php* /usr/sbin/php-fpm* 2>/dev/null
Sam broj verzije nije dovoljan. Distribucije sigurnosne ispravke često isporučuju kao backport, pa prikazani broj ostaje stariji. Odlučuje zapisnik promjena paketa.
# Debian/Ubuntu (naziv paketa kao primjer)
apt changelog php8.3-fpm 2>/dev/null | grep -iE 'CVE-2026-1096(18|19)'
# RHEL obitelj (naziv paketa kao primjer)
rpm -q --changelog php-fpm | grep -iE 'CVE-2026-1096(18|19)'
Opširne upute nalaze se u članku Provjera PHP verzije i stanja zakrpe.
Instalirajte ažuriranje i obnovite sve procese
Ažuriranja instalirajte putem upravitelja paketa, a zatim ponovno pokrenite svaku uslugu koja učitava PHP. Ovisno o izvedbi to su PHP-FPM, Apache s mod_php, LiteSpeed ili aplikacijski poslužitelj. Nove datoteke na disku nisu dovoljne dok stari procesi rade u memoriji.
# Pronađite usluge s PHP-om
systemctl list-units --type=service | grep -iE 'php|apache2|httpd|lsws'
# Prikažite procese s vremenom pokretanja
ps -eo pid,lstart,cmd | grep -E 'php|apache2|httpd' | grep -v grep
# Debian/Ubuntu: prepoznajte programe sa zastarjelim bibliotekama (ako je instalirano)
needrestart -r l
Svaki relevantan proces trebao bi biti pokrenut nakon ažuriranja. Na Debian sustavima koristan je alat needrestart koji prikazuje usluge sa zastarjelim bibliotekama. Pojedinosti o ponovnom pokretanju opisuje članak Ponovno pokretanje PHP-FPM-a i svih workera.
Zakrpa ne uklanja zlonamjerni softver koji je ubačen prije ažuriranja. Sačuvajte zapisnike web-poslužitelja od 20. 10. 2026. i provjerite poslužitelj zbog tragova prije nego što ga ocijenite čistim.
Za prvu potragu za tragovima prikladno je nekoliko provjera koje ništa ne mijenjaju. Tražite PHP datoteke koje su u web direktorijima nove ili izmijenjene od 17. 10. 2026., nepoznate unose u crontabovima svih korisnika, nove sistemske korisnike i SSH ključeve te procese korisnika web-poslužitelja koji drže odlazne veze.
# PHP datoteke izmijenjene od 17. 10. 2026. (putanja kao primjer)
find /var/www -type f -name '*.php' -newermt '2026-10-17' -ls
# Mrežne veze s pripadajućim procesom
ss -tupn
Nijedna od tih provjera sama po sebi ne dokazuje provalu, a prazan rezultat ne dokazuje suprotno. Ipak pokazuju je li potrebna dublja istraga. Radite na kopijama zapisnika i ne mijenjajte sumnjive datoteke dok se stanje ne osigura. Kod nalaza siguran je put uredna istraga. U tom slučaju poslužitelj nemojte jednostavno isključiti niti ga odmah postaviti iznova, jer se time gube tragovi važni za procjenu obveza prijave i za moguću prijavu policiji.
Trajno ojačajte poslužitelj
Nakon akutne zakrpe slijedi osnovna zaštita. Ona ne sprječava svaku ranjivost, ali ograničava štetu i skraćuje vrijeme reakcije idući put. Sljedeće se točke dokazale:
- Pristupi: SSH samo s ključem, bez izravne root prijave, upravljačka sučelja dostupna samo iz poznatih mreža.
- Vatrozid: otvoriti samo portove koji su stvarno potrebni, ograničiti odlazne veze web-poslužitelja.
- PHP konfiguracija: isključiti opasne funkcije,
open_basedirpo web-stranici, zasebni poolovi i korisnici po aplikaciji. - Prava nad datotekama: web-poslužitelj ne smije pisati u programski kod, direktoriji za upload ne izvršavaju PHP.
- Ažuriranja: sigurnosna ažuriranja instalirati automatski, ponovno pokretanje i kontrolu čvrsto planirati.
- Sigurnosne kopije: kopije prema pravilu 3-2-1, barem jedna kopija izvan poslužitelja i zaštićena od izmjene.
- Zapisnici: zapisnike prikupljati središnje i čuvati dovoljno dugo.
Kako izgleda pouzdana sigurnosna kopija opisuje članak Sigurnosne kopije prema pravilu 3-2-1. Kao okvir za tvrtke prikladan je IT-Grundschutz (njemački temeljni standard IT sigurnosti) BSI-ja.
Kada je upravljani poslužitelj bolji izbor
Vlastiti poslužitelj isplati se ako netko pouzdano preuzme održavanje: prati ažuriranja, procjenjuje situacije poput PHP2Shella, može reagirati i noću. Ako takvih kapaciteta nema, smislen je ili upravljani poslužitelj ili stalni ugovor o održavanju. U oba je slučaja važno odgovornosti zabilježiti pisanim putem. Više o tome u članku Upravljani poslužitelj: razjasnite odgovornost.
Kako PHP SOS konkretno pomaže?
- Popisujemo sve PHP instalacije, izvore paketa i usluge Vašeg poslužitelja te ocjenjujemo stvarno stanje zakrpe.
- Instaliramo ažuriranja, ponovno pokrećemo sve procese i dokumentiramo rezultat.
- Provjeravamo poslužitelj zbog tragova kompromitacije i osiguravamo zapisnike za kasniju analizu.
- U okviru našeg ojačavanja poslužitelja uredno postavljamo pristupe, vatrozid, PHP poolove i prava.
- Na zahtjev preuzimamo redovito održavanje putem ugovora o sigurnosnom održavanju.
Česta pitanja
Zakrpava li moj podatkovni centar vServer automatski?
Kod neupravljanih root poslužitelja i vServera u pravilu ne. Pružatelj osigurava hardver ili virtualizaciju i mrežu, a operacijskim sustavom i svim uslugama na njemu upravljate sami. U slučaju sumnje provjerite svoj ugovor.
Jesu li automatska sigurnosna ažuriranja dovoljna?
Pomažu, ali ne zamjenjuju kontrolu. Automatska ažuriranja ne pokreću uvijek ponovno PHP procese koji rade i često ne pokrivaju pakete iz vanjskih izvora. Nakon svakog sigurnosnog ažuriranja provjerite stanje paketa i vremena pokretanja procesa.
Kako saznati sadrži li moj paket backport?
U zapisniku promjena paketa i u sigurnosnim obavijestima Vaše distribucije. Ako je tamo navedena CVE oznaka, ispravak je ugrađen, iako broj verzije djeluje starije. Ako unosa nema, razjasnite stanje prije nego što poslužitelj ocijenite zakrpanim.
Što učiniti ako za moju PHP verziju zakrpa neće doći?
PHP 8.1 i starije više ne primaju službena ažuriranja. Postavite privremene mjere prema php.net-u, brzo planirajte prelazak na podržanu verziju i prema preporuci BSI-ja poslužitelj po potrebi privremeno odvojite s mreže.