Na kratko: Pri varnosti PHP v Drupalu gre po PHP2Shell predvsem za strežnik: ranljivost je v PHP, ne v Drupalu. Preverite stanje PHP v poročilu o stanju in pri upravljavcu, znova zaženite vse procese PHP, nato pa preglejte settings.php, mapo files in pravice vlog.
Drupal in PHP2Shell: položaj
Drupal se pogosto uporablja za večje spletne strani, portale in javne organe, pogosto z veliko urednikov in vmesniki. Ranljivosti PHP CVE-2026-109618 in CVE-2026-109619 po navedbah ekipe PHP omogočata izvajanje škodljive kode na daljavo brez prijave. Kako dobro je vzdrževan sam Drupal, pri tem ni pomembno.
Drupal ima lastno varnostno ekipo, ki objavlja opozorila za jedro in module. PHP2Shell med njimi ni, ker ni ranljivost Drupal. Kdor spremlja samo opozorila Drupal, je zato lahko spregledal to obvestilo.
Pri večjih projektih Drupal je odgovornost pogosto razdeljena na več mest: agencija vzdržuje kodo, podatkovni center upravlja strežnike, uredništvo sedi v hiši. Pisno razjasnite, kdo namesti posodobitev PHP, kdo sproži ponovni zagon in kdo preveri, ali se je prej kaj zgodilo. Pri postavitvah z več spletnimi strežniki za uravnoteževalnikom obremenitve mora biti vsak posamezen strežnik popravljen in znova zagnan, sicer del zahtev ostane na starem PHP.
Varnost PHP v Drupalu: preverite različico in stanje popravkov
Pod Poročila > Poročilo o stanju Drupal prikaže različico PHP, s katero spletna stran teče, skupaj z opozorili o konfiguraciji. V ukazni vrstici drush status vrne različico PHP CLI, s katerim tečejo tudi cron opravila in uvajanja. Oba morata biti popravljena.
Odpravljene različice izvorne kode so 8.5.12, 8.4.27, 8.3.36 in 8.2.35. Distribucije in ponudniki gostovanja popravke deloma vgradijo kot backport, takrat številka ostane enaka; merodajno je potrjeno stanje paketa. Katere različice PHP podpira vaša različica Drupal, preverite v sistemskih zahtevah na drupal.org. Po posodobitvi sodi zraven ponovni zagon, opisan v prispevku Ponovni zagon PHP-FPM in vseh workerjev.
Mape in datoteke, ki štejejo
| Mesto | Vsebina | Točka preverjanja |
|---|---|---|
sites/default/settings.php |
Podatkovna zbirka, hash salt, trusted_host_patterns |
Datum spremembe, vstavljeni include |
sites/default/files/ |
Javna nalaganja, ustvarjene slike, CSS in JS | Brez datotek PHP, .htaccess prisoten |
| Zasebna mapa z datotekami | Zaščitena nalaganja, pogosto zunaj korenske mape dokumentov | Pravice dostopa |
modules/contrib/, modules/custom/ |
Moduli z drupal.org in lastni razvoji | Spremenjeni ali neznani moduli |
themes/ |
Teme s predlogami Twig | Tuj JavaScript |
vendor/ |
Odvisnosti Composerja | composer audit |
Drupal v mapi files ustvari .htaccess, ki preprečuje izvajanje PHP. Pod Apacheem deluje, pod Nginxom ne. Tam je potrebno lastno pravilo:
location ~* ^/sites/.+/files/.+\.php$ {
deny all;
}
Neškodljivi pregledi z vgrajenimi orodji in Drushem:
find sites/*/files -type f -name "*.php"
drush pm:list --status=enabled --type=module
composer audit
Primerjajte stanje kode na strežniku s svojim repozitorijem Git. Pri projektih Drupal s Composerjem je to najhitrejša pot do tujih ali spremenjenih datotek, saj mora biti vsako odstopanje razložljivo.
Vloge, pravice in moduli kot tveganje
Prijava je pod /user/login, upravljalno območje pod /admin. V Drupalu o varnosti ne odločajo samo skrbniški računi, ampak posamezne pravice. Pravice, kot so upravljanje modulov, uporabnikov, dovoljenj ali besedilnih formatov s polnim HTML, so v praksi skrbniške pravice. Pod Ljudje in Dovoljenja preverite, katere vloge jih imajo in kdo spada v te vloge.
Moduli contrib Drupal močno razširijo, vendar prinašajo lastno kodo. Moduli brez aktivnega vzdrževanja in stari lastni razvoji so pogosto razlog, da se nadgradnja PHP odlaga. Več o odvisnostih najdete v prispevku Preverjanje odvisnosti Composerja glede ranljivosti.
Kaj posodobitev Drupal zmore in česa ne
Posodobitev jedra ali modula zapre napake v tej kodi in lahko omogoči novejše različice PHP. PHP ne popravi, ne odstrani tujih datotek iz sites/default/files, ne ponastavi dovoljenj in ne izbriše na skrivaj ustvarjenih računov. Tudi predpomnilnik lahko še naprej dostavlja manipulirano vsebino, dokler se ne izprazni. Ob sumu je treba obnoviti hash salt in dostop do podatkovne zbirke.
Pri namestitvah multisite si več spletnih strani deli isto kodo, pod sites/ pa ima vsaka lastno settings.php in lastno mapo files. Takrat preverite vsako spletno stran posebej. Najdba na eni strani zaradi skupne kode praviloma zadeva tudi vse druge.
Kako PHP SOS pomaga konkretno?
- Preverimo PHP za splet in CLI na vašem strežniku Drupal ter dosežemo potrditev popravka in ponovnega zagona.
- Zavarujemo dnevnike in podatke ter stanje kode primerjamo z vašim repozitorijem ali izvirnimi paketi.
- Nadzorujemo
settings.php, mapofiles, pravila strežnika, vloge in dovoljenja. - Na željo prevzamemo tekoče vzdrževanje v varnostni pogodbi o vzdrževanju, da se posodobitve PHP in Drupal ne razhajajo spet.
Pogosta vprašanja
Ali varnostna posodobitev Drupal pomaga proti PHP2Shell?
Ne. Posodobitve Drupal zapirajo napake v jedru in modulih Drupal. PHP2Shell je v PHP na strežniku in potrebuje posodobitev PHP ali potrjen backport ter ponovni zagon vseh procesov PHP.
Kje Drupal prikaže različico PHP?
V poročilu o stanju pod Poročila. Z Drushem drush status prikaže različico PHP v ukazni vrstici. Podatka se lahko razlikujeta in backporta na nobenem od njiju ni mogoče zanesljivo prepoznati.
Ali .htaccess v mapi files ščiti tudi pod Nginxom?
Ne. Datoteko .htaccess, ki jo ustvari Drupal, upošteva samo Apache. Pod Nginxom potrebujete lastno pravilo v konfiguraciji strežnika, ki datoteke PHP v mapi files blokira.
Kaj pomeni trusted_host_patterns?
Nastavitev v settings.php določa, pod katerimi imeni gostiteljev Drupal odgovarja. Ščiti pred napadi prek manipuliranih podatkov o gostitelju in sodi v vsako produkcijsko namestitev.