Pe scurt: La securitatea PHP în Drupal, după PHP2Shell, este vorba în primul rând de server: vulnerabilitatea se află în PHP, nu în Drupal. Verificați starea PHP în raportul de stare și la operator, reporniți toate procesele PHP și controlați apoi settings.php, directorul files și drepturile rolurilor.
Drupal și PHP2Shell: situația
Drupal este folosit frecvent pentru site-uri mai mari, portaluri și instituții publice, adesea cu mulți redactori și interfețe. Potrivit echipei PHP, vulnerabilitățile PHP CVE-2026-109618 și CVE-2026-109619 permit cod malițios la distanță, fără autentificare. Cât de bine este întreținut Drupal însuși nu joacă niciun rol în acest caz.
Drupal are o echipă proprie de securitate, care publică avertismente despre nucleu și module. PHP2Shell nu se numără printre ele, deoarece nu este o vulnerabilitate Drupal. Cine urmărește doar avertismentele Drupal poate, de aceea, să fi trecut cu vederea știrea.
La proiectele Drupal mai mari, responsabilitatea este adesea împărțită între mai multe părți: o agenție întreține codul, un centru de date operează serverele, redacția este în casă. Clarificați în scris cine aplică actualizarea PHP, cine declanșează repornirea și cine verifică dacă s-a întâmplat ceva înainte. La configurațiile cu mai multe servere web în spatele unui load balancer, fiecare server în parte trebuie să aibă patchul aplicat și să fie repornit, altfel o parte din cereri rămâne pe PHP vechi.
Securitatea PHP în Drupal: verificarea versiunii și a stării patchului
La Rapoarte > Raport de stare, Drupal afișează versiunea PHP cu care rulează site-ul, împreună cu avertismente privind configurația. În linia de comandă, drush status furnizează versiunea PHP CLI, cu care rulează și cronjob-urile și deployment-urile. Ambele trebuie să aibă patchul aplicat.
Versiunile upstream remediate sunt 8.5.12, 8.4.27, 8.3.36 și 8.2.35. Distribuțiile și furnizorii de hosting aplică uneori corecțiile ca backport, caz în care numărul rămâne același; determinantă este starea confirmată a pachetului. Ce versiuni PHP sunt acceptate de versiunea dumneavoastră de Drupal verificați conform cerințelor de sistem de pe drupal.org. După actualizare, repornirea face parte din proces, descrisă la Repornirea PHP-FPM și a tuturor workerilor.
Directoare și fișiere care contează
| Loc | Conținut | Punct de verificare |
|---|---|---|
sites/default/settings.php |
Baza de date, hash salt, trusted_host_patterns |
Data modificării, include-uri strecurate |
sites/default/files/ |
Upload-uri publice, imagini generate, CSS și JS | Fără fișiere PHP, .htaccess prezent |
| Directorul privat de fișiere | Upload-uri protejate, adesea în afara rădăcinii documentelor | Drepturi de acces |
modules/contrib/, modules/custom/ |
Module de pe drupal.org și dezvoltări proprii | Module modificate sau necunoscute |
themes/ |
Teme cu șabloane Twig | JavaScript străin |
vendor/ |
Dependențe Composer | composer audit |
Drupal creează în directorul files un .htaccess care împiedică execuția PHP. Sub Apache funcționează, sub Nginx nu. Acolo este nevoie de o regulă proprie:
location ~* ^/sites/.+/files/.+\.php$ {
deny all;
}
Verificări inofensive cu mijloace de bază și Drush:
find sites/*/files -type f -name "*.php"
drush pm:list --status=enabled --type=module
composer audit
Comparați starea codului de pe server cu repository-ul dumneavoastră Git. La proiectele Drupal cu Composer, aceasta este cea mai rapidă cale de a găsi fișiere străine sau modificate, deoarece orice abatere trebuie să poată fi explicată.
Rolurile, drepturile și modulele ca risc
Autentificarea se află la /user/login, zona de administrare la /admin. În Drupal, securitatea nu este decisă doar de conturile de administrator, ci și de permisiuni individuale. Drepturi precum gestionarea modulelor, a utilizatorilor, a permisiunilor sau a formatelor de text cu HTML complet sunt practic drepturi de administrator. Verificați la Persoane și Permisiuni ce roluri le au și cine aparține acestor roluri.
Modulele contrib extind puternic Drupal, dar aduc cod propriu. Modulele fără întreținere activă și dezvoltările proprii vechi sunt adesea motivul pentru care un upgrade PHP este amânat. Mai multe despre dependențe găsiți la Verificarea vulnerabilităților din dependențele Composer.
Ce poate și ce nu poate o actualizare Drupal
O actualizare de nucleu sau de modul închide erori din acel cod și poate permite versiuni PHP mai noi. Ea nu aplică patchul PHP, nu elimină fișiere străine din sites/default/files, nu resetează permisiuni și nu șterge conturi create pe ascuns. Și cache-ul poate continua să livreze conținut manipulat, până când este golit. În caz de suspiciune, hash salt-ul și accesul la baza de date trebuie reînnoite.
La instalările multisite, mai multe site-uri împart același cod, dar au sub sites/ fiecare un settings.php propriu și un director files propriu. Verificați atunci fiecare site în parte. O descoperire într-un site afectează, din cauza codului comun, de obicei și pe toate celelalte.
Cum ajută PHP SOS concret?
- Verificăm PHP-ul web și CLI al serverului dumneavoastră Drupal și punem să fie confirmate patchul și repornirea.
- Salvăm jurnalele și datele și comparăm starea codului cu repository-ul dumneavoastră sau cu pachetele originale.
- Controlăm
settings.php, directorulfiles, regulile serverului, rolurile și permisiunile. - La cerere, preluăm întreținerea continuă în contractul de mentenanță de securitate, pentru ca actualizările PHP și Drupal să nu mai ajungă din nou la ritmuri diferite.
Întrebări frecvente
Ajută o actualizare de securitate Drupal împotriva PHP2Shell?
Nu. Actualizările Drupal închid erori din nucleul Drupal și din module. PHP2Shell se află în PHP-ul serverului și necesită o actualizare PHP sau un backport confirmat, precum și repornirea tuturor proceselor PHP.
Unde afișează Drupal versiunea PHP?
În raportul de stare, la Rapoarte. Cu Drush, drush status arată versiunea PHP din linia de comandă. Cele două informații pot diferi, iar un backport nu poate fi recunoscut cu siguranță din niciuna dintre ele.
Protejează .htaccess din directorul files și sub Nginx?
Nu. Fișierul .htaccess creat de Drupal este evaluat doar de Apache. Sub Nginx aveți nevoie de o regulă proprie în configurația serverului, care blochează fișierele PHP din directorul files.
Ce înseamnă trusted_host_patterns?
Setarea din settings.php stabilește sub ce nume de gazdă răspunde Drupal. Ea protejează împotriva atacurilor prin indicații de gazdă manipulate și aparține fiecărei instalări de producție.