cPanel och WHM: säkra PHP

Kort sagt: En cPanel PHP-uppdatering efter PHP2Shell består av tre steg: alla ea-php-paket och eventuellt alt-php-paket ska ha en åtgärdad version, PHP-FPM och Apache ska startas om helt och paketstatusen ska dokumenteras. Kunder på servern kan inte själva sätta de viktigaste tillfälliga värdena, det måste WHM-administratören göra.

Utgångsläget på cPanel-servrar

PHP2Shell omfattar sårbarheterna CVE-2026-109618 och CVE-2026-109619 i PHP självt. Båda gör det möjligt att köra skadlig kod utan inloggning och är bedömda med CVSS v4.0 9,2. PHP-FPM, Apache med mod_php, php-cgi, FrankenPHP och LiteSpeed berörs. PHP-projektet publicerade den 21 oktober 2026 versionerna 8.5.12, 8.4.27, 8.3.36 och 8.2.35.

cPanel levererar inte PHP som ett enskilt paket utan via EasyApache 4, med en paketuppsättning per version, till exempel ea-php83 eller ea-php84. Därtill kommer på vissa servrar operativsystemets paket och på CloudLinux alt-php-versionerna. Varje källa har sin egen status. En fullständig bild får ni först när ni kontrollerar alla tre.

cPanel PHP-uppdatering: kontrollera bestånd och koppling

Börja med en inventering. Följande kommandon läser bara och ändrar ingenting. Sökvägar och paketnamn är exempel och kan avvika beroende på installationen.

# Installerade PHP-versioner enligt WHM-API:et
whmapi1 php_get_installed_versions

# Version per ea-php-installation
for p in /opt/cpanel/ea-php*/root/usr/bin/php; do echo "$p"; "$p" -v | head -1; done

# Paketstatus (RPM-baserade system, exempel)
rpm -qa | grep -E '^ea-php[0-9]+-php-(cli|fpm|common)' | sort

I MultiPHP Manager ser ni vilken domän som använder vilken version och om PHP-FPM är aktiverat. Notera versioner som är installerade men inte tilldelade någon domän. Även de ska uppdateras eller tas bort.

Tolka backports rätt

Precis som hos andra leverantörer gäller: det visade versionsnumret är inte det enda måttet. Om en rättning levereras som backport kan numret förbli oförändrat. Kontrollera därför dessutom paketets ändringslogg och leverantörens anvisningar.

# Sök i ett pakets ändringslogg efter CVE-nummer (exempel)
rpm -q --changelog ea-php84-php-cli | grep -iE 'CVE-2026-1096(18|19)'

Om ingen post hittas betyder det inte automatiskt att rättningen saknas. Det betyder dock att ni behöver en skriftlig bekräftelse innan ni klassar servern som patchad. Hur ni läser versioner rätt beskrivs under Kontrollera PHP-version och patchstatus.

Uppdatering, omstart och kontroll

Uppdateringen installerar ni i WHM via systemuppdateringen eller med pakethanteringen. Därefter startar ni om alla PHP-processer. Nya filer räcker inte så länge gamla processer ligger kvar i minnet.

# Starta om PHP-FPM-tjänsterna för alla versioner (cPanel-skript)
/scripts/restartsrv_apache_php_fpm

# Starta om Apache helt
/scripts/restartsrv_httpd

# Kontrollera starttiden för PHP-processerna
ps -eo pid,lstart,cmd | grep -E 'php-fpm|lsphp|php-cgi' | grep -v grep

Varje PHP-process bör ha en starttid efter uppdateringen. Om så inte är fallet avslutar ni den riktat via den tjänst den hör till. Med flera servrar lönar det sig att föra ett kort protokoll per maskin som ni senare kan använda som underlag.

Sätt tillfälliga värden centralt

Om en version ännu inte är åtgärdad rekommenderar php.net tillfälliga åtgärder som inte ger något fullständigt skydd. På cPanel sätter ni dem i MultiPHP INI Editor i administratörsläget eller direkt i php.ini för respektive ea-php-version. Värden i .user.ini på kundkontona räcker inte för session.upload_progress.enabled.

; serveromfattande php.ini för den berörda versionen (exempel)
session.upload_progress.enabled = 0
post_max_size = 32M
upload_max_filesize = 24M

Utan uppladdningsfunktion anger php.net post_max_size = 8M. På PHP 8.5 tillkommer fatal_error_backtraces=0. Därefter startar ni om alla worker-processer igen. En minnesgräns sätter ni via cgroups, till exempel med CloudLinux gränser, inte via RLIMIT_AS eller RLIMIT_DATA. Fler detaljer finns under Omedelbara åtgärder utan patch.

Ansvarsfördelning mellan serverdrivare och kontoinnehavare

På en cPanel-server med många konton bär WHM-administratören ansvaret för PHP, tjänster och serveromfattande konfiguration. Innehavarna av enskilda konton ansvarar för sina applikationer, plugin och inloggningsuppgifter. Informera kontoinnehavarna om när och hur patchningen gjordes och rekommendera dem att kontrollera sina applikationer med avseende på avvikelser. Hur läget ser ut ur kundens perspektiv beskrivs under Shared hosting.

Spara loggarna från och med den 20 oktober 2026. En patch tar inte bort skadlig programvara som fördes in tidigare.

Som underlag räcker ett enkelt protokoll per server: datum och klockslag för uppdateringen, lista över ea-php- och alt-php-paketen med version före och efter, processlistan med starttider efter omstarten och i förekommande fall paketleverantörens bekräftelse om backports. Förvara protokollet utanför servern. Det fungerar senare som belägg gentemot kunder, försäkringsgivare eller granskare och underlättar nästa akuta uppdatering, eftersom stegen redan är beskrivna. Driver ni flera cPanel-servrar lönar det sig att samla läskommandona från den här sidan i ett litet skript som körs likadant på alla maskiner och samlar in resultaten. Då upptäcker ni avvikelser mellan servrar, till exempel en bortglömd PHP-version, på ett ögonkast.

Hur hjälper PHP SOS konkret?

• Vi inventerar ea-php-, alt-php- och systempaket och kopplar alla konton till sin PHP-version.
• Via vår PHP-patchtjänst uppdaterar vi, startar om alla tjänster och styrker läget med paketlistor och processtider.
• Där det behövs sätter vi tillfälliga värden serveromfattande och så att de inte kan skrivas över.
• Vi kontrollerar kontona med avseende på typiska spår av ett intrång och sätter vid fynd igång borttagning av skadlig kod.
• Därefter minskar vi antalet PHP-versioner och härdar konfigurationen.

Vanliga frågor

Källor

• php.net: säkerhetsmeddelanden
• PHP 8 ChangeLog
• php.net: versioner som stöds
• BSI