Kort sagt: Vid Drupal PHP-säkerhet handlar det efter PHP2Shell framför allt om servern: sårbarheten finns i PHP, inte i Drupal. Kontrollera PHP-statusen i statusrapporten och hos driftleverantören, starta om alla PHP-processer och kontrollera därefter settings.php, katalogen files och rollbehörigheterna.
Drupal och PHP2Shell: läget
Drupal används ofta för större webbplatser, portaler och offentliga organ, ofta med många redaktörer och gränssnitt. PHP-sårbarheterna CVE-2026-109618 och CVE-2026-109619 gör det enligt PHP-teamet möjligt att köra skadlig kod på distans utan inloggning. Hur väl Drupal självt underhålls spelar ingen roll för detta.
Drupal har ett eget säkerhetsteam som publicerar meddelanden om kärnan och moduler. PHP2Shell hör inte dit, eftersom det inte är en Drupal-sårbarhet. Den som bara följer Drupal-meddelandena kan därför ha missat larmet.
I större Drupal-projekt är ansvaret ofta fördelat på flera parter: en byrå sköter koden, ett datacenter driver servrarna, redaktionen sitter internt. Klargör skriftligen vem som installerar PHP-uppdateringen, vem som utlöser omstarten och vem som kontrollerar om något hänt tidigare. Vid uppsättningar med flera webbservrar bakom en lastbalanserare måste varje enskild server vara patchad och omstartad, annars hamnar en del av förfrågningarna kvar på gammalt PHP.
Drupal PHP-säkerhet: kontrollera version och patchstatus
Under Rapporter > Statusrapport visar Drupal den PHP-version som webbplatsen körs med, tillsammans med varningar om konfigurationen. På kommandoraden ger drush status versionen av CLI-PHP, som även cronjobb och driftsättningar använder. Båda måste vara patchade.
Åtgärdade upstream-versioner är 8.5.12, 8.4.27, 8.3.36 och 8.2.35. Distributioner och webbhotell levererar ibland rättningar som backport, och då förblir numret detsamma; avgörande är den bekräftade paketstatusen. Vilka PHP-versioner er Drupal-version stöder kontrollerar ni enligt systemkraven på drupal.org. Efter uppdateringen hör omstarten till, beskriven under Starta om PHP-FPM och alla workers.
Kataloger och filer som räknas
| Plats | Innehåll | Kontrollpunkt |
|---|---|---|
sites/default/settings.php |
Databas, hash-salt, trusted_host_patterns |
Ändringsdatum, inskjutna includes |
sites/default/files/ |
publika uppladdningar, genererade bilder, CSS och JS | inga PHP-filer, .htaccess finns |
| privat filkatalog | skyddade uppladdningar, ofta utanför dokumentroten | Åtkomsträttigheter |
modules/contrib/, modules/custom/ |
moduler från drupal.org och egenutvecklingar | ändrade eller okända moduler |
themes/ |
teman med Twig-mallar | främmande JavaScript |
vendor/ |
Composer-beroenden | composer audit |
Drupal skapar i katalogen files en .htaccess som förhindrar körning av PHP. Under Apache fungerar den, under Nginx inte. Där behövs en egen regel:
location ~* ^/sites/.+/files/.+\.php$ {
deny all;
}
Ofarliga kontroller med inbyggda verktyg och Drush:
find sites/*/files -type f -name "*.php"
drush pm:list --status=enabled --type=module
composer audit
Jämför kodläget på servern med ert Git-repository. I Drupal-projekt med Composer är det det snabbaste sättet att hitta främmande eller ändrade filer, eftersom varje avvikelse måste gå att förklara.
Roller, behörigheter och moduler som risk
Inloggningen ligger under /user/login, administrationsområdet under /admin. I Drupal avgör inte bara administratörskonton säkerheten utan enskilda behörigheter. Rättigheter som att hantera moduler, användare, behörigheter eller textformat med fullständig HTML är i praktiken administratörsrättigheter. Kontrollera under Personer och Behörigheter vilka roller som har dem och vem som tillhör dessa roller.
Contrib-moduler utökar Drupal kraftigt men har egen kod. Moduler utan aktivt underhåll och gamla egenutvecklingar är ofta orsaken till att en PHP-uppgradering skjuts upp. Mer om beroenden finns under Kontrollera Composer-beroenden för sårbarheter.
Vad en Drupal-uppdatering klarar och inte klarar
En kärn- eller moduluppdatering stänger fel i den koden och kan möjliggöra nyare PHP-versioner. Den patchar inte PHP, tar inte bort främmande filer ur sites/default/files, återställer inga behörigheter och raderar inga i smyg skapade konton. Även cachen kan fortsätta leverera manipulerat innehåll tills den töms. Vid misstanke ska hash-salt och databasåtkomst förnyas.
Vid multisite-installationer delar flera webbplatser samma kod, men har under sites/ var sin settings.php och var sin files-katalog. Kontrollera då varje webbplats för sig. Ett fynd på en site berör på grund av den gemensamma koden oftast alla andra också.
Hur hjälper PHP SOS konkret?
- Vi kontrollerar webb- och CLI-PHP på er Drupal-server och låter patch och omstart bekräftas.
- Vi säkrar loggar och data och jämför kodläget med ert repository eller originalpaketen.
- Vi kontrollerar
settings.php, katalogenfiles, serverregler, roller och behörigheter. - På begäran tar vi över det löpande underhållet i säkerhetsunderhållsavtalet, så att PHP- och Drupal-uppdateringar inte åter glider isär.
Vanliga frågor
Hjälper en Drupal-säkerhetsuppdatering mot PHP2Shell?
Nej. Drupal-uppdateringar stänger fel i Drupal-kärnan och moduler. PHP2Shell finns i serverns PHP och kräver en PHP-uppdatering eller en bekräftad backport samt omstart av alla PHP-processer.
Var visar Drupal PHP-versionen?
I statusrapporten under Rapporter. Med Drush visar drush status kommandoradens PHP-version. De båda uppgifterna kan skilja sig åt, och en backport går inte att känna igen säkert på någon av dem.
Skyddar .htaccess i files-mappen även under Nginx?
Nej. Den .htaccess som Drupal skapar tolkas bara av Apache. Under Nginx behöver ni en egen regel i serverkonfigurationen som spärrar PHP-filer i files-katalogen.
Vad betyder trusted_host_patterns?
Inställningen i settings.php bestämmer under vilka värdnamn Drupal svarar. Den skyddar mot attacker via manipulerade värduppgifter och hör hemma i varje produktionsinstallation.