# Ce versiuni PHP sunt afectate?

> Ce versiuni PHP afectează PHP2Shell și care sunt remediate: tabel de versiuni de la 8.5 la 5.4, indicații despre backporturi, sfârșitul suportului și pași.

Sursa: https://phpsos.de/ro/php2shell/betroffene-php-versionen/  
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:** De vulnerabilitatea PHP2Shell sunt afectate ramurile 8.2 până la 8.5 până la versiunile din 21 octombrie 2026, iar potrivit presei de specialitate aproape toate versiunile, până înapoi la PHP 5.4. Ea este remediată în PHP 8.5.12, 8.4.27, 8.3.36 și 8.2.35. Pentru PHP 8.1 și versiunile mai vechi nu mai există actualizări oficiale, ci doar backporturi minime în codul sursă pentru 7.4, 8.0 și 8.1.

## Ce versiuni a afectat vulnerabilitatea PHP?

PHP2Shell cuprinde cele două vulnerabilități CVE-2026-109618 și CVE-2026-109619, evaluate fiecare cu CVSS v4.0 9.2. Ambele permit execuția de cod malițios de la distanță, fără autentificare. La 21 octombrie 2026, la ora 14:00 UTC (ora 16:00, ora Germaniei), proiectul PHP a publicat corecții pentru toate ramurile susținute.

| Ramura PHP | Ultima stare dinaintea corecției | Remediat de la | Suport |
|---|---|---|---|
| 8.5 | 8.5.11 | **8.5.12** | susținut oficial |
| 8.4 | 8.4.26 | **8.4.27** | susținut oficial |
| 8.3 | 8.3.35 | **8.3.36** | susținut oficial |
| 8.2 | 8.2.34 | **8.2.35** | se încheie la 31.12.2026 |
| 8.1, 8.0, 7.4 | toate stările | nicio versiune oficială | doar backporturi minime în codul sursă |
| 7.3 până la 5.4 | potrivit presei de specialitate, aproape toate afectate | nicio actualizare | fără suport de ani de zile |

Datele privind 8.2 până la 8.5 provin din anunțurile php.net. Afirmația despre versiunile până la PHP 5.4 provine din presa de specialitate; o listă oficială completă pentru versiunile vechi nu există.

Pentru cei fără pregătire tehnică, în câteva fraze: dacă pe serverul dumneavoastră se află o versiune din coloana „Remediat de la” sau una mai nouă și toate procesele PHP au fost repornite după aceea, PHP2Shell este închis. Dacă acolo apare un număr mai vechi, fie intervine un backport pe care furnizorul dumneavoastră trebuie să-l confirme, fie vulnerabilitatea este deschisă. Întrebați departamentul IT sau furnizorul de hosting, în caz de dubiu, exact despre aceste trei puncte: versiune, backport, repornire.

## Moduri de operare afectate

