Röviden: RHEL, AlmaLinux és Rocky Linux rendszeren a PHP2Shell elleni PHP-javítást három úton ellenőrzi: a disztribúció biztonsági közleményein (dnf updateinfo), a csomag changelogján (rpm -q --changelog) és a PHP-folyamatok indítási idején keresztül. A Red Hat a RHEL 7-től 10-ig terjedő verziókat érintettként tünteti fel, és a lekérdezéskor azt közölte, hogy egyes frissítések elérhetők, továbbiak készülnek. A frissítés után érvényes: teljesen újraindítani, nem csak újratölteni.
Mit tett közzé a Red Hat a PHP2Shellről
A Red Hat a PHP2Shellről az RHSB-2026-013 biztonsági bulletint adta ki. 2026. október 25-én kérdeztük le. A legfontosabb pontok az adminoknak:
- Érintettek a RHEL 10, 9, 8 és 7, valamint az erre épülő termékek és a RHEL- vagy UBI-image-ekre alapozott konténerek.
- A RHEL 7 a Red Hat szerint csak a CVE-2026-109619-cel érintett; a CVE-2026-109618 kódja nem található meg ott.
- Nem érintettek a PHP nélküli rendszerek, vagy azok, amelyeken a PHP nem dolgoz fel nem megbízható HTTP-kéréseket.
- Frissítések: Egyesek a lekérdezéskor elérhetők voltak, továbbiak készülnek. Konkrét erráta-számokat a bulletin nem nevezett meg, hanem az erráta-oldalakra hivatkozott.
A Red Hat a CVE-2026-109618-at saját módszerrel „Important” szintűnek értékeli, és arra utal, hogy a RHEL 8-tól kezdve az alapértelmezett telepítések a mod_php helyett PHP-FPM-et használnak. Ez egy besorolás, nem riasztás-lefújás. A PHP-projekt mindkét rést CVSS v4.0 szerinti 9,2-del értékeli, a BSI (a német szövetségi információbiztonsági hivatal) pedig az azonnali frissítést javasolja.
AlmaLinux és Rocky Linux: ugyanaz a forrás, saját ütem
Az AlmaLinux és a Rocky Linux a Red Hat forrásaiból építi újra a csomagjait. A javítások ezért általában tartalmilag azonosan érkeznek, de saját időponttal és saját biztonsági közlemények alatt. A Red Hat erráta említése nem jelenti azt, hogy a csomag az Ön utánépítésénél ugyanazon a napon rendelkezésre áll.
Ezért a döntő az Ön rendszerén lévő állapot. Ellenőrizze a csomagkezelő eszközeivel, nem hírek vagy fórumok alapján.
Ügyeljen arra is, hogy a szerveren használnak-e tükörszervereket vagy belső csomagforrásokat. Sok vállalatnál a szerverek nem közvetlenül a gyártótól, hanem egy belső tükrön vagy egy kezelőeszközön keresztül töltik le a frissítéseiket. Ha ez a tükör nem naprakész, a dnf nem talál új csomagokat, noha azokat már rég közzétették.
A PHP-javítás ellenőrzése RHEL-en és az utánépítéseken
A következő parancsok kizárólag olvasnak. A csomagnevek a disztribúció PHP-csomagjaira érvényesek; a harmadik féltől származó források, például a Remi csomagjai részben másképp hívják.
# Mely PHP-streameket ismeri a rendszer, melyik aktív? (RHEL 8 és 9)
dnf module list php
# Telepített PHP-csomagok verzióval és eredettel
rpm -qa 'php*' --qf '%{NAME}-%{VERSION}-%{RELEASE} %{VENDOR}\n' | sort
# Vannak biztonsági közlemények a CVE-kre ehhez a rendszerhez?
dnf updateinfo list --cve CVE-2026-109618
dnf updateinfo list --cve CVE-2026-109619
# Benne van a javítás a telepített csomag changelogjában?
rpm -q --changelog php-fpm | grep -E "CVE-2026-10961[89]"
A dnf updateinfo csak a még nem telepített frissítések közleményeit mutatja; a --installed kapcsolóval a már telepítetteket is látja. Egy üres eredmény tehát kétféle lehet: a frissítés már benne van, vagy még nincs közzétéve. A changelog-összevetés tisztázza ezt. Hogyan rögzítheti az eredményt igazolásként, azt a CVE-számok igazolása a csomag changelogjában írás írja le.
Mint más vállalati disztribúcióknál, a csomag többnyire megtartja az eredeti PHP-verziót; csak a kiadásjelzés változik. A php -v régebbi száma ezért nem jelzi a javítás hiányát. A verzióellenőrzés általános tudnivalói a PHP-verzió és javítási állapot helyes ellenőrzése oldalon találhatók.
A helyes üzemmód felismerése
A Red Hat megnevezi az alapértelmezett üzemmódokat: a RHEL 8-tól a PHP PHP-FPM-en keresztül fut, a RHEL 7-en mod_php-ként az Apache httpd szolgáltatásban. Sok szerver eltér ettől, például panelek, külső források vagy régi konfigurációk miatt.
| Rendszer | Alapértelmezett a Red Hat szerint | Újraindítás a frissítés után |
|---|---|---|
| RHEL 8, 9, 10 és utánépítések | PHP-FPM | systemctl restart php-fpm |
| RHEL 7 | mod_php a httpd-ben | systemctl restart httpd |
| RHEL- vagy UBI-alapú konténerek | image-enként | az image újraépítése, a konténer cseréje |
Konténerekhez a Red Hat azt javasolja, hogy a frissített alap-image-ek után építsék újra a saját image-eket, és cseréljék le a futó konténereket vagy podokat. A futó konténerben végzett frissítés nem megbízható út.
A frissítés után: újraindítás és ellenőrzés
A Red Hat hangsúlyozza, hogy a reload nem elég. A meglévő workerek megtarthatják az érintett állapotot. Indítson ezért újra minden szolgáltatást, amely PHP-t tölt be, és ellenőrizze az eredményt:
# Elavult könyvtárakkal rendelkező szolgáltatások kijelzése (dnf-utils illetve dnf-plugins-core)
needs-restarting -s
# A PHP-folyamatok indítási idejének összevetése a frissítés időpontjával
ps -eo pid,lstart,cmd | grep -E "[p]hp-fpm|[h]ttpd"
A konfigurációhoz a Red Hat gyakorlati tanácsot ad: a php -i a parancssor beállításait mutatja, nem a webszerverét. Aki ellenőrizni szeretné, hogy az olyan átmeneti értékek, mint a session.upload_progress.enabled=0, érvényesek-e a webes környezetben, rövid időre használjon egy védett phpinfo-oldalt, és utána törölje. Hogy az újraindításnál mire kell még ügyelni, azt a PHP-FPM és az összes worker újraindítása oldal tartalmazza.
Átmeneti intézkedések: a Red Hat tanácsai
Ahol a frissítés még hiányzik, a Red Hat ugyanazokra az átmeneti intézkedésekre hivatkozik, mint a php.net, és néhány gyakorlati tanáccsal egészíti ki a RHEL-rendszerekre. Ezek nem helyettesítik a frissítést.
- Valóban egészítse ki a sort: A Red Hat szerint a
session.upload_progress.enabledsora a kiszállított konfigurációban ki van kommentezve, a funkció tehát alapértelmezetten aktív. A0értéket kifejezetten be kell állítani. - Felülírhatatlanul állítsa be: a PHP-FPM-pool
php_admin_valuedirektívájával, mod_php esetén az Apache-konfigurációban. Nemini_set()-tel vagy.user.ini-vel. - Keresse az ellenjátékosokat: A Red Hat azt javasolja, hogy ellenőrizze a
.htaccessfájlokat, a VirtualHostokat és a.user.inifájlokat, hogy nem kapcsolják-e vissza az érintett beállításokat. - Határokat előtte is húzzon: A PHP-beli
post_max_sizemellett a Red Hat azt javasolja, hogy fontolja meg a kérésméret korlátait a webszerveren vagy a proxyn is.
A PHP-FPM-rendszereken a poolok általában az /etc/php-fpm.d/ alatt találhatók. Minden módosítás után ugyanaz érvényes, mint a frissítés után: az összes workert teljesen újra kell indítani.
Ha ugyanazon a szerveren emellett a Remi-tárolóból származó PHP is fut, arra saját csomagok és szolgáltatások érvényesek. Olvassa el erről a A Remi-tároló írást.
Hogyan segít konkrétan a PHP SOS?
- RHEL, AlmaLinux és Rocky Linux rendszereken ellenőrizzük az összes PHP-csomagot, streamet és külső forrást, és összevetjük őket a biztonsági közleményekkel.
- Telepítjük a frissítéseket, az összes workert teljesen újraindítjuk, és ellenőrizzük a folyamatok indítási idejét.
- Konténerkörnyezetekben újraépítjük az image-eket, és ellenőrzötten lecseréljük a futó példányokat.
- Az állapotot szerverenként a PHP-javítási szolgáltatás igazolásában rögzítjük.
Gyakori kérdések
Érintett a RHEL 7 a PHP2Shellben?
A Red Hat szerint a RHEL 7 csak a CVE-2026-109619-cel érintett, a CVE-2026-109618 sebezhető kódja nincs ott meg. A RHEL 7-en a mod_php az alapértelmezett üzemmód, amelyet a PHP-csapat különösen kockázatosnak minősít.
Miért értékeli a Red Hat alacsonyabbra a rést, mint a php.net?
A Red Hat saját, CVSS v3.1 szerinti értékelést használ, és a CVE-2026-109618-at Important szintűnek minősíti, mert a kihasználás pontos időzítést igényel. A php.net CVSS v4.0 szerinti 9,2-vel értékel. Mindkettő lehetségesnek tartja a bejelentkezés nélküli kódfuttatást, a frissítés mindenképp szükséges.
Automatikusan megkapja a javításokat az AlmaLinux és a Rocky Linux?
Mindkettő a Red Hat forrásaiból építi újra a csomagjait, és saját biztonsági közleményeket tesz közzé. Az időpont eltérhet a Red Hatétól. Ezért az állapotot ellenőrizze a saját rendszerén és a disztribúciója közleményeiben.
Elég a systemctl reload php-fpm a frissítés után?
Nem. A Red Hat kifejezetten rámutat, hogy a reload nem elég, mert a meglévő workerek megtarthatják az érintett állapotot. Indítsa újra az összes workert, mod_php esetén az Apache httpd szolgáltatást.