Ukratko: Kod Drupal PHP sigurnosti nakon PHP2Shella ponajprije je riječ o poslužitelju: ranjivost je u PHP-u, a ne u Drupalu. Provjerite stanje PHP-a u izvješću o stanju i kod operatera, ponovno pokrenite sve PHP procese, a potom pregledajte settings.php, direktorij files i prava uloga.
Drupal i PHP2Shell: situacija
Drupal se često koristi za veće web-stranice, portale i javna tijela, često s mnogo urednika i sučelja. PHP ranjivosti CVE-2026-109618 i CVE-2026-109619 prema PHP timu omogućuju zlonamjerni kôd na daljinu bez prijave. Koliko je sam Drupal dobro održavan, pritom nije važno.
Drupal ima vlastiti sigurnosni tim koji objavljuje napomene o jezgri i modulima. PHP2Shell među njih ne spada jer nije Drupal ranjivost. Tko prati samo Drupal napomene, stoga je mogao previdjeti tu objavu.
Kod većih Drupal projekata odgovornost je često raspoređena na više mjesta: agencija održava kôd, računalni centar upravlja poslužiteljima, redakcija sjedi u kući. Pisano razjasnite tko ugrađuje PHP ažuriranje, tko pokreće ponovno pokretanje i tko provjerava je li se prije toga nešto dogodilo. Kod postava s više web-poslužitelja iza load balancera svaki pojedini poslužitelj mora biti zakrpan i ponovno pokrenut, inače dio zahtjeva ostaje na starom PHP-u.
Drupal PHP sigurnost: provjera verzije i stanja zakrpe
Pod Izvješća > Izvješće o stanju Drupal prikazuje verziju PHP-a s kojom web-stranica radi, zajedno s upozorenjima o konfiguraciji. U naredbenom retku drush status daje verziju CLI PHP-a s kojim rade i cron zadaci i deploymenti. Oba moraju biti zakrpana.
Ispravljene upstream verzije su 8.5.12, 8.4.27, 8.3.36 i 8.2.35. Distribucije i pružatelji hostinga ispravke ponekad ugrađuju kao backport, tada broj ostaje isti; mjerodavno je potvrđeno stanje paketa. Koje PHP verzije podržava Vaša verzija Drupala, provjerite prema sistemskim zahtjevima na drupal.org. Nakon ažuriranja ponovno pokretanje je obvezno, a opisano je na stranici Ponovno pokretanje PHP-FPM-a i svih workera.
Direktoriji i datoteke koji su važni
| Mjesto | Sadržaj | Točka provjere |
|---|---|---|
sites/default/settings.php |
Baza podataka, hash salt, trusted_host_patterns |
Datum izmjene, umetnuti includeovi |
sites/default/files/ |
Javni uploadi, generirane slike, CSS i JS | Nema PHP datoteka, .htaccess postoji |
| Privatni direktorij datoteka | Zaštićeni uploadi, često izvan korijena dokumenata | Prava pristupa |
modules/contrib/, modules/custom/ |
Moduli s drupal.org i vlastiti razvoji | Izmijenjeni ili nepoznati moduli |
themes/ |
Teme s Twig predlošcima | Strani JavaScript |
vendor/ |
Composer ovisnosti | composer audit |
Drupal u direktoriju files stvara .htaccess koji sprječava izvršavanje PHP-a. Pod Apacheom djeluje, pod Nginxom ne. Tamo je potrebno vlastito pravilo:
location ~* ^/sites/.+/files/.+\.php$ {
deny all;
}
Neopasne provjere ugrađenim alatima i Drushom:
find sites/*/files -type f -name "*.php"
drush pm:list --status=enabled --type=module
composer audit
Usporedite stanje kôda na poslužitelju sa svojim Git repozitorijem. Kod Drupal projekata s Composerom to je najbrži put do stranih ili izmijenjenih datoteka jer svako odstupanje mora biti objašnjivo.
Uloge, prava i moduli kao rizik
Prijava se nalazi na /user/login, a administracijsko područje na /admin. U Drupalu o sigurnosti ne odlučuju samo administratorski računi, nego i pojedinačna ovlaštenja. Prava poput upravljanja modulima, korisnicima, ovlaštenjima ili formatima teksta s punim HTML-om praktički su administratorska prava. Pod Osobe i Ovlaštenja provjerite koje uloge ih imaju i tko tim ulogama pripada.
Contrib moduli znatno proširuju Drupal, ali donose vlastiti kôd. Moduli bez aktivnog održavanja i stari vlastiti razvoji često su razlog zašto se nadogradnja PHP-a odgađa. Više o ovisnostima na stranici Provjera Composer ovisnosti na ranjivosti.
Što Drupal ažuriranje postiže, a što ne
Ažuriranje jezgre ili modula zatvara pogreške u tom kôdu i može omogućiti novije verzije PHP-a. Ne zakrpava PHP, ne uklanja strane datoteke iz sites/default/files, ne vraća ovlaštenja na početno stanje i ne briše potajno stvorene račune. I predmemorija može i dalje isporučivati manipulirani sadržaj dok se ne isprazni. Nakon sumnje hash salt i pristup bazi podataka treba obnoviti.
Kod multisite instalacija više web-stranica dijeli isti kôd, ali pod sites/ svaka ima vlastiti settings.php i vlastiti direktorij files. Tada provjerite svaku web-stranicu zasebno. Nalaz na jednoj stranici zbog zajedničkog kôda uglavnom pogađa i sve ostale.
Kako PHP SOS konkretno pomaže?
- Provjeravamo web i CLI PHP Vašeg Drupal poslužitelja te dajemo potvrditi zakrpu i ponovno pokretanje.
- Osiguravamo logove i podatke te uspoređujemo stanje kôda s Vašim repozitorijem ili originalnim paketima.
- Kontroliramo
settings.php, direktorijfiles, pravila poslužitelja, uloge i ovlaštenja. - Na zahtjev preuzimamo trajno održavanje u sigurnosnom ugovoru o održavanju kako PHP i Drupal ažuriranja ne bi ponovno otišla različitim putovima.
Česta pitanja
Pomaže li Drupal sigurnosno ažuriranje protiv PHP2Shella?
Ne. Drupal ažuriranja zatvaraju pogreške u Drupal jezgri i modulima. PHP2Shell je u PHP-u poslužitelja i treba PHP ažuriranje ili potvrđeni backport te ponovno pokretanje svih PHP procesa.
Gdje Drupal prikazuje verziju PHP-a?
U izvješću o stanju pod Izvješća. S Drushom naredba drush status prikazuje verziju PHP-a naredbenog retka. Oba podatka mogu se razlikovati, a backport se ni po jednom ne može pouzdano prepoznati.
Štiti li .htaccess u mapi files i pod Nginxom?
Ne. .htaccess koji stvara Drupal tumači samo Apache. Pod Nginxom Vam je potrebno vlastito pravilo u konfiguraciji poslužitelja koje blokira PHP datoteke u direktoriju files.
Što znači trusted_host_patterns?
Postavka u settings.php određuje pod kojim imenima poslužitelja Drupal odgovara. Štiti od napada putem manipuliranih podataka o hostu i pripada u svaku produkcijsku instalaciju.