# RHEL, AlmaLinux és Rocky Linux: PHP-javítás ellenőrzése

> PHP-javítás ellenőrzése RHEL, AlmaLinux és Rocky rendszeren: mit közöl a Red Hat a PHP2Shellről, hogyan kérdezze le az errátákat és a changelogot.

Forrás: https://phpsos.de/hu/blog/rhel-almalinux-rocky-php/  
Állapot: 2026. 10. 25.  
Szolgáltató: PHP SOS, PHP-vészhelyzeti segítség és szerverbiztonság. Azonnali segítség WhatsAppon: https://wa.me/491736494914?text=%C3%9Cdv%C3%B6zl%C3%B6m%2C%20PHP%20SOS%21%20Seg%C3%ADts%C3%A9gre%20van%20sz%C3%BCks%C3%A9g%C3%BCnk%20a%20PHP-szerver%C3%BCnkkel.%20C%C3%A9g%3A%20%E2%80%A6%20Weboldal%3A%20%E2%80%A6

**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.

```bash
# 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](https://phpsos.de/hu/blog/cve-im-changelog-nachweisen/) í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](https://phpsos.de/hu/php2shell/php-version-pruefen/) 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:

```bash
# 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](https://phpsos.de/hu/php2shell/php-fpm-neustart/) 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.enabled` sora a kiszállított konfigurációban ki van kommentezve, a funkció tehát alapértelmezetten aktív. A `0` értéket kifejezetten be kell állítani.
- **Felülírhatatlanul állítsa be:** a PHP-FPM-pool `php_admin_value` direktívájával, mod_php esetén az Apache-konfigurációban. Nem `ini_set()`-tel vagy `.user.ini`-vel.
- **Keresse az ellenjátékosokat:** A Red Hat azt javasolja, hogy ellenőrizze a `.htaccess` fájlokat, a VirtualHostokat és a `.user.ini` fá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_size` mellett 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.

> **Tipp:**
> 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ó](https://phpsos.de/hu/blog/remi-repository-php/) í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](https://phpsos.de/hu/leistungen/php-patch-service/) 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.

## Források

- [Red Hat Security Bulletin RHSB-2026-013](https://access.redhat.com/security/vulnerabilities/RHSB-2026-013)
- [Red Hat: CVE-2026-109618](https://access.redhat.com/security/cve/CVE-2026-109618)
- [php.net: biztonsági közlemények](https://www.php.net/)