Na kratko: Na RHEL, AlmaLinux in Rocky Linux popravek PHP proti PHP2Shell preverite na tri načine: prek varnostnih obvestil distribucije (dnf updateinfo), prek changeloga paketa (rpm -q --changelog) in prek časa zagona procesov PHP. Red Hat RHEL 7 do 10 vodi kot prizadete in je ob poizvedbi javil, da so nekatere posodobitve na voljo, druge v delu. Po posodobitvi velja: v celoti znova zagnati, ne le znova naložiti.
Kaj je Red Hat objavil o PHP2Shell
Red Hat je o PHP2Shell izdal varnostni bilten RHSB-2026-013. Poizvedeli smo ga 25. oktobra 2026. Najpomembnejše točke za skrbnike:
- Prizadeti so RHEL 10, 9, 8 in 7 ter izdelki, zgrajeni na njih, in containerji na podlagi image RHEL ali UBI.
- RHEL 7 je po Red Hat prizadet samo zaradi CVE-2026-109619; kode za CVE-2026-109618 tam ni.
- Neprizadeti so sistemi brez PHP ali s PHP, ki ne obdeluje nezaupanja vrednih zahtev HTTP.
- Posodobitve: Nekatere so bile ob poizvedbi na voljo, druge v delu. Bilten konkretnih številk errata ni navedel, ampak je napotil na strani errata.
Red Hat CVE-2026-109618 z lastno metodo ocenjuje kot „Important“ in opozarja, da standardne namestitve od RHEL 8 naprej uporabljajo PHP-FPM namesto mod_php. To je uvrstitev, ne razglasitev odprave nevarnosti. Projekt PHP obe ranljivosti ocenjuje s CVSS v4.0 9,2, BSI (nemški zvezni urad za informacijsko varnost) pa priporoča takojšnjo posodobitev.
AlmaLinux in Rocky Linux: isti vir, lasten ritem
AlmaLinux in Rocky Linux svoje pakete gradita iz izvorne kode Red Hata. Popravki zato praviloma prispejo vsebinsko enaki, a ob lastnem času in pod lastnimi varnostnimi obvestili. Sklic na errata Red Hata ne pomeni, da je paket pri vašem klonu na voljo isti dan.
Odločilno je zato stanje na vašem sistemu. Preverite ga z orodji upravljanja paketov, ne s pomočjo novic ali forumov.
Pazite tudi, ali strežnik uporablja zrcalne strežnike ali notranje vire paketov. V mnogih podjetjih strežniki posodobitve ne jemljejo neposredno od proizvajalca, ampak prek notranjega zrcala ali orodja za upravljanje. Če to zrcalo ni aktualno, dnf ne najde novih paketov, čeprav so že zdavnaj objavljeni.
Preverjanje popravka PHP na RHEL in klonih
Naslednji ukazi so zgolj za branje. Imena paketov veljajo za pakete PHP distribucije; paketi iz virov tretjih ponudnikov, kot je Remi, se včasih imenujejo drugače.
# Katere tokove PHP sistem pozna, kateri je aktiven? (RHEL 8 in 9)
dnf module list php
# Nameščeni paketi PHP z različico in izvorom
rpm -qa 'php*' --qf '%{NAME}-%{VERSION}-%{RELEASE} %{VENDOR}\n' | sort
# Ali obstajajo varnostna obvestila za CVE za ta sistem?
dnf updateinfo list --cve CVE-2026-109618
dnf updateinfo list --cve CVE-2026-109619
# Ali je popravek v changelogu nameščenega paketa?
rpm -q --changelog php-fpm | grep -E "CVE-2026-10961[89]"
dnf updateinfo prikaže samo obvestila za posodobitve, ki še niso nameščene; z --installed vidite tudi že nameščena. Prazen rezultat torej lahko pomeni dvoje: posodobitev je že noter ali še ni objavljena. Primerjava changeloga to razjasni. Kako rezultat zabeležite kot dokazilo, opisuje prispevek Dokazovanje številk CVE v changelogu paketa.
Tako kot pri drugih podjetniških distribucijah paket praviloma obdrži prvotno različico PHP; spremeni se samo oznaka izdaje. Starejša številka pri php -v zato ni znak manjkajočega popravka. Splošne napotke za preverjanje različice najdete pod Pravilno preverjanje različice PHP in stanja popravkov.
Prepoznajte pravi način delovanja
Red Hat navaja standardne načine delovanja: od RHEL 8 naprej PHP teče prek PHP-FPM, na RHEL 7 kot mod_php v storitvi Apache httpd. Mnogi strežniki od tega odstopajo, na primer zaradi panelov, tujih virov ali starih konfiguracij.
| Sistem | Standard po Red Hat | Ponovni zagon po posodobitvi |
|---|---|---|
| RHEL 8, 9, 10 in kloni | PHP-FPM | systemctl restart php-fpm |
| RHEL 7 | mod_php v httpd | systemctl restart httpd |
| Containerji na osnovi RHEL ali UBI | glede na image | Image znova zgraditi, containerje zamenjati |
Za containerje Red Hat priporoča, da se po posodobljenih osnovnih image znova zgradijo lastni image in zamenjajo tekoči containerji ali podi. Posodobitev v tekočem containerju ni zanesljiva pot.
Po posodobitvi: ponovni zagon in kontrola
Red Hat poudarja, da reload ne zadošča. Obstoječi workerji lahko obdržijo prizadeto stanje. Zato znova zaženite vsako storitev, ki nalaga PHP, in preverite rezultat:
# Prikaži storitve z zastarelimi knjižnicami (dnf-utils oziroma dnf-plugins-core)
needs-restarting -s
# Čas zagona procesov PHP primerjaj s časom posodobitve
ps -eo pid,lstart,cmd | grep -E "[p]hp-fpm|[h]ttpd"
Za konfiguracijo ima Red Hat praktičen napotek: php -i prikaže nastavitve ukazne vrstice, ne spletnega strežnika. Kdor želi preveriti, ali prehodne vrednosti, kot je session.upload_progress.enabled=0, v spletnem kontekstu veljajo, za kratek čas uporabi zaščiteno stran phpinfo in jo nato izbriše. Na kaj je sicer treba paziti pri ponovnem zagonu, je opisano pod Ponovni zagon PHP-FPM in vseh workerjev.
Prehodni ukrepi: napotki Red Hata
Kjer posodobitve še ni, Red Hat napoti na iste prehodne ukrepe kot php.net in dodaja nekaj praktičnih napotkov za sisteme RHEL. Posodobitve ne nadomestijo.
- Vrstico res dopolniti: Po Red Hat je vrstica za
session.upload_progress.enabledv dobavljeni konfiguraciji zakomentirana, funkcija je torej privzeto aktivna. Vrednost0je treba izrecno nastaviti. - Nastaviti tako, da je ni mogoče prepisati: prek
php_admin_valuev poolu PHP-FPM, pri mod_php v konfiguraciji Apache. Ne prekini_set()ali.user.ini. - Poiskati nasprotnike: Red Hat priporoča, da se datoteke
.htaccess, VirtualHost in.user.inipreverijo, ali prizadete nastavitve spet vklapljajo. - Meje nastaviti tudi pred tem: Poleg
post_max_sizev PHP Red Hat svetuje, da se omejitve velikosti zahtev razmislijo tudi v spletnem strežniku ali proxyju.
Na sistemih PHP-FPM so pooli praviloma pod /etc/php-fpm.d/. Po vsaki spremembi velja enako kot po posodobitvi: vse workerje v celoti znova zagnati.
Če na istem strežniku poleg tega teče PHP iz repozitorija Remi, zanj veljajo lastni paketi in storitve. O tem preberite prispevek Repozitorij Remi.
Kako konkretno pomaga PHP SOS?
- Na RHEL, AlmaLinux in Rocky Linux preverimo vse pakete PHP, tokove in tuje vire ter jih primerjamo z varnostnimi obvestili.
- Nameščamo posodobitve, v celoti znova zaženemo vse workerje in preverimo čase zagona procesov.
- Za okolja s containerji image znova zgradimo in tekoče primerke nadzorovano zamenjamo.
- Stanje za vsak strežnik zabeležimo v dokazilu storitve popravkov PHP.
Pogosta vprašanja
Ali je RHEL 7 prizadet zaradi PHP2Shell?
Po Red Hat je RHEL 7 prizadet samo zaradi CVE-2026-109619, ranljive kode za CVE-2026-109618 tam ni. Na RHEL 7 je mod_php standardni način delovanja, ki ga ekipa PHP uvršča kot posebej tvegan.
Zakaj Red Hat ranljivost ocenjuje nižje kot php.net?
Red Hat uporablja lastno oceno po CVSS v3.1 in CVE-2026-109618 uvršča kot Important, ker naj bi izkoriščanje zahtevalo natančno časovno usklajenost. php.net ocenjuje s CVSS v4.0 9,2. Oba menita, da je izvajanje kode brez prijave mogoče, posodobitev je v vsakem primeru potrebna.
Ali AlmaLinux in Rocky Linux popravke prejmeta samodejno?
Oba svoje pakete gradita iz izvorne kode Red Hata in objavljata lastna varnostna obvestila. Čas se lahko razlikuje od Red Hata. Stanje zato preverite na lastnem sistemu in v obvestilih svoje distribucije.
Ali po posodobitvi zadošča systemctl reload php-fpm?
Ne. Red Hat izrecno opozarja, da reload ne zadošča, ker lahko obstoječi workerji obdržijo prizadeto stanje. Znova zaženite vse workerje, pri mod_php storitev Apache httpd.