Lyhyesti: Drupalin PHP-tietoturvassa on PHP2Shellin jälkeen kyse ennen kaikkea palvelimesta: aukko on PHP:ssä, ei Drupalissa. Tarkistakaa PHP:n tila tilaraportista ja palveluntarjoajalta, käynnistäkää kaikki PHP-prosessit uudelleen ja kontrolloikaa sen jälkeen settings.php, files-hakemisto ja roolioikeudet.
Drupal ja PHP2Shell: tilanne
Drupalia käytetään usein suuremmilla sivustoilla, portaaleissa ja julkisilla toimijoilla, usein monine toimittajineen ja rajapintoineen. PHP-tiimin mukaan PHP-haavoittuvuudet CVE-2026-109618 ja CVE-2026-109619 sallivat haittakoodin suorittamisen etänä ilman kirjautumista. Sillä, kuinka hyvin Drupalia itseään ylläpidetään, ei ole tässä merkitystä.
Drupalilla on oma tietoturvatiiminsä, joka julkaisee ilmoituksia ytimestä ja moduuleista. PHP2Shell ei kuulu niihin, koska se ei ole Drupal-aukko. Jos seuraa vain Drupal-ilmoituksia, tiedon on siksi voinut jäädä huomaamatta.
Suuremmissa Drupal-hankkeissa vastuu jakautuu usein usealle taholle: toimisto ylläpitää koodia, konesali pyörittää palvelimia ja toimitus on talon sisällä. Sopikaa kirjallisesti, kuka asentaa PHP-päivityksen, kuka käynnistää uudelleen ja kuka tarkistaa, onko aiemmin tapahtunut jotain. Asennuksissa, joissa kuormantasaajan takana on useita verkkopalvelimia, jokainen yksittäinen palvelin on korjattava ja käynnistettävä uudelleen, muuten osa pyynnöistä jää vanhalle PHP:lle.
Drupalin PHP-tietoturva: version ja korjaustilan tarkistus
Kohta Raportit > Tilaraportti näyttää PHP-version, jolla sivusto toimii, sekä asetuksia koskevat varoitukset. Komentorivillä drush status antaa CLI-PHP:n version, jolla toimivat myös cron-ajot ja käyttöönotot. Molempien on oltava korjattuja.
Korjatut upstream-versiot ovat 8.5.12, 8.4.27, 8.3.36 ja 8.2.35. Jakelut ja hosting-yritykset tuovat korjaukset osin backporttina, jolloin numero pysyy samana; ratkaisevaa on vahvistettu pakettitila. Mitä PHP-versioita teidän Drupal-versionne tukee, tarkistatte järjestelmävaatimuksista osoitteessa drupal.org. Päivityksen jälkeen uudelleenkäynnistys kuuluu asiaan; se on kuvattu sivulla PHP-FPM:n ja kaikkien workerien uudelleenkäynnistys.
Hakemistot ja tiedostot, joilla on merkitystä
| Paikka | Sisältö | Tarkistuskohde |
|---|---|---|
sites/default/settings.php |
Tietokanta, hash-suola, trusted_host_patterns |
Muutospäivä, sisään ujutetut include-rivit |
sites/default/files/ |
julkiset lataukset, generoidut kuvat, CSS ja JS | ei PHP-tiedostoja, .htaccess olemassa |
| yksityinen tiedostohakemisto | suojatut lataukset, usein dokumenttijuuren ulkopuolella | Käyttöoikeudet |
modules/contrib/, modules/custom/ |
drupal.orgin moduulit ja omat kehitykset | muutetut tai tuntemattomat moduulit |
themes/ |
Teemat Twig-mallipohjineen | vieras JavaScript |
vendor/ |
Composer-riippuvuudet | composer audit |
Drupal luo files-hakemistoon .htaccess-tiedoston, joka estää PHP:n suorittamisen. Apachella se toimii, Nginxillä ei. Siellä tarvitaan oma sääntö:
location ~* ^/sites/.+/files/.+\.php$ {
deny all;
}
Vaarattomat tarkistukset järjestelmän omilla työkaluilla ja Drushilla:
find sites/*/files -type f -name "*.php"
drush pm:list --status=enabled --type=module
composer audit
Verratkaa palvelimen koodin tilaa Git-repositorioonne. Composer-pohjaisissa Drupal-hankkeissa se on nopein tapa löytää vieraita tai muutettuja tiedostoja, sillä jokaisen poikkeaman on oltava selitettävissä.
Roolit, oikeudet ja moduulit riskinä
Kirjautuminen on osoitteessa /user/login, hallinta osoitteessa /admin. Drupalissa tietoturvasta ei päätä vain ylläpitäjätilit, vaan yksittäiset oikeudet. Oikeudet moduulien, käyttäjien, oikeuksien tai täyttä HTML:ää sallivien tekstimuotojen hallintaan ovat käytännössä ylläpitäjän oikeuksia. Tarkistakaa kohdista Ihmiset ja Oikeudet, mitkä roolit ne omaavat ja ketkä näihin rooleihin kuuluvat.
Contrib-moduulit laajentavat Drupalia paljon, mutta tuovat omaa koodia. Moduulit ilman aktiivista ylläpitoa ja vanhat omat kehitykset ovat usein syy siihen, että PHP-päivitys lykkääntyy. Lisää riippuvuuksista sivulla Composer-riippuvuuksien aukkojen tarkistus.
Mihin Drupal-päivitys pystyy ja mihin ei
Ytimen tai moduulin päivitys sulkee tämän koodin virheitä ja voi mahdollistaa uudemmat PHP-versiot. Se ei korjaa PHP:tä, ei poista vieraita tiedostoja hakemistosta sites/default/files, ei nollaa oikeuksia eikä poista salaa luotuja tilejä. Myös välimuisti voi jatkaa muokatun sisällön toimittamista, kunnes se tyhjennetään. Epäilyn jälkeen hash-suola ja tietokantatunnukset kuuluu uusia.
Multisite-asennuksissa useat sivustot jakavat saman koodin, mutta niillä on hakemistossa sites/ kullakin oma settings.php ja oma files-hakemisto. Tarkistakaa silloin jokainen sivusto erikseen. Löydös yhdellä sivustolla koskee yhteisen koodin vuoksi yleensä kaikkia muitakin.
Miten PHP SOS auttaa konkreettisesti?
- Tarkistamme Drupal-palvelimenne web- ja CLI-PHP:n ja varmennamme korjauksen ja uudelleenkäynnistyksen.
- Varmuuskopioimme lokit ja tiedot ja vertaamme koodin tilaa repositorioonne tai alkuperäispaketteihin.
- Kontrolloimme
settings.php:n,files-hakemiston, palvelinsäännöt, roolit ja oikeudet. - Pyynnöstä hoidamme jatkuvan ylläpidon tietoturvahuoltosopimuksessa, jotta PHP- ja Drupal-päivitykset eivät taas eriydy.
Usein kysytyt kysymykset
Auttaako Drupalin tietoturvapäivitys PHP2Shelliä vastaan?
Ei. Drupal-päivitykset sulkevat Drupalin ytimen ja moduulien virheitä. PHP2Shell on palvelimen PHP:ssä ja vaatii PHP-päivityksen tai vahvistetun backportin sekä kaikkien PHP-prosessien uudelleenkäynnistyksen.
Mistä Drupal näyttää PHP-version?
Tilaraportista kohdassa Raportit. Drushilla drush status näyttää komentorivin PHP-version. Tiedot voivat poiketa toisistaan, eikä backportia tunnista varmasti kummastakaan.
Suojaako files-kansion .htaccess myös Nginxillä?
Ei. Drupalin luoma .htaccess toimii vain Apachella. Nginxillä tarvitaan oma sääntö palvelimen asetuksiin, joka estää PHP-tiedostot files-hakemistossa.
Mitä trusted_host_patterns tarkoittaa?
Tiedoston settings.php asetus määrittää, millä isäntänimillä Drupal vastaa. Se suojaa hyökkäyksiltä muokattujen Host-tietojen kautta ja kuuluu jokaiseen tuotantoasennukseen.