# cPanel en WHM: PHP beveiligen

> cPanel PHP-update na PHP2Shell: ea-php-pakketten controleren, PHP-FPM en Apache herstarten, overbruggingswaarden centraal instellen en de patchstatus aantonen.

Bron: https://phpsos.de/nl/server/cpanel/  
Stand: 25-10-2026  
Aanbieder: PHP SOS, PHP-noodhulp en serverbeveiliging. Directe hulp via WhatsApp: https://wa.me/491736494914?text=Hallo%20PHP%20SOS%2C%20wij%20hebben%20hulp%20nodig%20met%20onze%20PHP-server.%20Bedrijf%3A%20%E2%80%A6%20Website%3A%20%E2%80%A6

**Kort gezegd:** Een cPanel PHP-update na PHP2Shell omvat drie stappen: alle ea-php- en eventueel alt-php-pakketten naar een gecorrigeerde status brengen, PHP-FPM en Apache volledig herstarten en de pakketstatus documenteren. Klanten op de server kunnen de belangrijkste overbruggingswaarden niet zelf instellen, dat moet de WHM-beheerder doen.

## Uitgangssituatie op cPanel-servers

PHP2Shell omvat de kwetsbaarheden CVE-2026-109618 en CVE-2026-109619 in PHP zelf. Beide maken het uitvoeren van schadelijke code zonder inloggen mogelijk en zijn beoordeeld met CVSS v4.0 9.2. Getroffen zijn PHP-FPM, Apache met mod_php, php-cgi, FrankenPHP en LiteSpeed. Het PHP-project heeft op 21-10-2026 de versies 8.5.12, 8.4.27, 8.3.36 en 8.2.35 uitgebracht.

cPanel levert PHP niet als één pakket, maar via EasyApache 4 met per versie een eigen pakketset, zoals `ea-php83` of `ea-php84`. Op sommige servers komen daar de pakketten van het besturingssysteem bij en op CloudLinux de alt-php-versies. Elke bron heeft een eigen status. Een volledig beeld ontstaat pas als u alle drie controleert.

## cPanel PHP-update: inventaris en toewijzing controleren

Begin met een inventarisatie. De volgende opdrachten lezen alleen en wijzigen niets. Paden en pakketnamen zijn voorbeelden en kunnen per installatie afwijken.

```bash
# Geïnstalleerde PHP-versies volgens de WHM-API
whmapi1 php_get_installed_versions

# Versie per ea-php-installatie
for p in /opt/cpanel/ea-php*/root/usr/bin/php; do echo "$p"; "$p" -v | head -1; done

# Pakketstatus (RPM-gebaseerde systemen, voorbeeld)
rpm -qa | grep -E '^ea-php[0-9]+-php-(cli|fpm|common)' | sort
```

In de MultiPHP Manager ziet u welk domein welke versie gebruikt en of PHP-FPM is ingeschakeld. Noteer versies die zijn geïnstalleerd maar aan geen enkel domein zijn toegewezen. Ook die moeten worden bijgewerkt of verwijderd.

## Backports juist beoordelen

Net als bij andere aanbieders geldt: het getoonde versienummer is niet de enige maatstaf. Wordt een correctie als backport geleverd, dan kan het nummer ongewijzigd blijven. Controleer daarom aanvullend het wijzigingslogboek van het pakket en de aanwijzingen van de aanbieder.

```bash
# Wijzigingslogboek van een pakket doorzoeken op CVE-nummers (voorbeeld)
rpm -q --changelog ea-php84-php-cli | grep -iE 'CVE-2026-1096(18|19)'
```

