# Măsuri imediate dacă nu puteți încă aplica patchul

> Soluție provizorie pentru vulnerabilitatea PHP2Shell: măsurile provizorii de la php.net, setate corect, cu limite și indicații pentru drumul spre patch.

Sursa: https://phpsos.de/ro/php2shell/sofortmassnahmen-ohne-patch/  
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:** O soluție provizorie pentru vulnerabilitatea PHP2Shell poate reduce riscul, dar nu înlocuiește actualizarea. php.net menționează pentru aceasta limite fixe de memorie și de încărcare, dezactivarea session upload progress și, la PHP 8.5, `fatal_error_backtraces=0`. Dacă nici aceasta nu este posibilă pe termen scurt, BSI recomandă scoaterea temporară din rețea a serverului web.

## Ce poate face o soluție provizorie și ce nu

Măsurile provizorii de la php.net trebuie să îngreuneze condițiile în care vulnerabilitățile CVE-2026-109618 și CVE-2026-109619 pot fi exploatate. Ele sunt în mod expres **o protecție incompletă**. Vulnerabilitățile sunt remediate doar în PHP 8.5.12, 8.4.27, 8.3.36 și 8.2.35 sau într-un backport confirmat al furnizorului dumneavoastră.

Măsurile sunt utile atunci când actualizarea nu este încă posibilă dintr-un motiv concret: o fereastră de mentenanță este încă în așteptare, o aplicație trebuie mai întâi testată sau operați PHP 8.1 sau mai vechi, pentru care nu mai există actualizare oficială. Ele sunt atunci o punte, nu un scop.

Planificați, de aceea, odată cu soluția provizorie și actualizarea: cine o realizează, în ce fereastră de mentenanță și cine verifică după aceea că toți workerii au fost reporniți? O tranziție fără dată de încheiere riscă să devină o stare permanentă.

## Opțiunea 1: scoaterea temporară a serverului din rețea

BSI a emis nivelul de avertizare 3 (portocaliu) și recomandă scoaterea temporară din rețea a serverelor web afectate, dacă actualizarea nu este posibilă imediat. Unii furnizori au făcut acest lucru preventiv; asta nu înseamnă că acele site-uri au fost hackuite.

Pentru multe companii, o indisponibilitate a magazinului sau a portalului este costisitoare. O cântărire poate fi utilă: acces doar prin VPN sau adrese IP aprobate, o pagină statică de mentenanță în locul aplicației PHP sau oprirea unor site-uri individuale, nenecesare, de pe server. Cu cât este mai puțin PHP accesibil din exterior, cu atât suprafața de atac este mai mică.

Important este ca decizia să fie luată în mod conștient și consemnată: cine a decis și când să lase serverul online și cu ce măsuri de protecție? Asta ajută ulterior în raport cu asigurătorul, protecția datelor și conducerea.

## Măsurile provizorii de la php.net

| Măsură | Valoare | Observație |
|---|---|---|
| `memory_limit` | `-1`, fără posibilitate de suprascriere | limita de memorie se setează apoi prin container sau cgroup |
| `post_max_size` | `8M` fără încărcări, `32M` cu încărcări | `upload_max_filesize` sub aceasta |
| Limită de memorie | prin container/cgroup | nu prin `RLIMIT_AS` sau `RLIMIT_DATA` |
| `session.upload_progress.enabled` | `0` | în php.ini, pool sau configurația serverului, nu prin `ini_set()` sau `.user.ini` |
| `fatal_error_backtraces` | `0` | doar PHP 8.5 |