Numărul versiunii este doar jumătate din răspuns. Sunt afectate toate modurile uzuale de a opera PHP pe un server web: PHP-FPM, Apache cu mod_php, php-cgi, FrankenPHP și LiteSpeed. Echipa PHP evaluează riscul ca fiind cel mai ridicat la mod_php, pentru că acolo a fost demonstrat un exploit înainte ca vreun cod de aplicație să ruleze. Detalii la [De ce mod_php prezintă cel mai mare risc](https://phpsos.de/ro/php2shell/mod-php-risiko/).

Aplicația nu oferă nicio protecție: fie WordPress, Shopware, TYPO3, Laravel sau o dezvoltare proprie, o actualizare a aplicației nu închide vulnerabilitatea din PHP.

## Backporturi: când numărul versiunii înșală

Multe distribuții Linux și mulți furnizori de hosting livrează PHP în pachete proprii. În loc să treacă la o nouă versiune upstream, ei preiau corecția ca backport în versiunea lor existentă. Asta are o consecință practică: numărul afișat rămâne vechi. Un exemplu din situația actuală este Plesk, care poate afișa în continuare 8.2.34, deși eroarea este remediată.

Pentru dumneavoastră înseamnă: tabelul de mai sus este valabil pentru versiunile oficiale de pe php.net. La pachetele din distribuția dumneavoastră sau de la furnizorul de hosting decid starea pachetului și confirmarea furnizorului. Cum verificați ambele arată [Cum verificați corect versiunea PHP și starea patchului](https://phpsos.de/ro/php2shell/php-version-pruefen/). Pentru testul rapid din linia de comandă:

```bash
php -v
apt policy php8.3-fpm        # Debian/Ubuntu, numele pachetului diferă în funcție de versiune și sursă
dnf info php-fpm             # familia RHEL
```

> **Important:**
> O versiune remediată pe disc nu înseamnă încă că ea rulează. Abia după repornirea tuturor proceselor PHP lucrează serverul cu codul corectat.

## Ce se aplică pentru PHP 8.1 și versiunile mai vechi?

Pentru PHP 8.1, 8.0 și 7.4 există doar backporturi minime în codul sursă, adică corecții în codul sursă pe care cineva trebuie să le preia și să le compileze singur. Versiuni oficiale nu apar. Unele distribuții cu întreținere pe termen lung integrează asemenea corecții în pachetele lor; dacă acest lucru se aplică sistemului dumneavoastră se poate clarifica doar prin changelogul pachetului sau la furnizor.

Pe termen lung nu există cale ocolitoare pe lângă o versiune susținută. Ce versiune PHP suportă CMS-ul sau magazinul dumneavoastră verificați conform cerințelor de sistem ale producătorului, de exemplu pe wordpress.org, shopware.com sau typo3.org. Mai multe la [PHP 8.1 și versiuni mai vechi: ce se aplică acum](https://phpsos.de/ro/php2shell/php-8-1-und-aelter/).

## Dar CVE-2026-115560?

La 23 octombrie, php.net a publicat o indicație privind o a treia vulnerabilitate. Aceasta acționează doar la o configurație neobișnuită a sesiunilor. O versiune remediată nu există încă, la starea din 25 octombrie; până la următoarea versiune obișnuită de remediere a erorilor, remediul este `session.upload_progress.enabled=0`. O listă de versiuni este așteptată abia odată cu advisory-ul complet.

## Cum ajută PHP SOS concret?

- **Inventar:** Inventariem toate versiunile PHP de pe serverele dumneavoastră, inclusiv instalările secundare pentru site-uri individuale, care sunt ușor trecute cu vederea.
- **Confruntare:** Pentru fiecare instalare clarificăm dacă există o versiune oficială, un backport de distribuție sau nicio corecție.
- **Actualizare cu dovadă:** Prin [serviciul de patch PHP](https://phpsos.de/ro/leistungen/php-patch-service/) aplicăm corecția și repornim toate procesele.
- **Plan de migrare:** Pentru versiunile fără actualizări oficiale planificăm trecerea prin [migrarea de la PHP 8.1 și versiuni mai vechi](https://phpsos.de/ro/leistungen/php-migration-legacy/) și protejăm serverul până atunci.


## Întrebări frecvente

**Mai este PHP 8.3.35 sigur?**  
Nu, dacă furnizorul dumneavoastră nu a aplicat un backport. 8.3.35 este ultima stare dinaintea corecției; PHP2Shell este remediat în ramura 8.3 de la 8.3.36. La pachetele din distribuții, numărul poate rămâne același deși eroarea este remediată. Atunci contează changelogul pachetului sau confirmarea furnizorului.

**Este PHP 7.4 afectat de PHP2Shell?**  
Potrivit presei de specialitate, sunt afectate aproape toate versiunile, până înapoi la PHP 5.4. Pentru 7.4, 8.0 și 8.1 există doar backporturi minime în codul sursă și nicio versiune oficială. Trecerea la o versiune susținută este calea solidă.

**De ce Plesk afișează 8.2.34 deși s-a aplicat patchul?**  
Distribuțiile și furnizorii de hosting preiau uneori corecțiile ca backport în pachetele lor existente. Numărul versiunii rămâne atunci același, iar eroarea este totuși remediată. Verificați starea pachetului sau cereți furnizorului să vă confirme patchul.

**Ce versiune PHP ar trebui să aleg acum?**  
O versiune susținută pe care aplicația dumneavoastră o acceptă conform cerințelor de sistem ale producătorului. PHP 8.2 ajunge la 31.12.2026 la sfârșitul suportului; cine oricum schimbă acum ar trebui să țină cont de asta.

## 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)
- [TechTarget: PHP2Shell, 22M exposed servers at risk](https://www.techtarget.com/cybersecurity/news/366652444/PHP2Shell-22M-exposed-servers-at-risk-as-emergency-patches-released)