Situația actuală: PHP2Shell. Două vulnerabilități critice PHP (CVSS 9.2) permit cod malițios fără autentificare. Patchuri din 21.10.2026.Ce este de făcut acum →

Cum configurați php.ini în siguranță

Ce setări din php.ini reduc suprafața de atac, cum le protejați împotriva suprascrierii și ce se aplică suplimentar după PHP2Shell.

Stadiu 6 min de cititGhiduri

Pe scurt: Pentru securitatea php.ini contează în primul rând patru domenii: fără mesaje de eroare către exterior, cookieuri de sesiune sigure, încărcări limitate și valori blocate, pe care aplicațiile nu le pot suprascrie. După PHP2Shell se adaugă măsurile provizorii ale php.net, în primul rând session.upload_progress.enabled=0. O configurare sigură nu înlocuiește însă niciodată actualizarea.

De ce este php.ini din nou în atenție după PHP2Shell

php.ini este fișierul central de configurare al PHP. Pe multe servere a fost configurat o dată și apoi abia atins. Cu PHP2Shell, lucrurile s-au schimbat: pentru cele două vulnerabilități CVE-2026-109618 și CVE-2026-109619, php.net indică măsuri provizorii care acționează tocmai aici.

Vulnerabilitățile în sine se află în interpretorul PHP. Au fost corectate în PHP 8.5.12, 8.4.27, 8.3.36 și 8.2.35, publicate la 21.10.2026. O configurare bună ajută totuși în două feluri: poate îngreuna exploatarea și limitează paguba dacă totuși trece ceva.

Mulți operatori nici nu știu exact ce setări se aplică pe serverul lor. Acesta este primul pas.

Ce php.ini se aplică pe serverul dumneavoastră?

În funcție de modul de operare, PHP poate citi fișiere de configurare diferite. Linia de comandă, PHP-FPM și Apache cu mod_php au, de exemplu pe Debian și Ubuntu, câte un dosar propriu sub /etc/php/<version>/. Cine modifică doar fișierul CLI nu schimbă nimic la site.

# Fișierele de configurare ale liniei de comandă
php --ini
# Configurația PHP-FPM (adaptați numărul versiunii)
php-fpm8.3 -i | grep -E "Loaded Configuration|Scan this dir"
# Verificarea valorilor individuale din PHP-FPM
php-fpm8.3 -i | grep -E "^(expose_php|display_errors|session.upload_progress.enabled) "

În plus, valorile pot fi stabilite în pool-ul FPM, în configurația Apache, în .htaccess (doar mod_php) sau în .user.ini (FPM și CGI). Ce versiune rulează efectiv pe server și dacă este inclus un backport clarifică articolul Cum verificați corect versiunea PHP și starea patchului.

Setări de bază pentru mai multă securitate php.ini

Valorile următoare sunt sensibile pentru majoritatea serverelor de producție. Înainte de utilizare, verificați într-un mediu de test dacă aplicația dumneavoastră se descurcă cu toate valorile.

; Fără indicarea versiunii în antetul HTTP
expose_php = Off

; Erorile se înregistrează în log, dar nu se afișează niciodată în browser
display_errors = Off
display_startup_errors = Off
log_errors = On
error_log = /var/log/php/error.log

; Fără includerea de fișiere de la adrese externe
allow_url_include = Off
; allow_url_fopen se lasă activ doar dacă aplicația are nevoie de el
allow_url_fopen = Off

; Sesiuni: stricte, doar prin HTTPS, ilizibile prin JavaScript
session.use_strict_mode = 1
session.use_only_cookies = 1
session.cookie_secure = 1
session.cookie_httponly = 1
session.cookie_samesite = Lax

; Limitarea timpului de execuție și a datelor de intrare
max_execution_time = 30
max_input_time = 60
max_input_vars = 1000

allow_url_fopen este necesar unor aplicații pentru actualizări sau interfețe. Dezactivați-l doar dacă ați verificat acest lucru în prealabil. Funcțiile care execută comenzi de sistem pot fi blocate suplimentar; cum reușiți fără efecte secundare explică ghidul Cum folosiți corect disable_functions.

Măsuri provizorii ale php.net pentru PHP2Shell

Dacă nu puteți aplica imediat patchul, php.net indică mai multe setări care reduc riscul. Ele nu sunt, în mod explicit, o protecție completă, ci o punte până la actualizare.

; Dezactivarea session upload progress (și din cauza CVE-2026-115560)
session.upload_progress.enabled = 0

; Limitarea dimensiunii cererii: 8M fără încărcări, 32M cu încărcări
post_max_size = 8M
upload_max_filesize = 6M

; Doar PHP 8.5: fără backtrace la erori grave
fatal_error_backtraces = 0

În plus, php.net recomandă setarea memory_limit=-1 astfel încât aplicațiile să nu poată suprascrie valoarea, iar limita de memorie să fie stabilită prin container sau cgroup, nu prin RLIMIT_AS sau RLIMIT_DATA. Această măsură aparține pool-ului FPM sau configurației serverului și ar trebui combinată cu o limită cgroup funcțională. Prezentarea completă găsiți la Măsuri imediate dacă nu puteți aplica încă patchul.

