Actuele situatie: PHP2Shell. Twee kritieke PHP-kwetsbaarheden (CVSS 9.2) maken schadelijke code zonder inloggen mogelijk. Patches sinds 21-10-2026.Wat u nu moet doen →

Plesk-server: PHP-versies controleren en patchen

Op Plesk-servers draaien vaak meerdere PHP-versies naast elkaar. Zo controleert u elke handler, voert u de PHP-update door en herstart u alle workers.

Stand 5 min. leestijdServer & hosting

Kort gezegd: Een Plesk PHP-update is pas afgerond als elke geïnstalleerde PHP-versie een gecorrigeerde status heeft, alle PHP-FPM-diensten zijn herstart en u dat kunt aantonen met pakketstatus en starttijd van de processen. Het in het paneel getoonde versienummer volstaat daarvoor niet, omdat backports het vaak ongewijzigd laten.

Waar het bij PHP2Shell op Plesk-servers om gaat

PHP2Shell staat voor twee kritieke kwetsbaarheden in PHP zelf (CVE-2026-109618 en CVE-2026-109619, elk CVSS v4.0 9.2). Ze stellen aanvallers in staat om zonder inloggen code op de server uit te voeren. Getroffen zijn onder meer PHP-FPM en Apache met mod_php, precies de uitvoeringsmodi die Plesk voor websites inricht.

Op 21-10-2026 heeft het PHP-project de gecorrigeerde versies 8.5.12, 8.4.27, 8.3.36 en 8.2.35 uitgebracht. Voor PHP 8.1 en ouder zijn er geen officiële updates meer. Plesk-servers hebben een bijzonderheid: hier draaien vaak meerdere PHP-versies naast elkaar, deels van Plesk zelf, deels van het besturingssysteem. Elk daarvan heeft een eigen controle nodig.

Belangrijk

Een update in het paneel vervangt bestanden op de schijf. Zolang oude PHP-processen in het geheugen draaien, blijft de kwetsbaarheid open. Zonder herstart van alle workers is de patch niet effectief.

Plesk PHP-update: eerst de inventaris opmaken

Voordat u iets bijwerkt, maakt u een lijst van alle PHP-handlers en de domeinen die ze gebruiken. Dat lukt via het paneel (Hulpmiddelen en instellingen, PHP-instellingen) of via de opdrachtregel. De volgende opdrachten wijzigen niets, ze lezen alleen.

# Alle geregistreerde PHP-handlers met versie en pad
plesk bin php_handler --list

