Kort gezegd: Na PHP2Shell bewijst de getoonde PHP-versie op zichzelf weinig, omdat hosters correcties vaak als backport installeren. Vraag daarom een schriftelijke bevestiging van de PHP-update bij uw hoster op: pakketstand per PHP-tak, tijdstip van installatie en herstart van alle PHP-processen. Een sjabloon om te kopiëren vindt u hieronder.
Waarom een schriftelijke bevestiging nu telt
Op 21-10-2026 publiceerde het PHP-project de patches voor twee kritieke kwetsbaarheden die onder de naam PHP2Shell bekend zijn. Beide maken het mogelijk om op afstand en zonder aanmelding schadelijke code uit te voeren. Het BSI (de Duitse federale dienst voor informatiebeveiliging) heeft waarschuwingsniveau 3 / oranje afgekondigd en adviseert direct te updaten.
Wie zijn website bij een hoster draait, kan de update vaak niet zelf installeren. Tegelijk draagt u als exploitant de verantwoordelijkheid voor de gegevens van uw klanten. Een schriftelijke, concrete bevestiging van de hoster is daarom meer dan een formaliteit. Ze is een bouwsteen van uw documentatie, bijvoorbeeld richting functionarissen voor gegevensbescherming, verzekeraars of de directie.
Daar komt bij: een patch verwijdert geen schadelijke software die eerder is binnengebracht. Volgens mediaberichten was er al op 17-10. een eerste waargenomen aanvalspoging. Het precieze moment waarop uw server beschermd was, is dus belangrijk voor de vraag of u verder moet controleren.
Waarom de getoonde PHP-versie niet volstaat
Verholpen zijn PHP 8.5.12, 8.4.27, 8.3.36 en 8.2.35. Veel distributies en hosters nemen de correctie echter als backport over in hun eigen pakket. Dan toont een interface als Plesk nog steeds 8.2.34, hoewel de server gepatcht is.
Omgekeerd kan een correct versienummer misleiden. Nieuwe bestanden alleen beschermen niet zolang oude PHP-processen in het geheugen draaien. Pas na een herstart van alle workers is de nieuwe stand actief. Meer daarover in het artikel PHP-versie en patchstand goed controleren.
| Uitspraak van de hoster | Wat ze aantoont | Wat nog ontbreekt |
|---|---|---|
| „Alle systemen zijn actueel.” | weinig | Versie of pakketstand, datum, herstart |
| „PHP 8.3.36 is geïnstalleerd.” | Versie | Datum, herstart, getroffen servers |
| „Backport in pakket xy, herstart op …” | Patch en activering | evt. gegevens over PHP 8.1 en ouder |
Welke gegevens u van de hoster nodig hebt
Vraag om antwoorden op deze punten, het liefst per website of contract:
- Welke PHP-takken en versies zijn actief voor uw websites, ook oudere die alleen voor afzonderlijke mappen draaien?
- Zijn de correcties voor CVE-2026-109618 en CVE-2026-109619 aanwezig, als officiële versie of als backport?
- Wanneer is de update geïnstalleerd en wanneer zijn alle PHP-processen (FPM-pools, Apache, LiteSpeed) herstart?
- Is
session.upload_progress.enabledvanwege CVE-2026-115560 uitgeschakeld? - Welke uitvoeringsmodus gebruikt uw abonnement, bijvoorbeeld PHP-FPM of Apache met mod_php? Bij mod_php ziet het PHP-team het hoogste risico.
- Welke toegangs- en foutlogs vanaf 20-10-2026 worden bewaard en hoe krijgt u die?
Draait een website nog op PHP 8.1 of ouder, vraag dan apart na. Voor deze takken zijn er geen officiële updates meer, alleen minimale backports van de broncode voor 7.4, 8.0 en 8.1.
Sjabloon: bevestiging van de PHP-update bij de hoster opvragen
Kopieer de tekst in een supportticket of een e-mail aan uw hoster. Vul de gegevens tussen de vierkante haken aan.
Onderwerp: Verzoek om bevestiging van de PHP-patchstatus (PHP2Shell, CVE-2026-109618 / CVE-2026-109619)
Geachte heer/mevrouw,
wij hebben bij u de volgende websites / contracten:
[Klantnummer, contract, domeinen]
In verband met de PHP-beveiligingslekken CVE-2026-109618 en
CVE-2026-109619 (PHP2Shell, patches van 21.10.2026) en de melding
over CVE-2026-115560 van 23.10.2026 verzoeken wij u om een schriftelijke
bevestiging van de volgende punten:
1. Welke PHP-versies of pakketstanden zijn actief voor onze websites?
2. Bevatten deze de correcties (officiële versie of backport)?
3. Datum en tijdstip van de installatie.
4. Datum en tijdstip van de herstart van alle PHP-processen (FPM, Apache,
LiteSpeed of vergelijkbaar).
5. Is session.upload_progress.enabled aan de serverzijde uitgeschakeld?
6. Welke PHP-bedrijfsmodus wordt gebruikt (bijv. PHP-FPM, mod_php)?
7. Worden toegangs- en foutlogs vanaf 20.10.2026 bewaard, en
hoe kunnen wij ze krijgen?
8. Als een website nog PHP 8.1 of ouder gebruikt: welke beveiliging
is daar aanwezig, en welke overstap raadt u aan?
Wij hebben deze gegevens nodig voor onze interne documentatie.
Hartelijk dank en met vriendelijke groet,
[Naam, bedrijf, functie]
Het antwoord goed beoordelen en zelf natrekken
Een goed antwoord noemt concrete standen, data en tijdstippen. Algemene formuleringen als „wij hebben gereageerd” volstaan niet voor uw dossier. Vraag in dat geval vriendelijk naar de ontbrekende punten.
Staat uw abonnement het toe, controleer dan ook zelf. Met SSH-toegang volstaan meestal deze opdrachten:
# Versie van de opdrachtregel (kan afwijken van de webversie)
php -v
# Pakketstand onder Debian/Ubuntu
dpkg -l | grep -E "php[0-9.]*-(fpm|cli|common)"
# Pakketstand onder RHEL, Alma, Rocky
rpm -qa | grep -i php
# Sinds wanneer draaien de PHP-FPM-processen?
ps -eo pid,lstart,cmd | grep "[p]hp-fpm"
Ligt het starttijdstip van de PHP-processen vóór de bevestigde installatiedatum, dan was de herstart niet volledig.
Als de hoster niet of ontwijkend antwoordt
Blijft een antwoord uit of ontbreken de beslissende gegevens, beschouw de situatie dan niet als opgehelderd. Het BSI adviseert webservers tijdelijk van het netwerk te halen als een update niet direct mogelijk is. Of dat voor uw website proportioneel is, beslist de directie, bij voorkeur schriftelijk en met datum.
Kijk tegelijk naar mogelijke sporen van een aanval, want het patchmoment blijft onbekend. Aanknopingspunten biedt het artikel Ben ik al gecompromitteerd?. Zonder SSH-toegang blijft de schriftelijke bevestiging uw belangrijkste bewijs. Welke plichten bij de hoster liggen en welke bij u, legt de pagina Shared hosting: wat de hoster doet uit; voor beheerde servers helpt Managed server: verantwoordelijkheid afbakenen.
Bewaar verzoek, antwoord en eigen controleresultaten met datum in één map. Dit dossier helpt later bij vragen van verzekeraars of functionarissen voor gegevensbescherming.
Hoe helpt PHP SOS concreet?
- Samen met u formuleren we het verzoek aan de hoster en beoordelen we het antwoord vakinhoudelijk.
- Waar toegang bestaat, controleren we pakketstand, actieve uitvoeringsmodus en herstart van de PHP-processen zelf.
- Blijven er gaten, dan zetten we tussenmaatregelen in of plannen we de overstap naar een ondersteunde versie.
- We leggen resultaat en tijdstippen vast in een bewijsstuk dat u intern kunt doorgeven.
Hoe de update met herstart en bewijs verloopt, beschrijft onze PHP-patchservice.
Veelgestelde vragen
Volstaat het als mijn hoster schrijft dat alles actueel is?
Voor uw documentatie meestal niet. Vraag om concrete gegevens: pakketstand of versie per PHP-tak, installatiedatum en datum van de herstart van alle PHP-processen. Pas daarmee kunt u het tijdvenster van de kwetsbaarheid afbakenen.
Waarom toont mijn hostinginterface nog PHP 8.2.34?
Distributies en hosters installeren beveiligingscorrecties soms als backport, zonder het versienummer te wijzigen. Plesk kan dan nog steeds 8.2.34 tonen, hoewel de server gepatcht is. Duidelijkheid geeft alleen de bevestiging van de aanbieder over de pakketstand.
Wat doe ik als de hoster niet reageert?
Documenteer uw verzoek met datum en vraag na een redelijke termijn opnieuw. Controleer tegelijk of u tussenmaatregelen zelf kunt instellen, en overleg met de directie of de website tot de opheldering offline gaat, zoals het BSI (de Duitse federale dienst voor informatiebeveiliging) voor niet-gepatchte servers adviseert.
Dicht een WordPress- of webshopupdate de kwetsbaarheid ook?
Nee. PHP2Shell zit in PHP zelf. Een update van het CMS of de webshopsoftware verandert niets aan de PHP-interpreter die op de server draait.