# Serviciu de patch PHP: actualizare cu repornire și dovadă

> Actualizare PHP la comandă: aplicăm patchul pe versiunile corectate, repornim toți workerii și dovedim starea în scris. Pentru firme și agenții.

Sursa: https://phpsos.de/ro/leistungen/php-patch-service/  
Stadiu: 25.10.2026  
Furnizor: PHP SOS, Asistență de urgență PHP și securitatea serverelor. Ajutor imediat pe WhatsApp: https://wa.me/491736494914?text=Bun%C4%83%20ziua%2C%20PHP%20SOS%2C%20avem%20nevoie%20de%20ajutor%20cu%20serverul%20nostru%20PHP.%20Firma%3A%20%E2%80%A6%20Site%3A%20%E2%80%A6

**Pe scurt:** Cine vrea să comande o actualizare PHP are nevoie de mai mult decât pachete noi: contează starea corectă a pachetelor, repornirea tuturor proceselor PHP și o dovadă în acest sens. Exact asta livrează serviciul nostru de patch PHP. Primiți o dovadă scrisă pentru fiecare server, pe care o puteți prezenta intern sau terților.

## De ce o actualizare PHP singură nu este adesea suficientă

Din 21.10.2026 există patchuri pentru vulnerabilitățile PHP2Shell CVE-2026-109618 și CVE-2026-109619. BSI (Oficiul Federal German pentru Securitatea Informațiilor) recomandă actualizarea imediată. În practică vedem trei obstacole tipice.

În primul rând, numărul versiunii nu arată întotdeauna starea reală. Distribuțiile și furnizorii de hosting aplică uneori backporturi; atunci Plesk, de exemplu, raportează în continuare 8.2.34, deși starea pachetelor este actualizată. În al doilea rând, după aplicare rulează adesea mai departe procese PHP vechi. Fișierele noi de pe disc nu protejează cât timp workerii vechi lucrează în memorie. În al treilea rând, pe un server rulează frecvent mai multe versiuni PHP în paralel, iar una dintre ele este uitată.

## Actualizare PHP la comandă: versiunile remediate

| Ramură | Remediat de la | Starea anterioară | Observație |
|---|---|---|---|
| PHP 8.5 | 8.5.12 | 8.5.11 | verificați suplimentar `fatal_error_backtraces` |
| PHP 8.4 | 8.4.27 | 8.4.26 | |
| PHP 8.3 | 8.3.36 | 8.3.35 | |
| PHP 8.2 | 8.2.35 | 8.2.34 | suportul se încheie la 31.12.2026 |
| PHP 8.1 și mai vechi | fără actualizări oficiale | – | doar backporturi minime în codul sursă pentru 7.4, 8.0, 8.1 |