Vindt u geen vermelding, dan betekent dat niet automatisch dat de correctie ontbreekt. Het betekent wel dat u een schriftelijke bevestiging nodig hebt voordat u de server als gepatcht beschouwt. Hoe u versies juist leest, beschrijft [PHP-versie en patchstatus controleren](https://phpsos.de/nl/php2shell/php-version-pruefen/).

## Update, herstart en controle

De update voert u in WHM door via de systeemupdate of via de pakketbeheerder. Daarna herstart u alle PHP-processen. Nieuwe bestanden alleen volstaan niet zolang oude processen in het geheugen draaien.

```bash
# PHP-FPM-diensten van alle versies herstarten (cPanel-script)
/scripts/restartsrv_apache_php_fpm

# Apache volledig herstarten
/scripts/restartsrv_httpd

# Starttijd van de PHP-processen controleren
ps -eo pid,lstart,cmd | grep -E 'php-fpm|lsphp|php-cgi' | grep -v grep
```

Elk PHP-proces hoort een starttijd na de update te hebben. Is dat niet zo, beëindig het proces dan gericht via de bijbehorende dienst. Bij meerdere servers loont een kort protocol per machine dat u later als bewijs kunt gebruiken.

> **Belangrijk:**
> Een CMS-update via cPanel-hulpmiddelen zoals WP Toolkit sluit de PHP-kwetsbaarheid niet. Ze is zinvol, maar vervangt noch de PHP-update noch de herstart.

## Overbruggingswaarden centraal instellen

Is een versie nog niet gecorrigeerd, dan adviseert php.net overbruggingsmaatregelen die geen volledige bescherming bieden. Op cPanel stelt u die in via de MultiPHP INI Editor in de modus voor beheerders of rechtstreeks in de php.ini van de betreffende ea-php-versie. Waarden in `.user.ini` van de klantaccounts volstaan voor `session.upload_progress.enabled` niet.

```ini
; serverbrede php.ini van de getroffen versie (voorbeeld)
session.upload_progress.enabled = 0
post_max_size = 32M
upload_max_filesize = 24M
```

Zonder uploadfunctie noemt php.net `post_max_size = 8M`. Op PHP 8.5 komt `fatal_error_backtraces=0` erbij. Daarna herstart u alle workers opnieuw. Een geheugengrens stelt u in via cgroups, bijvoorbeeld met de limieten van CloudLinux, niet via `RLIMIT_AS` of `RLIMIT_DATA`. Meer details vindt u onder [Directe maatregelen zonder patch](https://phpsos.de/nl/php2shell/sofortmassnahmen-ohne-patch/).

## Verantwoordelijkheid tussen serverbeheerder en accounthouders

Op een cPanel-server met veel accounts draagt de WHM-beheerder de verantwoordelijkheid voor PHP, diensten en serverbrede configuratie. De houders van afzonderlijke accounts zijn verantwoordelijk voor hun toepassingen, plug-ins en toegangsgegevens. Informeer de accounthouders wanneer en hoe er is gepatcht en adviseer hen hun toepassingen op opvallende zaken te controleren. Hoe de situatie er vanuit het perspectief van de klant uitziet, beschrijft [Shared hosting](https://phpsos.de/nl/server/shared-hosting/).

Bewaar de logs vanaf 20-10-2026. Een patch verwijdert geen schadelijke software die eerder is ingebracht.

Voor het bewijs volstaat een eenvoudig protocol per server: datum en tijd van de update, lijst van de ea-php- en alt-php-pakketten met versie vóór en na, de proceslijst met starttijden na de herstart en eventueel de bevestiging van de pakketleverancier over backports. Bewaar het protocol buiten de server. Het dient later als bewijs richting klanten, verzekeraars of controleurs en vergemakkelijkt de volgende noodupdate, omdat de stappen al zijn beschreven. Beheert u meerdere cPanel-servers, dan loont het om de leesopdrachten van deze pagina samen te vatten in een klein script dat op alle machines hetzelfde draait en de resultaten verzamelt. Zo ziet u afwijkingen tussen servers, bijvoorbeeld een vergeten PHP-versie, in één oogopslag.

## Hoe helpt PHP SOS concreet?

- Wij inventariseren ea-php-, alt-php- en systeempakketten en koppelen alle accounts aan hun PHP-versie.
- Via onze [PHP-patchservice](https://phpsos.de/nl/leistungen/php-patch-service/) werken we bij, herstarten we alle diensten en onderbouwen we de status met pakketlijsten en procestijden.
- Waar nodig stellen we overbruggingswaarden serverbreed en niet overschrijfbaar in.
- Wij controleren de accounts op typische sporen van een compromittering en starten bij een bevinding de [verwijdering van malware](https://phpsos.de/nl/leistungen/malware-entfernung/).
- Vervolgens verminderen we het aantal PHP-versies en beveiligen we de configuratie.


## Veelgestelde vragen

**Waar zie ik in WHM welk domein welke PHP-versie gebruikt?**  
In de MultiPHP Manager van WHM ziet u per domein de toegewezen versie en of PHP-FPM actief is. Voor een volledige lijst is een opvraging via de opdrachtregel een goede aanvulling. Noteer ook versies die aan geen enkel domein zijn gekoppeld.

**Mag een cPanel-klant de overbruggingswaarden zelf in .user.ini instellen?**  
Voor session.upload_progress.enabled vermeldt php.net uitdrukkelijk dat .user.ini en ini_set() niet volstaan. De waarde hoort in de php.ini, de FPM-pool of de serverconfiguratie. Dat kan alleen de serverbeheerder.

**Volstaat een graceful restart van Apache?**  
Bij PHP-FPM moeten de FPM-diensten zelf herstarten, een reload van Apache vernieuwt ze niet. Bij op Apache gebaseerde PHP-handlers is een volledige herstart de veilige weg. Controleer daarna de starttijd van alle PHP-processen.

**Hoe zit het met CloudLinux en alt-php?**  
Op CloudLinux-servers draaien websites deels met eigen alt-php-pakketten in plaats van ea-php. Die hebben een eigen pakketstatus en moeten apart worden gecontroleerd en bijgewerkt.

## Bronnen

- [php.net: beveiligingsmeldingen](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)
- [php.net: ondersteunde versies](https://www.php.net/supported-versions.php)
- [BSI](https://www.bsi.bund.de/)
