Pe scurt: Pe RHEL, AlmaLinux și Rocky Linux verificați patchul PHP împotriva PHP2Shell pe trei căi: anunțurile de securitate ale distribuției (dnf updateinfo), changelog-ul pachetului (rpm -q --changelog) și ora de pornire a proceselor PHP. Red Hat indică RHEL 7 până la 10 ca afectate și a anunțat la consultare că unele actualizări sunt disponibile, iar altele în lucru. După actualizare se aplică: reporniți complet, nu doar reîncărcați.
Ce a publicat Red Hat despre PHP2Shell
Red Hat a publicat pentru PHP2Shell buletinul de securitate RHSB-2026-013. L-am consultat pe 25 octombrie 2026. Cele mai importante puncte pentru administratori:
- Sunt afectate RHEL 10, 9, 8 și 7, precum și produsele construite pe ele și containerele bazate pe imagini RHEL sau UBI.
- RHEL 7 este afectat, potrivit Red Hat, doar de CVE-2026-109619; codul pentru CVE-2026-109618 nu ar fi conținut acolo.
- Nu sunt afectate sistemele fără PHP sau fără PHP care să prelucreze cereri HTTP nesigure.
- Actualizări: Unele erau disponibile la consultare, altele în lucru. Buletinul nu a menționat numere concrete de errata, ci a trimis la paginile de errata.
Red Hat evaluează CVE-2026-109618 cu o metodă proprie drept „Important” și precizează că instalările standard începând cu RHEL 8 folosesc PHP-FPM în loc de mod_php. Aceasta este o încadrare, nu o încetare a alertei. Proiectul PHP evaluează ambele vulnerabilități cu CVSS v4.0 9.2, iar BSI (Oficiul Federal German pentru Securitatea Informațiilor) recomandă actualizarea imediată.
AlmaLinux și Rocky Linux: aceeași sursă, ritm propriu
AlmaLinux și Rocky Linux își reconstruiesc pachetele din sursele Red Hat. Corecțiile ajung de aceea, de regulă, identice ca substanță, dar la un moment propriu și sub anunțuri de securitate proprii. O trimitere la o errata Red Hat nu înseamnă că pachetul este disponibil în aceeași zi la clona dumneavoastră.
Decisivă este de aceea starea de pe sistemul dumneavoastră. Verificați-o cu instrumentele gestionării pachetelor și nu pe baza știrilor sau a forumurilor.
Fiți atenți, în plus, dacă pe server se folosesc servere oglindă sau surse interne de pachete. În multe companii, serverele nu își obțin actualizările direct de la producător, ci printr-o oglindă internă sau un instrument de administrare. Dacă această oglindă nu este actuală, dnf nu găsește pachete noi, deși ele au fost publicate de mult.
Verificarea patchului PHP pe RHEL și clone
Comenzile următoare sunt exclusiv de citire. Numele pachetelor se aplică pachetelor PHP ale distribuției; pachetele din surse terțe precum Remi se numesc uneori diferit.
# Ce stream-uri PHP cunoaște sistemul, care este activ? (RHEL 8 și 9)
dnf module list php
# Pachete PHP instalate cu versiune și proveniență
rpm -qa 'php*' --qf '%{NAME}-%{VERSION}-%{RELEASE} %{VENDOR}\n' | sort
# Există anunțuri de securitate pentru aceste CVE-uri pe acest sistem?
dnf updateinfo list --cve CVE-2026-109618
dnf updateinfo list --cve CVE-2026-109619
# Se află corecția în changelog-ul pachetului instalat?
rpm -q --changelog php-fpm | grep -E "CVE-2026-10961[89]"
dnf updateinfo arată doar anunțuri pentru actualizări care nu sunt încă instalate; cu --installed vedeți și pe cele deja instalate. Un rezultat gol poate însemna deci două lucruri: actualizarea este deja instalată sau nu este încă publicată. Compararea cu changelog-ul clarifică. Cum consemnați rezultatul ca dovadă descrie articolul Dovedirea numerelor CVE în changelog-ul pachetului.
Ca la alte distribuții pentru întreprinderi, pachetul își păstrează de obicei versiunea PHP originală; se schimbă doar indicația de release. Un număr mai vechi la php -v nu este deci un indiciu al unei corecții lipsă. Indicații generale pentru verificarea versiunii se află la Verificarea corectă a versiunii PHP și a nivelului de patch.
Recunoașteți modul de operare corect
Red Hat menționează modurile de operare implicite: începând cu RHEL 8, PHP rulează prin PHP-FPM, pe RHEL 7 ca mod_php în serviciul Apache httpd. Multe servere se abat de la aceasta, de exemplu prin panouri, surse terțe sau configurații vechi.
| Sistem | Implicit conform Red Hat | Repornire după actualizare |
|---|---|---|
| RHEL 8, 9, 10 și clone | PHP-FPM | systemctl restart php-fpm |
| RHEL 7 | mod_php în httpd | systemctl restart httpd |
| Containere pe bază RHEL sau UBI | în funcție de imagine | reconstruiți imaginea, înlocuiți containerul |
Pentru containere, Red Hat recomandă ca după imaginile de bază actualizate să reconstruiți propriile imagini și să înlocuiți containerele sau pod-urile în funcțiune. O actualizare în containerul în funcțiune nu este o cale de încredere.
După actualizare: repornire și control
Red Hat subliniază că o reîncărcare nu este suficientă. Workerii existenți pot păstra starea afectată. Reporniți de aceea fiecare serviciu care încarcă PHP și controlați rezultatul:
# Afișează serviciile cu biblioteci depășite (dnf-utils sau dnf-plugins-core)
needs-restarting -s
# Comparați ora de pornire a proceselor PHP cu momentul actualizării
ps -eo pid,lstart,cmd | grep -E "[p]hp-fpm|[h]ttpd"
Pentru configurație, Red Hat are o indicație practică: php -i arată setările liniei de comandă, nu pe cele ale serverului web. Cine vrea să verifice dacă valori provizorii precum session.upload_progress.enabled=0 se aplică în contextul web folosește pe scurt o pagină phpinfo protejată și o șterge după aceea. Ce mai trebuie avut în vedere la repornire se află la Repornirea PHP-FPM și a tuturor workerilor.
Măsuri provizorii: indicațiile Red Hat
Acolo unde actualizarea lipsește încă, Red Hat trimite la aceleași măsuri provizorii ca php.net și adaugă câteva indicații practice pentru sistemele RHEL. Ele nu înlocuiesc actualizarea.
- Completați cu adevărat linia: Potrivit Red Hat, linia pentru
session.upload_progress.enabledeste comentată în configurația livrată, funcția fiind deci activă implicit. Valoarea0trebuie setată explicit. - Setați fără posibilitate de suprascriere: prin
php_admin_valueîn pool-ul PHP-FPM, la mod_php în configurația Apache. Nu prinini_set()sau.user.ini. - Căutați adversarii: Red Hat recomandă verificarea fișierelor
.htaccess, a VirtualHost-urilor și a fișierelor.user.inipentru a vedea dacă reactivează setările afectate. - Setați limite și în față: Pe lângă
post_max_sizeîn PHP, Red Hat recomandă să luați în considerare limite pentru dimensiunea cererii și în serverul web sau proxy.
Pe sistemele PHP-FPM, pool-urile se află de regulă în /etc/php-fpm.d/. După fiecare modificare se aplică același lucru ca după actualizare: reporniți complet toți workerii.
Dacă pe același server rulează suplimentar PHP din depozitul Remi, pentru acesta se aplică pachete și servicii proprii. Citiți despre aceasta articolul Depozitul Remi.
Cum ajută PHP SOS concret?
- Verificăm pe RHEL, AlmaLinux și Rocky Linux toate pachetele PHP, stream-urile și sursele terțe și le comparăm cu anunțurile de securitate.
- Instalăm actualizări, repornim complet toți workerii și controlăm orele de pornire a proceselor.
- Pentru mediile cu containere reconstruim imaginile și înlocuim controlat instanțele în funcțiune.
- Starea fiecărui server o consemnăm în dovada serviciului de patch PHP.
Întrebări frecvente
Este RHEL 7 afectat de PHP2Shell?
Potrivit Red Hat, RHEL 7 este afectat doar de CVE-2026-109619, codul vulnerabil pentru CVE-2026-109618 nu ar fi prezent acolo. Pe RHEL 7, mod_php este modul de operare implicit, pe care echipa PHP îl încadrează ca deosebit de riscant.
De ce evaluează Red Hat vulnerabilitatea mai jos decât php.net?
Red Hat folosește o evaluare proprie conform CVSS v3.1 și încadrează CVE-2026-109618 ca Important, deoarece exploatarea ar necesita sincronizare exactă. php.net evaluează cu CVSS v4.0 9.2. Ambele consideră posibilă execuția de cod fără autentificare, iar actualizarea este necesară în orice caz.
Primesc AlmaLinux și Rocky Linux corecțiile automat?
Ambele își reconstruiesc pachetele din sursele Red Hat și publică propriile anunțuri de securitate. Momentul poate diferi de cel al Red Hat. De aceea, verificați starea pe propriul sistem și în anunțurile distribuției dumneavoastră.
Este suficient systemctl reload php-fpm după actualizare?
Nu. Red Hat atrage explicit atenția că o reîncărcare nu este suficientă, deoarece workerii existenți pot păstra starea afectată. Reporniți toți workerii, iar la mod_php serviciul Apache httpd.