cPanel og WHM: sådan sikrer I PHP

Kort sagt: En cPanel PHP-opdatering efter PHP2Shell omfatter tre trin: bring alle ea-php- og eventuelt alt-php-pakker op på en rettet status, genstart PHP-FPM og Apache fuldstændigt, og dokumenter pakkestatus. Kunder på serveren kan ikke selv sætte de vigtigste midlertidige værdier, det må WHM-administratoren gøre.

Udgangspunktet på cPanel-servere

PHP2Shell omfatter sårbarhederne CVE-2026-109618 og CVE-2026-109619 i PHP selv. Begge tillader udførelse af skadelig kode uden login og er vurderet til CVSS v4.0 9,2. Berørt er PHP-FPM, Apache med mod_php, php-cgi, FrankenPHP og LiteSpeed. PHP-projektet udgav den 21.10.2026 versionerne 8.5.12, 8.4.27, 8.3.36 og 8.2.35.

cPanel leverer ikke PHP som én enkelt pakke, men via EasyApache 4 med et pakkesæt pr. version, f.eks. ea-php83 eller ea-php84. Dertil kommer på nogle servere operativsystemets pakker og på CloudLinux alt-php-versionerne. Hver kilde har sin egen status. Et fuldstændigt billede opstår først, når I kontrollerer alle tre.

cPanel PHP-opdatering: kontrollér beholdning og tildeling

Begynd med en optælling. Følgende kommandoer læser kun og ændrer intet. Stier og pakkenavne er eksempler og kan afvige afhængigt af installationen.

# Installerede PHP-versioner ifølge WHM-API
whmapi1 php_get_installed_versions

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

# Pakkestatus (RPM-baserede systemer, eksempel)
rpm -qa | grep -E '^ea-php[0-9]+-php-(cli|fpm|common)' | sort

I MultiPHP Manager ser I, hvilket domæne der bruger hvilken version, og om PHP-FPM er aktiveret. Notér versioner, som er installeret, men ikke tildelt noget domæne. Også de bør opdateres eller fjernes.

Vurdér backports korrekt

Som hos andre udbydere gælder: Det viste versionsnummer er ikke det eneste mål. Leveres en rettelse som backport, kan nummeret forblive uændret. Kontrollér derfor desuden pakkens ændringslog og udbyderens henvisninger.

# Gennemsøg en pakkes ændringslog efter CVE-numre (eksempel)
rpm -q --changelog ea-php84-php-cli | grep -iE 'CVE-2026-1096(18|19)'

Findes der ingen post, betyder det ikke automatisk, at rettelsen mangler. Men det betyder, at I har brug for en skriftlig bekræftelse, før I klassificerer serveren som patchet. Hvordan I læser versioner korrekt, beskriver Kontrollér PHP-version og patch-status.

Opdatering, genstart og kontrol

Opdateringen indspiller I i WHM via systemopdateringen eller via pakkehåndteringen. Bagefter genstarter I alle PHP-processer. Nye filer alene er ikke nok, så længe gamle processer kører i hukommelsen.

# Genstart PHP-FPM-tjenesterne for alle versioner (cPanel-script)
/scripts/restartsrv_apache_php_fpm

# Genstart Apache fuldstændigt
/scripts/restartsrv_httpd

# Kontrollér PHP-processernes starttidspunkt
ps -eo pid,lstart,cmd | grep -E 'php-fpm|lsphp|php-cgi' | grep -v grep

Hver PHP-proces bør have et starttidspunkt efter opdateringen. Er det ikke tilfældet, afslutter I den målrettet via den tilhørende tjeneste. Ved flere servere kan det betale sig at føre en kort protokol pr. maskine, som I senere kan bruge som dokumentation.

Sæt midlertidige værdier centralt

Er en version endnu ikke rettet, anbefaler php.net midlertidige foranstaltninger, som ikke giver fuldstændig beskyttelse. På cPanel sætter I dem i MultiPHP INI Editor i administratortilstand eller direkte i php.ini for den pågældende ea-php-version. Værdier i .user.ini på kundekontoene er ikke nok for session.upload_progress.enabled.

; serverdækkende php.ini for den berørte version (eksempel)
session.upload_progress.enabled = 0
post_max_size = 32M
upload_max_filesize = 24M

Uden upload-funktion angiver php.net post_max_size = 8M. På PHP 8.5 kommer fatal_error_backtraces=0 til. Bagefter genstarter I alle workere igen. En hukommelsesgrænse sætter I via cgroups, f.eks. med CloudLinux' limits, ikke via RLIMIT_AS eller RLIMIT_DATA. Yderligere detaljer står under Akutforanstaltninger uden patch.

Ansvar mellem serverdriftsansvarlig og kontoindehavere

På en cPanel-server med mange konti bærer WHM-administratoren ansvaret for PHP, tjenester og serverdækkende konfiguration. Indehaverne af de enkelte konti er ansvarlige for deres applikationer, plugins og adgangsdata. Informér kontoindehaverne om, hvornår og hvordan der er patchet, og anbefal dem at gennemgå deres applikationer for påfaldende forhold. Hvordan situationen ser ud fra kundens side, beskriver shared hosting.

Gem logs fra og med 20.10.2026. En patch fjerner ikke skadelig software, som er smuttet ind tidligere.

Som dokumentation er en enkel protokol pr. server nok: dato og klokkeslæt for opdateringen, liste over ea-php- og alt-php-pakker med version før og efter, procesliste med starttidspunkter efter genstarten og eventuelt pakkeleverandørens bekræftelse vedrørende backports. Gem protokollen uden for serveren. Den tjener senere som bevis over for kunder, forsikringsselskaber eller kontrollører og gør den næste nødopdatering lettere, fordi trinnene allerede er beskrevet. Driver I flere cPanel-servere, kan det betale sig at samle læsekommandoerne fra denne side i et lille script, der kører ens på alle maskiner og samler resultaterne. Så opdager I afvigelser mellem servere, f.eks. en glemt PHP-version, med et blik.

Hvordan hjælper PHP SOS konkret?

• Vi opgør ea-php-, alt-php- og systempakker og tildeler alle konti deres PHP-version.
• Via vores PHP-patch-service opdaterer vi, genstarter alle tjenester og dokumenterer status med pakkelister og proces-tidspunkter.
• Hvor det er nødvendigt, sætter vi midlertidige værdier serverdækkende og således, at de ikke kan overskrives.
• Vi gennemgår kontiene for typiske spor af et kompromis og indleder ved fund fjernelse af malware.
• Derefter reducerer vi antallet af PHP-versioner og hærder konfigurationen.

Ofte stillede spørgsmål

Kilder

• php.net: Sikkerhedsmeddelelser
• PHP 8 ChangeLog
• php.net: Understøttede versioner
• BSI