La pachetele din distribuții sau de la furnizorii de hosting nu contează cifra de după „PHP”, ci starea pachetului pe care furnizorul o confirmă ca actualizată. Cum verificați singur, aflați la [Cum verificați corect versiunea PHP și starea patchului](https://phpsos.de/ro/php2shell/php-version-pruefen/).

## Cum ajută PHP SOS concret?

1. **Inventar:** Inventariem toate instalările PHP de pe server, modul de operare (PHP-FPM, mod_php, php-cgi, FrankenPHP, LiteSpeed) și ce site folosește ce versiune.
2. **Aplicarea actualizării:** Instalăm versiunile remediate din sursa de pachete a distribuției dumneavoastră, a panoului dumneavoastră sau a proiectului oficial. Pentru containere construim împreună cu dumneavoastră imagini noi.
3. **Repornirea tuturor proceselor:** Repornim complet PHP-FPM, Apache, LiteSpeed sau workerii respectivi și controlăm ca niciun proces să nu fie mai vechi decât actualizarea. Contextul îl găsiți la [Cum reporniți PHP-FPM și toți workerii](https://phpsos.de/ro/php2shell/php-fpm-neustart/).
4. **Verificarea funcționării:** Accesăm paginile și funcțiile cele mai importante, de exemplu pagina de start, autentificarea, formularele și finalizarea comenzii, și verificăm jurnalele de erori.
5. **Dovada:** Primiți pentru fiecare server un protocol cu versiunea, starea pachetelor, momentul repornirii și punctele deschise.

Un pas tipic de verificare după repornire arată astfel:

```bash
# versiunea PHP-CLI și a binarului FPM (calea depinde de sistem)
php -v
php-fpm8.3 -v
# ora de pornire a proceselor FPM: trebuie să fie ulterioară actualizării
ps -o pid,lstart,cmd -C php-fpm8.3
```

## Cazuri speciale: panouri, containere și mai multe versiuni PHP

Pe serverele cu **Plesk sau cPanel**, versiunile PHP provin adesea din sursele de pachete ale panoului și nu din distribuție. Acolo verificăm fiecare versiune instalată în parte, inclusiv pe cele care nu sunt atribuite în prezent niciunui site. Versiunile neutilizate și învechite le eliminăm, în înțelegere cu dumneavoastră, pentru ca ele să nu fie reactivate din greșeală.

În mediile **Docker și Kubernetes**, o actualizare pe host nu este suficientă. PHP se află în imagine, iar abia o imagine reconstruită cu o bază actualizată, distribuită pe toate containerele în execuție, închide vulnerabilitatea. Verificăm aici și dacă imagini mai vechi din registre sau din deployment-uri sunt încă folosite. Detalii găsiți la [Cum actualizați PHP în containere Docker](https://phpsos.de/ro/php2shell/docker-container-patchen/).

La **mod_php**, PHP rulează direct în procesul Apache. Echipa PHP evaluează riscul aici ca fiind cel mai ridicat. După actualizare, Apache însuși trebuie, de aceea, repornit complet; o simplă reîncărcare a configurației nu este suficientă în orice caz.

## Ce primiți de la noi

- un protocol de patch pentru fiecare server: pachete instalate, versiuni, sursă, moment
- dovada că toate procesele PHP au fost repornite
- o listă a site-urilor și funcțiilor verificate
- indicații despre sistemele care nu au putut fi actualizate, cu motivare
- o recomandare pentru drumul mai departe, de exemplu la PHP 8.2 din cauza sfârșitului apropiat al suportului

## De ce avem nevoie de la dumneavoastră

- **Acces:** SSH cu drepturi de administrator sau acces la panou (Plesk, cPanel sau similar)
- **Fereastră de mentenanță:** când este permisă o scurtă repornire
- **Interlocutor:** pentru întrebări și pentru aprobarea după verificarea funcționării
- **Backupuri:** confirmarea că există o salvare actuală sau mandatul de a crea una înainte
- **Indicații despre dezvoltările proprii:** extensii PHP sau configurații speciale care trebuie luate în considerare

La hostingul partajat, fără acces propriu la server, nu putem aplica noi patchul. Vă ajutăm atunci să puneți furnizorului de hosting întrebările potrivite și să evaluați răspunsul.

## Ce nu promitem

Serviciul de patch închide vulnerabilitatea cunoscută. El nu răspunde la întrebarea dacă serverul a fost compromis înainte de actualizare și nu elimină software-ul malițios introdus. Dacă doriți să aflați acest lucru, comanda potrivită este [asistența de urgență PHP2Shell](https://phpsos.de/ro/leistungen/php2shell-soforthilfe/) cu căutarea urmelor.

Pentru PHP 8.1 și versiunile mai vechi nu mai există actualizări oficiale. Aici aplicăm măsuri provizorii și recomandăm [migrarea la o versiune susținută](https://phpsos.de/ro/leistungen/php-migration-legacy/). O promisiune de compatibilitate pentru CMS-ul dumneavoastră nu o dăm din memorie, ci o verificăm pe baza cerințelor de sistem ale producătorului.


## Întrebări frecvente

**De ce serverul meu arată încă vechea versiune PHP după actualizare?**  
Pot fi două motive. Fie distribuția a aplicat un backport, caz în care numărul versiunii rămâne același, deși starea pachetelor este actualizată. Fie procese PHP vechi rulează încă în memorie și trebuie repornite.

**Ce versiuni PHP închid PHP2Shell?**  
Vulnerabilitatea este remediată în PHP 8.5.12, 8.4.27, 8.3.36 și 8.2.35, publicate la 21.10.2026. La pachetele din distribuții contează starea pachetului pe care furnizorul o confirmă ca actualizată.

**Poate actualizarea să-mi blocheze site-ul?**  
O actualizare în cadrul aceleiași versiuni majore, de exemplu de la 8.3.35 la 8.3.36, nu este de regulă critică. O scurtă repornire a proceselor PHP este totuși necesară. Stabilim intervalul de timp împreună cu dumneavoastră și verificăm paginile după aceea.

**Este totul rezolvat odată cu patchul?**  
Pentru vulnerabilitatea în sine, da, de îndată ce toate procesele au fost repornite. Dacă înainte de patch a pătruns deja cineva, patchul nu arată. Pentru asta este nevoie de o verificare separată.

## Surse

- [php.net: anunțuri de securitate](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)
- [php.net: versiuni susținute](https://www.php.net/supported-versions.php)
- [BSI: Oficiul Federal German pentru Securitatea Informațiilor](https://www.bsi.bund.de/)