Ukratko: Na RHEL-u, AlmaLinuxu i Rocky Linuxu PHP zakrpu protiv PHP2Shella provjeravate na tri načina: sigurnosnim objavama distribucije (dnf updateinfo), changelogom paketa (rpm -q --changelog) i vremenom pokretanja PHP procesa. Red Hat navodi RHEL 7 do 10 kao pogođene i pri dohvatu je javio da su neka ažuriranja dostupna, a druga u izradi. Nakon ažuriranja vrijedi: pokrenuti potpuno ponovno, a ne samo ponovno učitati.
Što je Red Hat objavio o PHP2Shellu
Red Hat je o PHP2Shellu izdao sigurnosni bilten RHSB-2026-013. Dohvatili smo ga 25. listopada 2026. Najvažnije točke za administratore:
- Pogođeni su RHEL 10, 9, 8 i 7 te proizvodi i containeri na njima temeljeni na RHEL ili UBI imageima.
- RHEL 7 je prema Red Hatu pogođen samo s CVE-2026-109619; kod za CVE-2026-109618 tamo nije sadržan.
- Nisu pogođeni sustavi bez PHP-a ili s PHP-om koji ne obrađuje nepouzdane HTTP zahtjeve.
- Ažuriranja: Neka su pri dohvatu bila dostupna, druga u izradi. Konkretne brojeve errata bilten nije naveo, nego je uputio na stranice errata.
Red Hat CVE-2026-109618 vlastitom metodom ocjenjuje kao „Important“ i upućuje na to da standardne instalacije od RHEL-a 8 koriste PHP-FPM umjesto mod_php. To je razvrstavanje, a ne otklanjanje uzbune. PHP projekt obje ranjivosti ocjenjuje s CVSS v4.0 9.2, a BSI (njemački Savezni ured za informacijsku sigurnost) preporučuje trenutačno ažuriranje.
AlmaLinux i Rocky Linux: isti izvor, vlastiti takt
AlmaLinux i Rocky Linux svoje pakete grade iz izvora Red Hata. Ispravci zato u pravilu stižu istovjetni po sadržaju, ali u vlastito vrijeme i pod vlastitim sigurnosnim objavama. Napomena o Red Hat erratu ne znači da je paket kod Vašeg derivata dostupan istoga dana.
Odlučujuće je stoga stanje na Vašem sustavu. Provjerite ga alatima upravljanja paketima, a ne prema vijestima ili forumima.
Pazite i koriste li se na poslužitelju zrcalni poslužitelji ili interni izvori paketa. U mnogim tvrtkama poslužitelji ažuriranja ne dohvaćaju izravno od proizvođača, nego putem internog zrcala ili alata za upravljanje. Ako to zrcalo nije aktualno, dnf ne nalazi nove pakete iako su odavno objavljeni.
Provjera PHP zakrpe na RHEL-u i derivatima
Sljedeće naredbe samo čitaju. Nazivi paketa vrijede za PHP pakete distribucije; paketi iz izvora trećih strana poput Remija djelomično se zovu drukčije.
# Koje PHP streamove sustav poznaje, koji je aktivan? (RHEL 8 i 9)
dnf module list php
# Instalirani PHP paketi s verzijom i podrijetlom
rpm -qa 'php*' --qf '%{NAME}-%{VERSION}-%{RELEASE} %{VENDOR}\n' | sort
# Postoje li sigurnosne objave za CVE-ove za ovaj sustav?
dnf updateinfo list --cve CVE-2026-109618
dnf updateinfo list --cve CVE-2026-109619
# Stoji li ispravak u changelogu instaliranog paketa?
rpm -q --changelog php-fpm | grep -E "CVE-2026-10961[89]"
dnf updateinfo prikazuje samo objave za ažuriranja koja još nisu instalirana; s --installed vidite i već instalirana. Prazan rezultat dakle može značiti dvoje: ažuriranje je već instalirano ili još nije objavljeno. Usporedba s changelogom to razjašnjava. Kako rezultat zabilježiti kao dokaz, opisuje članak Dokazati CVE brojeve u changelogu paketa.
Kao i kod drugih poslovnih distribucija, paket najčešće zadržava izvornu PHP verziju; mijenja se samo oznaka izdanja. Starija oznaka kod php -v stoga nije naznaka da ispravak nedostaje. Opće napomene o provjeri verzije nalaze se na stranici Ispravno provjeriti PHP verziju i razinu zakrpe.
Prepoznati ispravan način rada
Red Hat navodi standardne načine rada: od RHEL-a 8 PHP radi preko PHP-FPM-a, a na RHEL-u 7 kao mod_php u Apache usluzi httpd. Mnogi poslužitelji od toga odstupaju, primjerice zbog panela, izvora trećih strana ili starih konfiguracija.
| Sustav | Standard prema Red Hatu | Ponovno pokretanje nakon ažuriranja |
|---|---|---|
| RHEL 8, 9, 10 i derivati | PHP-FPM | systemctl restart php-fpm |
| RHEL 7 | mod_php u httpd | systemctl restart httpd |
| Containeri na RHEL ili UBI osnovi | ovisno o imageu | Ponovno izgraditi image, zamijeniti container |
Za containere Red Hat preporučuje da se nakon ažuriranih osnovnih imagea ponovno izgrade vlastiti imagei te zamijene pokrenuti containeri ili podovi. Ažuriranje u pokrenutom containeru nije pouzdan put.
Nakon ažuriranja: ponovno pokretanje i kontrola
Red Hat naglašava da reload nije dovoljan. Postojeći workeri mogu zadržati pogođeno stanje. Zato ponovno pokrenite svaku uslugu koja učitava PHP i provjerite rezultat:
# Prikaži usluge sa zastarjelim bibliotekama (dnf-utils odnosno dnf-plugins-core)
needs-restarting -s
# Usporedi vrijeme pokretanja PHP procesa s vremenom ažuriranja
ps -eo pid,lstart,cmd | grep -E "[p]hp-fpm|[h]ttpd"
Za konfiguraciju Red Hat ima praktičnu napomenu: php -i prikazuje postavke naredbenog retka, a ne web-poslužitelja. Tko želi provjeriti djeluju li prijelazne vrijednosti poput session.upload_progress.enabled=0 u web-kontekstu, kratkotrajno koristi zaštićenu phpinfo stranicu i potom je briše. Na što još paziti pri ponovnom pokretanju, navodi stranica Ponovno pokretanje PHP-FPM-a i svih workera.
Prijelazne mjere: napomene Red Hata
Gdje ažuriranja još nema, Red Hat upućuje na iste prijelazne mjere kao php.net i dodaje nekoliko praktičnih napomena za RHEL sustave. One ne zamjenjuju ažuriranje.
- Redak doista dodati: Prema Red Hatu redak za
session.upload_progress.enabledu isporučenoj konfiguraciji je zakomentiran, dakle funkcija je standardno aktivna. Vrijednost0mora se izričito postaviti. - Postaviti tako da se ne može nadjačati: putem
php_admin_valueu PHP-FPM poolu, kod mod_php u Apache konfiguraciji. Ne putemini_set()ili.user.ini. - Tražiti protivnike: Red Hat preporučuje provjeriti
.htaccessdatoteke, VirtualHostove i.user.inidatoteke ponovno uključuju li pogođene postavke. - Granice postaviti i ispred: Uz
post_max_sizeu PHP-u Red Hat savjetuje razmotriti ograničenja veličine zahtjeva i u web-poslužitelju ili proxyju.
Na PHP-FPM sustavima poolovi su u pravilu u /etc/php-fpm.d/. Nakon svake promjene vrijedi isto kao nakon ažuriranja: potpuno ponovno pokrenuti sve workere.
Ako na istom poslužitelju dodatno radi PHP iz Remi repozitorija, za njega vrijede vlastiti paketi i usluge. Pročitajte o tome članak Repozitorij Remi.
Kako PHP SOS konkretno pomaže?
- Na RHEL-u, AlmaLinuxu i Rocky Linuxu provjeravamo sve PHP pakete, streamove i izvore trećih strana te ih uspoređujemo sa sigurnosnim objavama.
- Instaliramo ažuriranja, potpuno ponovno pokrećemo sve workere i kontroliramo vremena pokretanja procesa.
- Za container okruženja ponovno gradimo imagee i kontrolirano zamjenjujemo pokrenute instance.
- Stanje po poslužitelju bilježimo u dokazu PHP usluge zakrpa.
Česta pitanja
Je li RHEL 7 pogođen PHP2Shellom?
Prema Red Hatu RHEL 7 pogođen je samo CVE-2026-109619, a ranjivi kod za CVE-2026-109618 tamo nije prisutan. Na RHEL-u 7 mod_php je standardni način rada, koji PHP tim ocjenjuje posebno rizičnim.
Zašto Red Hat ranjivost ocjenjuje nižom ocjenom od php.net-a?
Red Hat koristi vlastitu ocjenu prema CVSS v3.1 i CVE-2026-109618 razvrstava kao Important jer iskorištavanje zahtijeva točan timing. php.net ocjenjuje s CVSS v4.0 9.2. Oboje smatraju izvršavanje koda bez prijave mogućim, ažuriranje je u svakom slučaju potrebno.
Dobivaju li AlmaLinux i Rocky Linux ispravke automatski?
Oba svoje pakete grade iz izvora Red Hata i objavljuju vlastite sigurnosne objave. Vrijeme može odstupati od Red Hata. Zato stanje provjerite na vlastitom sustavu i u objavama svoje distribucije.
Je li systemctl reload php-fpm dovoljan nakon ažuriranja?
Ne. Red Hat izričito upozorava da reload nije dovoljan jer postojeći workeri mogu zadržati pogođeno stanje. Ponovno pokrenite sve workere, kod mod_php Apache uslugu httpd.