Important

session.upload_progress.enabled=0 are efect doar din php.ini, din pool-ul FPM sau din configurația serverului. Dacă este setat prin ini_set() sau .user.ini, măsura nu funcționează. Apoi reporniți toți workerii.

Blocarea valorilor împotriva suprascrierii

Multe aplicații își setează valori proprii, de exemplu pentru memorie sau încărcări. Cu php_admin_value și php_admin_flag fixați setările astfel încât nici ini_set(), nici .user.ini să nu le poată modifica. În pool-ul FPM arată astfel:

; /etc/php/8.3/fpm/pool.d/meine-seite.conf (extras)
php_admin_flag[display_errors] = off
php_admin_flag[session.upload_progress.enabled] = off
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M
php_admin_value[upload_max_filesize] = 6M
php_admin_value[error_log] = /var/log/php/meine-seite.error.log

Pe Apache cu mod_php se aplică aceeași logică, cu php_admin_value și php_admin_flag în configurația VirtualHost. Apoi reîncărcați serviciul și verificați valoarea activă:

sudo systemctl reload php8.3-fpm
# Ora de pornire a proceselor: este ulterioară modificării?
ps -eo pid,lstart,cmd | grep "[p]hp-fpm"

Un reload repornește workerii PHP-FPM. După o actualizare PHP, în schimb, este necesară o repornire completă a tuturor proceselor PHP, pentru ca niciun proces vechi să nu continue să ruleze în memorie. La mai multe site-uri pe un server merită, în plus, un pool propriu pentru fiecare site; mai multe în ghidul open_basedir și izolarea pe site.

Greșeli frecvente și o scurtă listă de verificare

Majoritatea problemelor cu php.ini nu provin din valori greșite, ci din valori puse în locul greșit. Tipic este fișierul CLI modificat, în timp ce site-ul rulează prin PHP-FPM. La fel de des, după o modificare lipsește repornirea sau un panou de hosting suprascrie propria setare la următoarea salvare.

O a doua clasică sunt mesajele de eroare vizibile pe site-ul live. Ele dezvăluie căi, nume de baze de date sau versiuni și ușurează orientarea atacatorilor. Tocmai după o mutare sau o reinstalare, display_errors este adesea din nou pe On.

Verificați aceste puncte după fiecare modificare și după fiecare actualizare PHP:

  1. Ce fișier de configurare citește modul de operare web și conține el valorile dumneavoastră?
  2. Sunt dezactivate display_errors și expose_php, iar logul de erori poate fi scris?
  3. Este session.upload_progress.enabled pe 0, setat prin php.ini sau pool?
  4. Sunt limitate dimensiunile încărcărilor și ale cererilor în funcție de aplicație?
  5. Rulează toate procesele PHP cu un moment de pornire ulterior ultimei modificări?

Consemnați rezultatul cu dată. Astfel se poate dovedi ulterior ce setare s-a aplicat și când.

Cum ajută PHP SOS concret?

  • Stabilim ce configurare este efectiv activă în fiecare mod de operare.
  • Aplicăm o configurare de bază adaptată și măsurile provizorii PHP2Shell, testate cu aplicația dumneavoastră.
  • Blocăm valorile relevante pentru securitate împotriva suprascrierii și repornim controlat toți workerii.
  • Documentăm setările și rezultatul verificării, astfel încât modificările ulterioare să rămână trasabile.

Cum arată o securizare de durată descrie serviciul Securizarea serverelor web PHP.

Întrebări frecvente

Ce php.ini folosește de fapt serverul meu web?

Adesea nu este aceeași ca în linia de comandă. PHP-FPM, Apache cu mod_php și CLI au de obicei dosare de configurare proprii. Verificați de aceea fișierul activ prin modul de operare respectiv, de exemplu cu php-fpm -i sau cu un fișier de test depus pentru scurt timp.

Înlocuiește un php.ini sigur actualizarea PHP?

Nu. Setările reduc suprafața de atac și îngreunează exploatarea, dar nu închid nicio vulnerabilitate din interpretorul PHP. Nici măsurile provizorii ale php.net pentru PHP2Shell nu sunt, în mod explicit, o protecție completă.

Care este diferența dintre php_value și php_admin_value?

Valorile setate cu php_value pot fi modificate din nou de aplicație în timpul rulării. Valorile prin php_admin_value în pool-ul FPM sau în configurația Apache sunt, în schimb, blocate pentru aplicație, inclusiv pentru ini_set() și .user.ini.

Trebuie să repornesc după o modificare în php.ini?

Da. PHP-FPM și Apache cu mod_php citesc configurația doar la pornire. Valorile noi se aplică abia după o repornire sau un reload al tuturor serviciilor afectate.

Surse

Contact imediat

Fiecare oră contează. Scrieți-ne acum.

Descrieți pe scurt sistemul, versiunea PHP și ce ați observat. Ne vom face auziți, clarificăm situația și lucrăm la distanță până când incidentul este încheiat și documentat.

Ajutor imediat