Kort sagt: Ved Drupal PHP-sikkerhed handler det efter PHP2Shell først og fremmest om serveren: Sårbarheden sidder i PHP, ikke i Drupal. Kontrollér PHP-status i statusrapporten og hos driftsleverandøren, genstart alle PHP-processer, og kontrollér derefter settings.php, files-mappen og rollerettighederne.
Drupal og PHP2Shell: situationen
Drupal bruges ofte til større websites, portaler og offentlige myndigheder, ofte med mange redaktører og grænseflader. PHP-sårbarhederne CVE-2026-109618 og CVE-2026-109619 gør det ifølge PHP-teamet muligt at køre skadelig kode på afstand uden login. Hvor godt Drupal selv er vedligeholdt, spiller ingen rolle for det.
Drupal har sit eget sikkerhedsteam, som offentliggør meddelelser om core og moduler. PHP2Shell hører ikke med, fordi det ikke er en Drupal-sårbarhed. Den, der kun følger Drupal-meddelelserne, kan derfor have overset meldingen.
Ved større Drupal-projekter fordeles ansvaret ofte på flere steder: Et bureau vedligeholder koden, et datacenter driver serverne, redaktionen sidder internt. Afklar skriftligt, hvem der indspiller PHP-opdateringen, hvem der udløser genstarten, og hvem der kontrollerer, om der er sket noget før. Ved opsætninger med flere webservere bag en load balancer skal hver enkelt server være patchet og genstartet, ellers bliver en del af forespørgslerne på gammelt PHP.
Drupal PHP-sikkerhed: kontrollér version og patch-status
Under Rapporter > Statusrapport viser Drupal den PHP-version, som websitet kører med, sammen med advarsler om konfigurationen. På kommandolinjen leverer drush status versionen af CLI-PHP, som også cronjobs og deployments kører med. Begge skal være patchet.
Rettede upstream-versioner er 8.5.12, 8.4.27, 8.3.36 og 8.2.35. Distributioner og hostingudbydere indspiller nogle gange rettelser som backport, og så forbliver nummeret det samme; afgørende er den bekræftede pakkestatus. Hvilke PHP-versioner jeres Drupal-version understøtter, kontrollerer I ifølge systemkravene på drupal.org. Efter opdateringen hører genstarten med, beskrevet under Genstart PHP-FPM og alle workers.
Mapper og filer, der tæller
| Sted | Indhold | Kontrolpunkt |
|---|---|---|
sites/default/settings.php |
Database, hash-salt, trusted_host_patterns |
Ændringsdato, indskudte includes |
sites/default/files/ |
offentlige uploads, genererede billeder, CSS og JS | ingen PHP-filer, .htaccess til stede |
| privat filmappe | beskyttede uploads, ofte uden for dokumentroden | Adgangsrettigheder |
modules/contrib/, modules/custom/ |
Moduler fra drupal.org og egenudviklinger | ændrede eller ukendte moduler |
themes/ |
Temaer med Twig-skabeloner | fremmed JavaScript |
vendor/ |
Composer-afhængigheder | composer audit |
Drupal opretter i files-mappen en .htaccess, som forhindrer kørsel af PHP. Under Apache virker den, under Nginx ikke. Dér kræves en egen regel:
location ~* ^/sites/.+/files/.+\.php$ {
deny all;
}
Ufarlige kontroller med standardværktøjer og Drush:
find sites/*/files -type f -name "*.php"
drush pm:list --status=enabled --type=module
composer audit
Sammenlign kodestatus på serveren med jeres Git-repository. Ved Drupal-projekter med Composer er det den hurtigste vej til at finde fremmede eller ændrede filer, for hver afvigelse skal kunne forklares.
Roller, rettigheder og moduler som risiko
Login ligger under /user/login, administrationsområdet under /admin. I Drupal afgør ikke kun administratorkonti sikkerheden, men enkelte tilladelser. Rettigheder som at administrere moduler, brugere, tilladelser eller tekstformater med fuld HTML svarer i praksis til administratorrettigheder. Kontrollér under Personer og Tilladelser, hvilke roller der har dem, og hvem der tilhører disse roller.
Contrib-moduler udvider Drupal kraftigt, men medbringer egen kode. Moduler uden aktiv vedligeholdelse og gamle egenudviklinger er ofte grunden til, at en PHP-opgradering udskydes. Mere om afhængigheder står under Kontrollér Composer-afhængigheder for sårbarheder.
Hvad en Drupal-opdatering kan, og hvad den ikke kan
En core- eller modulopdatering lukker fejl i denne kode og kan gøre nyere PHP-versioner mulige. Den patcher ikke PHP, fjerner ikke fremmede filer fra sites/default/files, nulstiller ikke tilladelser og sletter ikke i det skjulte oprettede konti. Også cachen kan fortsat levere manipuleret indhold, indtil den tømmes. Ved mistanke bør hash-salt og databaseadgang fornyes.
Ved multisite-installationer deler flere websites den samme kode, men har under sites/ hver sin settings.php og sin egen files-mappe. Kontrollér så hvert website for sig. Et fund i ét site berører på grund af den fælles kode som regel alle de andre ligeså.
Hvordan hjælper PHP SOS konkret?
- Vi kontrollerer web- og CLI-PHP på jeres Drupal-server og lader rettelse og genstart bekræfte.
- Vi sikrer logs og data og sammenligner kodestatus med jeres repository eller originalpakkerne.
- Vi kontrollerer
settings.php,files-mappen, serverregler, roller og tilladelser. - På ønske overtager vi den løbende vedligeholdelse i sikkerhedsvedligeholdelsesaftalen, så PHP- og Drupal-opdateringer ikke igen kommer ud af takt.
Ofte stillede spørgsmål
Hjælper en Drupal-sikkerhedsopdatering mod PHP2Shell?
Nej. Drupal-opdateringer lukker fejl i Drupal core og moduler. PHP2Shell ligger i serverens PHP og kræver en PHP-opdatering eller en bekræftet backport samt genstart af alle PHP-processer.
Hvor viser Drupal PHP-versionen?
I statusrapporten under Rapporter. Med Drush viser drush status kommandolinjens PHP-version. Begge oplysninger kan være forskellige, og en backport kan ikke med sikkerhed genkendes ved nogen af dem.
Beskytter .htaccess i files-mappen også under Nginx?
Nej. Den .htaccess, som Drupal opretter, tolkes kun af Apache. Under Nginx har I brug for en egen regel i serverkonfigurationen, som spærrer PHP-filer i files-mappen.
Hvad betyder trusted_host_patterns?
Indstillingen i settings.php fastlægger, under hvilke værtsnavne Drupal svarer. Den beskytter mod angreb via manipulerede værtsoplysninger og hører hjemme i enhver produktiv installation.