# Vulnerabilitatea PHP2Shell în Laravel: securizarea corectă a aplicațiilor

> Securizați Laravel după PHP2Shell: verificați PHP cu artisan about, reporniți workerii de coadă și Octane, controlați .env, APP_KEY și directorul storage.

Sursa: https://phpsos.de/ro/plattformen/laravel/  
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:** Vulnerabilitatea Laravel pe care o caută acum mulți dezvoltatori este PHP2Shell și se află în PHP însuși. O actualizare Laravel nu o închide. Contează un PHP cu patch aplicat, repornirea tuturor proceselor, inclusiv a workerilor de coadă și a Octane, precum și o verificare a `.env`, `storage` și `public`.

## Ce înseamnă PHP2Shell pentru aplicațiile Laravel

Laravel este fundația multor dezvoltări proprii: portaluri pentru clienți, instrumente interne, sisteme de rezervări, API-uri pentru aplicații. Potrivit echipei PHP, vulnerabilitățile PHP CVE-2026-109618 și CVE-2026-109619 permit execuția de cod malițios la distanță, fără autentificare. Cât de curat este codul Laravel nu joacă niciun rol în acest caz.

Sunt afectate modurile de operare PHP-FPM, Apache cu mod_php, php-cgi, FrankenPHP și LiteSpeed. Laravel Octane poate folosi FrankenPHP ca server; atunci PHP se află în programul FrankenPHP sau în imaginea de container și este actualizat odată cu acesta. Cum arată situația la FrankenPHP descrie [Securizarea FrankenPHP](https://phpsos.de/ro/server/frankenphp/).

## Vulnerabilitatea Laravel: verificarea versiunii PHP și a proceselor

În linia de comandă, `php artisan about` afișează versiunea PHP, versiunea Laravel și setări importante, precum mediul și modul de depanare. Aceasta este însă versiunea PHP CLI. Cererile web sunt procesate de PHP-FPM sau de Octane, iar acestea pot fi o altă versiune. În caz de îndoială, cereți operatorului să confirme ce stare a pachetului rulează pe toate căile.

Versiunile upstream remediate sunt 8.5.12, 8.4.27, 8.3.36 și 8.2.35, backporturile pot purta numere mai vechi. Ce versiuni PHP sunt acceptate de versiunea dumneavoastră de Laravel verificați conform cerințelor de sistem din documentația de pe laravel.com.

După actualizare urmează partea care este cel mai des uitată la Laravel: procesele cu viață lungă.

```bash
# Afișarea versiunilor și a configurației
php artisan about
# Instruirea workerilor de coadă să se încheie după jobul curent
php artisan queue:restart
# Oprirea Horizon, pentru ca managerul de procese să îl repornească
php artisan horizon:terminate
```

Workerii repornesc după aceea doar dacă un manager de procese, precum Supervisor sau systemd, îi supraveghează. Serverele Octane și containerele trebuie repornite complet, respectiv livrate cu o imagine nouă. Pentru configurațiile cu containere se aplică [Aplicarea patchului PHP în containerele Docker](https://phpsos.de/ro/php2shell/docker-container-patchen/).

## Unde sunt vulnerabile aplicațiile Laravel

| Loc | Conținut | Punct de verificare |
|---|---|---|
| `.env` | `APP_KEY`, baza de date, e-mail, chei API | Nu are voie să fie accesibil niciodată prin web |
| `bootstrap/cache/config.php` | Configurație din cache, cu secrete | Drepturi, data modificării |
| `public/` | Rădăcina documentelor cu `index.php` | Fișiere PHP suplimentare |
| `storage/app/public` | Upload-uri, accesibile prin `public/storage` | Fără fișiere PHP |
| `storage/logs/` | `laravel.log`, adesea cu date ale cererilor | Salvați, nu public |
| `vendor/` | Pachete Composer | `composer audit`, comparație cu `composer.lock` |

Directorul `storage/app/public` este accesibil printr-un link simbolic sub `public/storage`. Un fișier PHP depus acolo poate fi executat direct, în funcție de configurația serverului. Blocați acest lucru la nivelul serverului web.

> **Important:**
> `APP_DEBUG` trebuie să fie `false` în producție. O pagină de eroare cu ieșire de depanare poate arăta variabile de mediu, căi și părți din cod și ușurează munca oricărui atacator.

## Interfețele de administrare și pachetele ca risc

Aplicațiile Laravel nu au o interfață de administrare unitară. Adesea sunt zone proprii sau pachete precum Filament sau Nova. Verificați cine are drepturi de admin, dacă autentificarea are un pas de autentificare în doi pași și dacă rutele de admin trebuie să fie accesibile din exterior. Și token-urile API, de exemplu din Sanctum sau Passport, ar trebui revocate și emise din nou în caz de suspiciune.

Verificați, în plus, dacă instrumente din dezvoltare sunt accesibile în producție, de exemplu bare de depanare, Telescope sau rute de test. Ele arată adesea cereri, interogări și configurație și aparțin în spatele unei autentificări sau trebuie eliminate complet din mediul de producție.

Pachetele Composer sunt al doilea mare bloc. Fiecare dependență aduce cod propriu, iar pachetele fără întreținere blochează ulterior upgrade-urile PHP. `composer audit` arată vulnerabilități cunoscute, dar nu înlocuiește o verificare a codului propriu.

## Ce poate și ce nu poate o actualizare Laravel

O actualizare Laravel sau a unor pachete individuale închide erori cunoscute din acel cod. Ea nu aplică patchul PHP, nu repornește workeri, nu reînnoiește un `APP_KEY` scurs și nu elimină fișiere din `storage` sau `public`. Dacă s-a întâmplat ceva înainte de patch se poate clarifica doar verificând jurnalele, fișierele și baza de date.

Pentru echipele cu pipeline de deployment se aplică: actualizarea PHP aparține și mediului de build și imaginilor de bază, altfel următorul deployment aduce din nou o versiune veche. Verificați, în plus, dacă mediile de staging sau de review sunt accesibile public. Ele rulează adesea cu `APP_DEBUG=true` și cu date reale și sunt ușor trecute cu vederea la actualizările de securitate.

## Cum ajută PHP SOS concret?

- Verificăm PHP-ul web, CLI și al workerilor aplicației dumneavoastră Laravel și însoțim repornirea ordonată a tuturor proceselor.
- Salvăm jurnalele începând cu 20.10.2026, baza de date și starea codului și o comparăm cu repository-ul dumneavoastră.
- Verificăm `.env`, cache-ul de configurație, `storage`, `public`, conturile de admin și token-urile API.
- Pentru o verificare mai aprofundată a codului propriu, mijlocim prin parteneri specializați un [audit de securitate sau un test de penetrare](https://phpsos.de/ro/leistungen/sicherheitsaudit-penetrationstest/).


## Întrebări frecvente

**Trebuie să actualizez Laravel din cauza PHP2Shell?**  
O actualizare Laravel nu închide PHP2Shell, deoarece vulnerabilitatea se află în interpretorul PHP. Țineți totuși Laravel actualizat. Pentru PHP2Shell aveți nevoie de un PHP cu patch aplicat și de repornirea tuturor proceselor PHP, inclusiv a workerilor.

**De ce nu este adesea suficientă repornirea PHP-FPM la Laravel?**  
Workerii de coadă, Horizon, Octane și Scheduler rulează ca procese PHP separate, din linia de comandă. Ele încarcă PHP o singură dată, la pornire, și lucrează apoi mai departe cu versiunea veche din memorie, până când sunt repornite.

**Ce fac dacă fișierul .env s-ar putea să se fi scurs?**  
Atunci ar trebui să reînnoiți APP_KEY, parola bazei de date și toate cheile pentru servicii externe. Rețineți că un APP_KEY nou încheie sesiunile existente și face ilizibile datele criptate cu cheia veche; planificați acest lucru împreună cu dezvoltatorii dumneavoastră.

## Surse

- [php.net: anunțuri de securitate](https://www.php.net/)
- [Laravel](https://laravel.com/)
- [OWASP Cheat Sheets](https://cheatsheetseries.owasp.org/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)