Securizarea Apache cu mod_php

Pe scurt: La Apache cu mod_php, PHP rulează direct în serverul web. Echipa PHP evaluează riscul PHP2Shell ca fiind cel mai ridicat tocmai în acest mod de operare, deoarece a fost demonstrat un exploit înainte ca vreun cod al aplicației să ruleze. Actualizați imediat, reporniți complet Apache și planificați apoi trecerea la PHP-FPM.

Ce este mod_php și de ce contează acum

La mod_php, Apache încarcă PHP ca modul în fiecare proces propriu de lucru. Fiecare cerere către un fișier PHP este executată direct în acel proces. Aceasta a fost multă vreme soluția standard și este simplu de configurat. Înseamnă însă și că toate site-urile de pe server rulează cu același utilizator, iar PHP împarte procesul cu serverul web.

PHP2Shell cuprinde vulnerabilitățile CVE-2026-109618 și CVE-2026-109619, ambele cu CVSS v4.0 9.2. La a doua, starea internă a unei cereri poate rămâne după eliberarea memoriei și poate fi folosită de o cerere ulterioară din același proces. Pentru mod_php, echipa PHP a stabilit riscul cel mai ridicat. Contextul și încadrarea găsiți la De ce mod_php prezintă cel mai mare risc.

Recunoașteți Apache mod_php și verificați versiunea

Verificați mai întâi dacă Apache-ul dumneavoastră folosește deloc mod_php. Comenzile următoare doar citesc. Numele comenzilor și ale pachetelor diferă în funcție de distribuție și sunt exemple.

# Debian/Ubuntu: modulele încărcate
apache2ctl -M 2>/dev/null | grep -i php

# Familia RHEL
httpd -M 2>/dev/null | grep -i php

# Ce MPM este activ? mod_php presupune prefork
apache2ctl -V 2>/dev/null | grep -i mpm

# Starea pachetului modulului (exemple)
dpkg -l | grep libapache2-mod-php
rpm -qa | grep -E '^php(-[0-9.]+)?$|^php-common'

Dacă apare un modul precum php_module, rulează mod_php. Versiunea PHP afișată nu este singură o dovadă a patchului, deoarece distribuțiile instalează adesea corecțiile ca backport. Versiunile corectate ale proiectului PHP sunt 8.5.12, 8.4.27, 8.3.36 și 8.2.35. La pachetele distribuției contează jurnalul de modificări cu numerele CVE.

Actualizați și reporniți complet Apache

Instalați actualizarea prin gestionarul de pachete. Deoarece PHP se află în procesul Apache, trebuie apoi repornit întregul serviciu. Reîncărcarea configurației nu este aici calea sigură.

# Debian/Ubuntu
systemctl restart apache2

# Familia RHEL
systemctl restart httpd

# Control: ora de pornire a tuturor proceselor Apache
ps -eo pid,lstart,cmd | grep -E 'apache2|httpd' | grep -v grep

Toate procesele Apache trebuie să arate o oră de pornire ulterioară actualizării. Dacă pe același server rulează în plus PHP-FPM sau php-cgi, reporniți și aceste servicii.

Măsuri provizorii în configurația Apache

php.net indică măsuri provizorii care reduc riscul, dar nu oferă o protecție completă. La mod_php setați valorile cu php_admin_value, respectiv php_admin_flag, în configurația Apache, astfel încât .htaccess și aplicațiile să nu le poată suprascrie.

# Exemplu: în configurația VirtualHost sau la nivel de server
<IfModule php_module>
    php_admin_flag  session.upload_progress.enabled off
    php_admin_value post_max_size 8M
    php_admin_value upload_max_filesize 6M
</IfModule>

Cu funcție de încărcare, php.net indică post_max_size = 32M, cu upload_max_filesize sub această valoare. Pe PHP 8.5 se adaugă fatal_error_backtraces=0. Indicația privind memory_limit=-1 o aplicați doar împreună cu o limită de memorie pentru serviciu prin cgroups, de exemplu cu MemoryMax într-o completare systemd, nu prin RLIMIT_AS sau RLIMIT_DATA. Apoi reporniți complet Apache. Toate măsurile pe scurt: Măsuri imediate fără patch.

Calea de ieșire din mod_php

După patchul acut merită trecerea la PHP-FPM. În acest caz, PHP rulează în procese proprii, separate de serverul web. Fiecare site poate primi un pool propriu, cu utilizator propriu, limitele pot fi setate pentru fiecare pool, iar repornirile afectează doar PHP. Apache conectează PHP-FPM prin mod_proxy_fcgi și poate folosi apoi, în locul prefork, un MPM mai modern, precum event.

Planificați trecerea într-un mediu de test: creați pool-uri pentru fiecare site, adaptați drepturile de fișiere la noii utilizatori, transferați intrările .htaccess cu php_value în setările pool-ului, rulați teste de încărcare. Cum arată o configurație corectă puteți vedea în articolul Securizarea Nginx cu PHP-FPM; principiile se aplică la fel și pentru Apache cu PHP-FPM.

Indiferent de modul de operare, se aplică: un patch nu elimină programele malițioase deja introduse. Păstrați jurnalele începând cu 20.10.2026 și verificați serverul pentru urme.

La căutarea de urme pe serverele cu mod_php merită o privire asupra utilizatorului comun. Deoarece toate site-urile rulează sub utilizatorul Apache, de exemplu www-data sau apache, un atacator care a preluat un site poate, de regulă, citi și modifica și fișierele celorlalte. Verificați de aceea nu doar site-ul care vi se pare suspect, ci toate document-root-urile de pe server. Fiți atenți în special la fișiere PHP cu dată de modificare recentă în directoarele de încărcare și de cache, la codul de program care aparține utilizatorului Apache și la intrări necunoscute în crontab-ul acestui utilizator. Dacă găsiți ceva, salvați mai întâi starea sistemului și nu ștergeți pripit, pentru ca cauza să poată fi reconstituită ulterior.

Cum ajută PHP SOS concret?

• Verificăm modul de operare, MPM-ul și starea pachetelor și evaluăm dacă serverul dumneavoastră este într-adevăr actualizat.
• Prin serviciul de patch PHP instalăm actualizarea, repornim complet Apache și documentăm dovada.
• Până la patch, setăm măsurile provizorii astfel încât să nu poată fi suprascrise și limităm memoria la nivel de serviciu.
• În cadrul securizării serverelor planificăm și testăm trecerea la PHP-FPM, cu pool-uri separate.

Întrebări frecvente

Surse

• php.net: anunțuri de securitate
• PHP 8 ChangeLog
• BSI: Oficiul Federal German pentru Securitatea Informațiilor
• OWASP Cheat Sheets