# Versie van elke door Plesk geïnstalleerde PHP-versie (pad als voorbeeld)
for p in /opt/plesk/php/*/bin/php; do echo "$p"; "$p" -v | head -1; done

Noteer voor elke handler: versie, uitvoeringsmodus (FPM, FastCGI, Apache-module) en het aantal domeinen. Handlers zonder domein zijn geen geruststelling. Ze kunnen later worden toegewezen of op testsubdomeinen draaien.

Pakketstatus controleren in plaats van de weergave

Plesk toont het versienummer dat PHP zelf meldt. Levert Plesk of de distributie de correctie als backport, dan kan daar nog steeds bijvoorbeeld 8.2.34 staan, terwijl de correctie erin zit. Omgekeerd kan een actueel ogend nummer misleiden als een pakket nog niet is bijgewerkt. Beslissend zijn de geïnstalleerde pakketstatus en de schriftelijke bevestiging van de aanbieder.

# Debian/Ubuntu (pakketnamen als voorbeeld)
dpkg -l | grep -E 'plesk-php|php[0-9.]+-(fpm|cli)'

# AlmaLinux/Rocky/RHEL (pakketnamen als voorbeeld)
rpm -qa | grep -E 'plesk-php|^php' | sort

Vergelijk de pakketversies met de gegevens in de Plesk-wijzigingslogboeken en de aanwijzingen van uw distributie. Als daar niet ondubbelzinnig is gedocumenteerd dat CVE-2026-109618 en CVE-2026-109619 zijn verholpen, vraag het dan na bij de aanbieder. Een sjabloon daarvoor vindt u onder Hostingprovider naar de patchstatus vragen.

Update doorvoeren en alle workers herstarten

De eigenlijke update loopt via het Plesk-installatieprogramma of de pakketbeheerder van het systeem. Daarna volgt de stap die het vaakst ontbreekt: de herstart. Elke PHP-versie heeft onder Plesk een eigen FPM-dienst. Herstart ze allemaal, niet alleen die van het hoofddomein.

# Alle PHP-FPM-diensten weergeven (namen van diensten als voorbeeld)
systemctl list-units --type=service | grep -i 'php.*fpm'

# Per dienst herstarten, bijv.:
systemctl restart plesk-php84-fpm

# Starttijd van de lopende PHP-processen controleren
ps -eo pid,lstart,cmd | grep -E 'php-fpm|php-cgi' | grep -v grep

Draait een domein met Apache en mod_php, herstart Apache dan volledig. Ligt de starttijd van een PHP-proces vóór de update, dan is het nog niet vernieuwd. Meer over deze stap leest u onder PHP-FPM en alle workers herstarten.

Overbruggende bescherming als de update nog ontbreekt

Is er voor een versie nog geen patch beschikbaar, dan adviseert php.net overbruggingsmaatregelen. Ze vormen geen volledige bescherming. Onder Plesk stelt u waarden die toepassingen niet mogen overschrijven in als php_admin_value in de aanvullende FPM-richtlijnen van het domein of serverbreed in de php.ini van de betreffende versie.

; Voorbeeld voor aanvullende PHP-FPM-richtlijnen in Plesk
php_admin_value[session.upload_progress.enabled] = 0
php_admin_value[post_max_size] = 8M
php_admin_value[upload_max_filesize] = 6M

Bij uploads is volgens php.net post_max_size = 32M bedoeld, met upload_max_filesize daaronder. Op PHP 8.5 komt fatal_error_backtraces=0 erbij. De geheugenbeperking via memory_limit=-1 hoort alleen te worden gebruikt in combinatie met een grens op container- of cgroup-niveau. Daarna volgt opnieuw een herstart van alle workers. Details vindt u onder Directe maatregelen zonder patch. Het BSI (de Duitse federale dienst voor informatiebeveiliging) adviseert webservers tijdelijk van het net te halen als de update niet meteen mogelijk is.

Na de patch: logs veiligstellen en sporen controleren

Een patch sluit de kwetsbaarheid voor de toekomst. Hij verwijdert geen schadelijke software die eerder is ingebracht en bewijst niet dat er niets is gebeurd. Bewaar daarom de logs van de webserver vanaf 20-10-2026. Plesk bewaart ze per domein in de map logs; kort de bewaartermijn in deze situatie niet in.

Let op nieuwe of gewijzigde PHP-bestanden in uploadmappen, onbekende geplande taken en nieuwe beheerdersaccounts. Gepubliceerde, bevestigde Indicators of Compromise zijn er tot nu toe niet; de detectie berust op gedragsanalyse. Als u opvallende dingen vindt, werk dan niet op eigen houtje verder, maar leg eerst de toestand vast.

Hoe helpt PHP SOS concreet?

  • Wij inventariseren alle PHP-handlers van uw Plesk-server, koppelen domeinen eraan en controleren de werkelijke pakketstatus per versie.
  • In het kader van onze PHP-patchservice voeren we updates door, herstarten we alle diensten en documenteren we de starttijden van processen als bewijs.
  • Waar een patch ontbreekt, stellen we de overbruggingsmaatregelen volgens php.net serverbreed en niet overschrijfbaar in.
  • Wij leggen logs vast en zoeken naar sporen van een compromittering, bij een bevinding met Incident Response.
  • Daarna beveiligen we de server duurzaam en verwijderen we PHP-versies die niet nodig zijn.

Veelgestelde vragen

Waarom toont Plesk na de update nog steeds PHP 8.2.34?

Distributies en aanbieders voeren beveiligingscorrecties soms door als backport, zonder het versienummer te wijzigen. Beslissend zijn dan de pakketstatus en de bevestiging van de aanbieder. De weergave alleen bewijst niet dat er gepatcht is, en ook niet het tegendeel.

Volstaat het om in het Plesk-paneel op Bijwerken te klikken?

De update plaatst nieuwe bestanden, maar de lopende PHP-processen werken in het geheugen verder met de oude code. Pas na een herstart van alle PHP-FPM-diensten en van de webserver is de nieuwe status actief. Controleer daarna de starttijd van de processen.

Moet ik ook PHP-versies patchen die geen enkel domein gebruikt?

Ja, zolang ze geïnstalleerd blijven. Een ongebruikte handler kan later per ongeluk worden toegewezen of bereikbaar zijn via testomgevingen. Versies die u niet nodig hebt, verwijdert u beter volledig.

Helpt een WordPress-update in de Plesk-toolkit tegen PHP2Shell?

Nee. PHP2Shell treft PHP zelf, niet het CMS. Een CMS-update blijft zinvol, maar sluit deze kwetsbaarheid niet.

Bronnen

Direct contact

Elk uur telt. Schrijf ons nu.

Beschrijf kort het systeem, de PHP-versie en wat u opmerkt. Wij nemen contact op, brengen de situatie in kaart en werken op afstand tot het incident is afgerond en gedocumenteerd.

Directe hulp