Setarea `session.upload_progress.enabled=0` este totodată remediul pentru vulnerabilitatea [CVE-2026-115560](https://phpsos.de/ro/php2shell/cve-2026-115560/), raportată la 23 octombrie.

## Cum setați corect soluția provizorie pentru vulnerabilitatea PHP

Decisiv este locul. Valorile trebuie setate astfel încât o aplicație să nu le poată suprascrie. Căile și numele serviciilor diferă în funcție de distribuție; exemplele pornesc de la PHP 8.3.

**PHP-FPM, în pool** (de ex. `/etc/php/8.3/fpm/pool.d/www.conf`):

```ini
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M
php_admin_value[upload_max_filesize] = 6M
php_admin_flag[session.upload_progress.enabled] = off
; doar PHP 8.5:
; php_admin_flag[fatal_error_backtraces] = off
```

**Apache cu mod_php,** în configurația serverului sau în VirtualHost:

```apache
php_admin_value memory_limit -1
php_admin_value post_max_size 32M
php_admin_value upload_max_filesize 24M
php_admin_flag session.upload_progress.enabled off
```

**Limită de memorie prin cgroup,** aici prin systemd pentru serviciul FPM. Valoarea o adaptați serverului dumneavoastră:

```ini
# sudo systemctl edit php8.3-fpm
[Service]
MemoryMax=2G
```

Apoi reporniți toți workerii, altfel nu acționează nimic din toate acestea: `systemctl restart php8.3-fpm` sau, la mod_php, Apache. Cum verificați că nu mai rulează niciun proces vechi aflați la [Cum reporniți PHP-FPM și toți workerii](https://phpsos.de/ro/php2shell/php-fpm-neustart/). Securizarea generală a configurației o descrie [Cum configurați sigur php.ini](https://phpsos.de/ro/ratgeber/php-ini-sicher-konfigurieren/).

> **Important:**
> Testați încărcările de fișiere și formularele mari după trecere. Un `post_max_size` prea mic poate bloca comenzi, formulare de candidatură sau încărcări de media. Este un motiv să nu amânați mult actualizarea.

## Straturi suplimentare de protecție

Un Web Application Firewall sau patchingul virtual poate ajuta ca strat în plus. Cloudflare a implementat reguli de protecție, dar avertizează chiar el că regulile bazate doar pe datele cererii nu sunt suficiente. Un WAF este, de aceea, o completare, nu un înlocuitor. Mai multe la [WAF și patching virtual](https://phpsos.de/ro/leistungen/waf-virtuelles-patching/).

Salvați în plus logurile serverului începând cu 20 octombrie. Potrivit rapoartelor din presă, o primă tentativă de atac a fost observată deja la 17 octombrie; logurile sunt baza, dacă mai târziu trebuie clarificat dacă înainte de patch s-a întâmplat ceva.

## Cum ajută PHP SOS concret?

- **Clarificarea situației:** Verificăm dacă o actualizare este posibilă pe termen scurt sau dacă este necesară o tranziție și discutăm cu dumneavoastră opțiunea de a scoate părți din rețea.
- **Setarea măsurilor:** Introducem valorile de la php.net în locul potrivit, setăm limita cgroup și repornim toți workerii.
- **Testarea funcționării:** După trecere verificăm formularele, încărcările și procesele de comandă.
- **Drumul spre patch:** Prin [serviciul de patch PHP](https://phpsos.de/ro/leistungen/php-patch-service/) planificăm actualizarea și retragem apoi, în mod controlat, valorile provizorii acolo unde deranjează.


## Întrebări frecvente

**Mă protejează complet soluția provizorie de PHP2Shell?**  
Nu. php.net numește măsurile în mod expres provizorii și nu o protecție completă. Ele reduc riscul până la aplicarea actualizării. BSI (Oficiul Federal German pentru Securitatea Informațiilor) recomandă scoaterea temporară din rețea a serverelor fără patch.

**Pot seta setările prin .htaccess sau .user.ini?**  
Pentru session.upload_progress.enabled, php.net exclude în mod expres ini_set() și .user.ini. Și pentru memory_limit se aplică: valoarea trebuie setată astfel încât aplicația să n-o poată suprascrie. Aceasta reușește în php.ini, în pool-ul FPM cu php_admin_value sau în configurația serverului Apache.

**Este suficient un Web Application Firewall ca soluție provizorie?**  
Ca strat suplimentar poate ajuta. Cloudflare a implementat reguli de protecție, dar subliniază chiar el că regulile bazate doar pe datele cererii nu sunt suficiente. Un WAF nu înlocuiește nici actualizarea, nici măsurile provizorii de pe server.

**Ce fac dacă am doar hosting partajat?**  
Atunci php.ini și repornirea se află la furnizorul de hosting. Întrebați concret dacă actualizarea a fost aplicată sau măsurile provizorii setate și dacă toate procesele PHP au fost repornite.

## Surse

- [php.net: anunțuri de securitate](https://www.php.net/)
- [BSI: Oficiul Federal German pentru Securitatea Informațiilor](https://www.bsi.bund.de/)
- [OWASP Cheat Sheets](https://cheatsheetseries.owasp.org/)