Pe scurt: Depozitul PHP Remi livrează versiuni PHP actuale pentru Fedora și familia RHEL, fie ca stream de modul, care înlocuiește PHP-ul sistemului, fie ca Software Collection, care instalează mai multe versiuni în paralel. Corecțiile PHP2Shell 8.2.35, 8.3.36, 8.4.27 și 8.5.12 au fost anunțate acolo pe 22 octombrie 2026. Verificați fiecare versiune instalată în parte și reporniți fiecare serviciu aferent.
De ce obțin atât de multe servere RHEL PHP de la Remi
Distribuțiile pentru întreprinderi precum RHEL, AlmaLinux și Rocky Linux mizează pe stabilitate îndelungată. Livrează puține ramuri PHP și le păstrează ani de zile. Multe aplicații cer însă versiuni mai noi decât oferă distribuția. Aici intervine depozitul lui Remi Collet, un îngrijitor de pachete PHP de multă vreme în mediul Fedora și RHEL.
Remi construiește versiunile PHP la scurt timp după lansările oficiale. Despre PHP2Shell a apărut în blogul depozitului pe 22 octombrie 2026 o postare despre versiunile 8.2.35, 8.3.36, 8.4.27 și 8.5.12. În ea sunt menționate cele două vulnerabilități critice CVE-2026-109618 și CVE-2026-109619 și este recomandată urgent actualizarea. Anunțurile de securitate ale Red Hat nu se aplică acestor pachete; ce anunță Red Hat pentru propriile pachete se află în articolul RHEL, AlmaLinux și Rocky Linux: verificarea patchului PHP.
Două căi: stream de modul sau Software Collection
Potrivit blogului Remi, build-urile pentru Enterprise Linux începând cu versiunea 8 sunt disponibile pe două căi. Care este folosită pe serverul dumneavoastră determină cum verificați și reporniți.
| Cale | Depozit | Efect | Serviciu tipic |
|---|---|---|---|
Stream de modul, de exemplu php:remi-8.3 |
remi-modular | înlocuiește PHP-ul sistemului, o versiune implicită | php-fpm |
Software Collection, de exemplu php83 |
remi-safe | versiune suplimentară în paralel, în cale proprie | serviciu propriu pentru fiecare versiune, de exemplu php83-php-fpm |
| Pachete de test și release candidates | remi-modular-test, remi-test | versiuni preliminare | nu pentru producție |
Software Collections se află, de regulă, sub /opt/remi/phpXY, iar configurația lor sub /etc/opt/remi/phpXY. Este practic pentru a opera aplicații vechi și noi pe un server. Este însă și cel mai frecvent motiv pentru care o versiune este trecută cu vederea la actualizare.
O indicație despre linia de comandă: Software Collections nu sunt disponibile automat sub comanda php. În funcție de configurare, cronjobs și scripturile le apelează printr-o comandă proprie sau o cale completă. Verificați de aceea și crontab-urile și scripturile de deployment, dacă vreți să știți ce colecție este folosită pentru ce.
Verificarea depozitului PHP Remi după PHP2Shell
Comenzile următoare sunt exclusiv de citire și arată ce pachete Remi sunt instalate și ce stare au.
# Surse de pachete active: este remi-modular sau remi-safe integrat?
dnf repolist
# Stream-ul de modul activ pentru PHP
dnf module list --enabled php
# Pachete de bază și Software Collections instalate în paralel
rpm -qa 'php-*' 'php[0-9][0-9]-php-*' --qf '%{NAME}-%{VERSION}-%{RELEASE}\n' | sort
# Versiunea fiecărei colecții instalate
for b in /opt/remi/php*/root/usr/bin/php; do echo "$b"; "$b" -v | head -1; done
La ramurile suportate, situația este clară: dacă acolo apare 8.5.12, 8.4.27, 8.3.36 sau 8.2.35 ori mai nou, corecția este inclusă. La Remi, numărul versiunii corespunde, de regulă, versiunii upstream, spre deosebire de pachetele distribuției, care își păstrează adesea numărul vechi.
Pentru colecții mai vechi precum php81, php80 sau php74 nu există o versiune țintă oficială. Remi tratează PHP 8.1 ca End-of-Life. Dacă un pachet instalat conține o corecție împotriva PHP2Shell clarificați în changelog, de exemplu cu rpm -q --changelog php81-php-fpm | grep -E "CVE-2026-10961[89]". Fără potrivire, tratați pachetul ca neclarificat. Cum dovediți curat astfel de potriviri descrie articolul Dovedirea numerelor CVE în changelog-ul pachetului.
Nu activați permanent pe serverele de producție depozite de test precum remi-test sau remi-modular-test. Ele livrează release candidates, destinate testelor.
Actualizarea și repornirea fiecărei versiuni
Actualizarea în sine este la Remi, de obicei, lipsită de spectaculos: dnf upgrade aduce pachete noi pentru stream și colecții. Partea critică urmează după aceea. Fiecare colecție are propriul serviciu FPM, iar fiecare trebuie repornit.
# Listați toate serviciile PHP-FPM, inclusiv pe cele ale colecțiilor
systemctl list-units --type=service --all | grep -E "php.*fpm"
# Verificați orele de pornire ale tuturor proceselor PHP
ps -eo pid,lstart,cmd | grep -E "[p]hp-fpm|[h]ttpd"
Orele de pornire anterioare actualizării înseamnă: acest serviciu lucrează încă cu cod vechi. De ce o reîncărcare nu este suficientă explică pagina Repornirea PHP-FPM și a tuturor workerilor.
Remi și distribuția: cine este responsabil?
Cine trece prin stream de modul la Remi schimbă pentru PHP furnizorul. Anunțurile de securitate ale Red Hat, AlmaLinux sau Rocky Linux nu se mai referă atunci la pachetele PHP instalate. Invers, Remi nu raportează probleme în alte pachete ale sistemului. Trebuie deci să țineți în vedere ambele surse.
De unde provine un pachet instalat arată baza de date a pachetelor, de exemplu cu rpm -qi php-fpm, în câmpurile pentru producător și împachetator. Deoarece pentru pachetele Remi nu există errata în sensul Red Hat, blogul depozitului este potrivit ca mijloc de notificare; poate fi abonat prin feed RSS. La PHP2Shell, indicația a apărut acolo la o zi după versiunile oficiale.
Pentru companii, această împărțire nu este un obstacol, dar trebuie documentată. Consemnați ce servere obțin PHP de la Remi, cine citește anunțurile și cine repornește serviciile după o actualizare. Altfel, fiecare se bazează pe celălalt.
Păstrați ordinea: mai puține versiuni, mai puțin risc
Software Collections invită să lăsați pur și simplu versiunile vechi pe loc. După PHP2Shell este un moment bun pentru ordine:
- Clarificați pentru fiecare colecție ce site sau ce cronjob o folosește.
- Dezactivați colecțiile nefolosite și eliminați-le după o perioadă de observare.
- Ridicați aplicațiile de pe colecții vechi la o ramură suportată.
- Documentați versiunile rămase cu scopul și responsabilul lor.
Cum păstrați imaginea de ansamblu asupra multor versiuni paralele descrie articolul Mai multe versiuni PHP pe un server.
Cum ajută PHP SOS concret?
- Inventariem toate stream-urile și colecțiile Remi de pe serverele dumneavoastră și le atribuim site-urilor și cronjob-urilor.
- Verificăm starea PHP2Shell pe versiune prin versiunea pachetului și changelog.
- Instalăm actualizări, repornim fiecare serviciu și dovedim aceasta cu orele de pornire a proceselor în cadrul serviciului de patch PHP.
- Colecțiile care nu mai sunt necesare le eliminăm controlat, după coordonare.
Întrebări frecvente
A pus Remi la dispoziție versiunile PHP2Shell?
Da. În blogul depozitului au fost anunțate pe 22 octombrie 2026 versiunile 8.2.35, 8.3.36, 8.4.27 și 8.5.12, cu indicația despre două vulnerabilități critice, CVE-2026-109618 și CVE-2026-109619, și cu recomandarea urgentă de actualizare.
Care este diferența dintre stream de modul și SCL la Remi?
Printr-un stream de modul înlocuiți PHP-ul sistemului cu o versiune Remi, existând atunci o versiune PHP ca implicită. Software Collections instalează alte versiuni în paralel, în căi proprii, fiecare cu serviciu propriu.
Mai primește PHP 8.1 actualizări de la Remi?
Remi tratează PHP 8.1 ca End-of-Life, proiectul PHP nu mai întreține ramura. Dacă un anumit pachet 8.1 conține o corecție împotriva PHP2Shell verificați în changelog-ul pachetului instalat. Fără intrare, starea este considerată neclarificată.
Trebuie să repornesc fiecare versiune PHP după o actualizare Remi?
Da. Fiecare versiune instalată în paralel are un serviciu FPM propriu. Dacă este repornit doar serviciul versiunii principale, celelalte continuă să ruleze cu cod vechi.