Op 21 oktober 2026 bracht PHP noodupdates uit voor twee kritieke kwetsbaarheden: CVE-2026-109618 en CVE-2026-109619. De kwetsbaarheden, meestal aangeduid als PHP2Shell, kunnen leiden tot uitvoering van externe code zonder authenticatie in de PHP-runtime. PHP beoordeelt beide met een CVSS v4.0-score van 9.2.
QDE heeft de cPanel-servers voor Shared Hosting, het facturatiesysteem en het klantenportaal gepatcht. Klanten met Shared Hosting hoeven de PHP-runtime niet zelf bij te werken. Draait PHP op een VPS of dedicated server van QDE, dan beheer je zelf het besturingssysteem. Je moet in dat geval de juiste update van de leverancier installeren en alle PHP-workers opnieuw starten.
De status van de pakketten en beveiligingsadviezen in deze handleiding is gecontroleerd op 27 oktober 2026.
Welke installaties worden geraakt door PHP2Shell?
De kwetsbaarheden zitten in PHP zelf. Een update van WordPress, Laravel, Symfony of een andere applicatie repareert de onderliggende runtime niet.
CVE-2026-109618 heeft betrekking op de afhandeling van een out-of-memory-situatie. PHP kan de initialisatie van een request afbreken terwijl interne gegevens nog maar gedeeltelijk zijn ingesteld. Tijdens het opruimen worden die ongeldige gegevens vervolgens als bruikbaar behandeld. Het PHP-team heeft uitvoering van code via HTTP aangetoond bij Apache mod_php. Daar kan het kwetsbare pad al worden uitgevoerd voordat de applicatiecode start. PHP-FPM geldt eveneens als kwetsbaar, maar de bevestigde aanvalspaden en hun betrouwbaarheid verschillen doordat een FPM-childproces na bepaalde opstartfouten wordt beëindigd.
CVE-2026-109619 draait om statusgegevens van een request die achterblijven nadat het bijbehorende geheugen is vrijgegeven. Een later request dat door dezelfde worker wordt verwerkt, kan die achtergebleven status gebruiken. Het PHP-advies beschrijft bevestigde aanvalspaden voor code-uitvoering bij zowel mod_php als PHP-FPM.
Bij een geslaagde aanval wordt code uitgevoerd met de rechten van de PHP-worker. Ook zonder root-toegang kan dat account doorgaans applicatiebestanden en geheimen lezen, verbinding maken met databases en webcontent wijzigen. Daarom moet de update met spoed worden geïnstalleerd.
Exploitcode circuleerde al vóór de gecoördineerde bekendmaking. AWS herleidde een aanvalspoging tot 17 oktober en vond meerdere proofs of concept voordat het embargo op 21 oktober afliep. Zowel AWS als Cloudflare heeft aanvalsverkeer waargenomen. Hoe betrouwbaar openbare exploitcode is, hangt af van de PHP-build, extensies, geheugenallocator, webserver en het gedrag van de applicatie. Installeer de patch uit het advies van je leverancier, ook als een openbare proof of concept op jouw build niet goed werkt. Controleer systemen die vóór de update bereikbaar waren bovendien op sporen van misbruik.
Gecorrigeerde upstreamversies van PHP
Dit zijn de eerste upstreamreleases met de volledige oplossingen:
| PHP-versietak | Eerste versie met fix |
|---|---|
| PHP 8.5 | 8.5.12 |
| PHP 8.4 | 8.4.27 |
| PHP 8.3 | 8.3.36 |
| PHP 8.2 | 8.2.35 |
De ondersteuning voor PHP 8.2 eindigt op 31 december 2026. Plan ook na de installatie van 8.2.35 een overstap naar een ondersteunde versietak.
PHP 8.1 en ouder ontvangen geen reguliere releases meer van het PHP-project. PHP heeft minimale backports van de broncode voor 7.4, 8.0 en 8.1 gepubliceerd. Verschillende leveranciers van besturingssystemen en controlepanelen hebben daarnaast eigen pakketten met backports uitgebracht. Een gepatchte build kan daardoor nog steeds een oud upstreamversienummer tonen. Controleer de volledige pakketrevisie en het advies van de leverancier in plaats van alleen op php -v te vertrouwen.
Een apart advies van 23 oktober
Twee dagen na de PHP2Shell-releases maakte PHP CVE-2026-115560 bekend. Dit is een afzonderlijk probleem met de voortgangsregistratie van sessie-uploads. De hierboven genoemde releases van 21 oktober lossen het niet op. Misbruik vereist een ongebruikelijke combinatie: uploadvoortgang is ingeschakeld, session.serialize_handler begint als php_binary of php_serialize en de applicatiecode wijzigt de waarde in php voordat session_start() wordt aangeroepen.
PHP wil CVE-2026-115560 in de volgende reguliere bugfixrelease oplossen. Totdat die release is geïnstalleerd, adviseert PHP om session.upload_progress.enabled=0 in te stellen. Pas dit toe in de opstartconfiguratie en start alle workers opnieuw. Applicaties die de serialisatiehandler nooit tijdens runtime wijzigen, zijn niet kwetsbaar voor dit afzonderlijke probleem.
Wat QDE heeft gepatcht
QDE heeft de oplossingen voor CVE-2026-109618 en CVE-2026-109619 geïnstalleerd op de systemen die wij beheren:
- de cPanel Shared Hosting-servers en de daarop aangeboden PHP-versies;
- het facturatiesysteem van QDE;
- het klantenportaal van QDE.
Staat je website op QDE Shared Hosting, dan hoef je als klant niets te doen voor deze twee PHP2Shell-oplossingen. Houd je CMS, plug-ins, thema's en applicatieafhankelijkheden wel actueel; die staan los van PHP2Shell.
De VPS- en dedicated-serverdiensten van QDE zijn unmanaged. Wij beheren de fysieke infrastructuur, het netwerk en de virtualisatielaag. De pakketten binnen je server beheer je zelf. Volg hieronder de instructies voor jouw systeem en open een supportticket als je niet zeker weet welke pakketbron de server gebruikt.
Voordat je de update installeert
Controleer eerst hoe PHP is geïnstalleerd voordat je repository's of releasestreams wijzigt:
php -v
command -v php
# Debian or Ubuntu
apt-cache policy php php8.2-cli php8.3-cli php8.4-cli php8.5-cli
# RHEL, AlmaLinux, Rocky Linux, or CentOS Stream
dnf module list php
rpm -qf "$(command -v php)"Maak een actuele back-up of snapshot, zeker als je van PHP-versietak wisselt. Bijwerken binnen dezelfde versietak van de distributie veroorzaakt doorgaans de minste problemen. Een overstap van PHP 8.2 naar 8.4 of 8.5 kan incompatibiliteit met applicaties en extensies blootleggen. Combineer de beveiligingsupdate daarom alleen met zo'n overstap wanneer je huidige pakketbron geen gepatcht pakket aanbiedt.
Debian 12 of Debian 13 patchen
Debian heeft voor beide ondersteunde releases gecorrigeerde pakketten gepubliceerd. DLA-4848-1 repareert de php8.2-pakketten van Debian 12 in 8.2.35-1~deb12u1. DSA-6574-1 doet hetzelfde voor de php8.4-pakketten van Debian 13 in 8.4.27-1~deb13u1.
Gebruik je de pakketten van Debian, controleer dan of de beveiligingsrepository is ingeschakeld. Bekijk vervolgens de voorgestelde wijzigingen en voer de update uit:
sudo apt update
apt list --upgradable
sudo apt upgradeDebian heeft voor elke release de meegeleverde PHP-versietak behouden. Je hoeft voor deze oplossing dus geen externe repository toe te voegen.
Gebruikt de server al de PHP-repository van Ondřej Surý, dan installeren dezelfde updatecommando's de gepatchte build voor de gekozen versietak. Voeg deze repository niet toe aan een goed werkende Debian-installatie om alleen het nummer uit php -v te verhogen.
Debian 11 patchen
De LTS-ondersteuning voor Debian 11 eindigde op 31 augustus 2026. Debian brengt geen PHP2Shell-update uit voor de eigen PHP 7.4-pakketten. Een upgrade van het besturingssysteem is de houdbare oplossing.
Heb je tijdens de voorbereiding van die upgrade tijdelijk meer tijd nodig, dan is een ondersteunde commerciële dienst voor verlengde levenscyclusondersteuning de veiligste optie. De openbare repository van Ondřej Surý publiceerde bij onze controle nog Bullseye-pakketten. De PHP 7.4-build 1:7.4.33-31+0~20261021.121+debian11~1.gbpe9c428 bevat de PHP2Shell-backport. Je stapt daarmee op een externe pakketbron over terwijl het besturingssysteem zelf niet meer wordt ondersteund. Test de wijziging en plan de Debian-upgrade; dit pakket maakt van Bullseye geen ondersteund platform.
De officiële repository's van Bullseye bevatten geen oplossing voor PHP2Shell. Het einde van de LTS-periode is op zichzelf geen reden om hun adres te wijzigen. Wil je de openbare Sury-build tijdelijk gebruiken, voeg de repository dan toe volgens de gepubliceerde installatiemethode:
sudo apt update
sudo apt install lsb-release ca-certificates curl
sudo curl -sSLo /tmp/debsuryorg-archive-keyring.deb https://packages.sury.org/debsuryorg-archive-keyring.deb
sudo dpkg -i /tmp/debsuryorg-archive-keyring.deb
sudo sh -c 'echo "deb [signed-by=/usr/share/keyrings/debsuryorg-archive-keyring.gpg] https://packages.sury.org/php/ bullseye main" > /etc/apt/sources.list.d/php.list'
sudo apt update
apt list --upgradable
sudo apt upgradeLees het pakketvoorstel voordat je het accepteert. Als het niet-versiegebonden metapakket php is geïnstalleerd, kan het naast de versie die je applicatie nu gebruikt ook een nieuwere PHP-versietak selecteren.
Ubuntu patchen
USN-8948-1 van Ubuntu bevat gecorrigeerde pakketten voor Ubuntu 22.04 LTS, 24.04 LTS, 26.04 LTS en 26.10. Gebruik je de PHP-pakketten van Ubuntu, voer dan het volgende uit:
sudo apt update
apt list --upgradable
sudo apt upgradeUbuntu past de oplossingen via backports toe. Het upstreamgedeelte van het versienummer kan daardoor lager blijven dan 8.2.35, 8.3.36 of 8.5.12. Vergelijk de volledige geïnstalleerde pakketversie met USN-8948-1.
Werk je al met de PPA van Ondřej Surý, installeer de update dan op dezelfde manier vanuit die bron. De PPA ondersteunt actuele Ubuntu LTS-releases, maar geen releases die naar Expanded Security Maintenance zijn overgegaan.
Canonical heeft een aparte Ubuntu Pro/ESM-update voor Ubuntu 20.04 uitgebracht. Daaronder valt PHP 7.4-pakket 7.4.3-4ubuntu2.29+esm5. Systemen met Ubuntu 20.04 waarop de relevante Ubuntu Pro-dienst actief is, kunnen die update van Canonical installeren. Zonder die dienst is een upgrade van het besturingssysteem verstandiger dan het toevoegen van een niet-ondersteunde PPA.
RHEL, AlmaLinux, Rocky Linux of CentOS Stream patchen
Red Hat, AlmaLinux en Rocky Linux verwerken de PHP-oplossingen als backport in hun eigen pakketrevisies. Het PHP2Shell-beveiligingsbulletin van Red Hat, de errata van AlmaLinux en de errata van Rocky Linux houden de betreffende streams bij.
Voor de standaardpakketten van de distributie:
sudo dnf upgrade --refreshControleer op de CVE-pagina van de leverancier jouw exacte hoofdversie en modulestream. De afhandeling door Red Hat stond tijdens onze controle nog op 'ongoing': voor sommige streams waren updates beschikbaar, voor andere werd er nog aan gewerkt. Red Hat publiceert bovendien afzonderlijke errata voor standaardondersteuning, Extended Update Support en andere levenscyclusstreams. Een gecorrigeerde versie in het ene kanaal zegt daarom niets over de beschikbaarheid in een ander kanaal.
Gebruikt je server al de repository van Remi, dan installeert dnf upgrade --refresh het gecorrigeerde pakket voor de ingeschakelde stream. Moet je van stream wisselen, gebruik dan de configuratiewizard van Remi en test eerst de applicatie. dnf module switch-to wijzigt zowel de geïnstalleerde pakketten als de actieve stream. Dat is een migratie en geen normale beveiligingsupdate.
Een zelfbeheerde cPanel-server patchen
cPanel heeft gecorrigeerde EasyApache 4-pakketten uitgebracht voor PHP 7.4 tot en met 8.5. Ook de interne PHP-pakketten van cPanel en Roundcube zijn bijgewerkt. Het PHP2Shell-advies van cPanel vermeldt de exacte pakketrevisies.
Ververs de pakketmetadata en laat cPanel de beheerde pakketten bijwerken:
# RHEL-family cPanel servers
sudo yum clean all
sudo yum makecache
# Ubuntu cPanel servers
sudo apt clean
sudo apt update
# Both platforms
sudo /scripts/update-packagesOp een cPanel-server met RPM kun je als volgt controleren of een specifiek EasyApache PHP-pakket de oplossing bevat:
rpm -q --changelog ea-php81-php-cli | grep -m1 CVE-2026-109618Vervang php81 door elke geïnstalleerde PHP-versietak. Alleen de interne PHP-versie van cPanel bijwerken is niet voldoende wanneer EasyApache PHP nog websites bedient vanuit een ouder pakket.
PHP in containers patchen
Een update van de host vervangt PHP in een container niet. Haal een basisimage met een gecorrigeerde upstreamrelease of gedocumenteerde backport op, of bouw het image daarmee opnieuw. Maak daarna de actieve containers opnieuw aan:
docker compose pull
docker compose build --pull --no-cache
docker compose up -d --force-recreateVoer alleen de commando's uit die bij je uitrol passen. Een stack die een gepubliceerd image gebruikt, heeft meestal pull nodig. Een stack met een eigen Dockerfile vereist build --pull. Voor Kubernetes en andere orchestratieplatforms moet je een nieuwe image-digest instellen en daarna een rollout uitvoeren. Controleer het pakket in de vervangende container, niet op de host.
PHP opnieuw starten na de update
Actieve PHP-workers hebben het oude uitvoerbare bestand nog in het geheugen geladen. Start na de pakketupdate PHP-FPM opnieuw, Apache wanneer dat mod_php laadt, of de betreffende container of pod. Alleen de configuratie herladen is bij dit incident onvoldoende.
# Debian and Ubuntu: use the branch you actually run
sudo systemctl restart php8.2-fpm
sudo systemctl restart php8.3-fpm
sudo systemctl restart php8.4-fpm
sudo systemctl restart php8.5-fpm
# Apache with mod_php on Debian or Ubuntu
sudo systemctl restart apache2
# RHEL family
sudo systemctl restart php-fpm
sudo systemctl restart httpdStart alleen diensten opnieuw die op je server zijn geïnstalleerd. Bedienen verschillende FPM-versietakken verschillende websites, start dan elke actieve versietak opnieuw.
Het pakket en iedere PHP-runtime voor webverkeer controleren
php -v toont het CLI-binaire bestand dat je shell vindt. Een aparte FPM-versietak, een EasyApache-build van cPanel of PHP in een container kan daardoor buiten beeld blijven. Controleer alle geïnstalleerde pakketten:
# Debian and Ubuntu
dpkg-query -W -f='${binary:Package}\t${Version}\n' 'php*' 2>/dev/null | sort
# RHEL family
rpm -qa 'php*' | sort
# Active FPM services on systemd distributions
systemctl list-units --type=service --state=running 'php*-fpm.service'Vergelijk de uitkomst met het advies van je distributie of controlepaneel. Controleer bij een upstreambuild op 8.5.12, 8.4.27, 8.3.36 of 8.2.35 of hoger. Bij een backport zijn de pakketrevisie en changelog van de leverancier bepalend.
Controleer ook waar elke website de PHP-requests naartoe stuurt. Het gebeurt regelmatig dat het standaard CLI-binaire bestand is gepatcht, terwijl een oudere FPM-pool, container of controlepaneelpakket nog steeds verkeer verwerkt.
Systemen controleren die vóór de patch bereikbaar waren
De update voorkomt toekomstig misbruik van deze kwetsbaarheden, maar maakt een eerdere inbraak niet ongedaan. AWS heeft een aanvalspoging tot 17 oktober teruggevoerd. Controleer daarom vanaf ten minste die datum de webserver- en PHP-logs wanneer de dienst vóór de patch via internet bereikbaar was.
Let op ongebruikelijke multipart-requests, onverwachte childprocessen die door een PHP-worker zijn gestart, nieuwe of gewijzigde bestanden in webroots en tijdelijke mappen, onbekende geplande taken en wijzigingen aan accounts of SSH-sleutels. Aanvallers pasten hun payloads na de bekendmaking snel aan. Dat één openbare proof of concept niets oplevert, bewijst daarom niet dat het systeem schoon is.
Vind je geloofwaardige aanwijzingen voor een inbraak, isoleer de server dan en bewaar het bewijsmateriaal dat je nodig hebt. Bouw het systeem opnieuw op vanaf een betrouwbaar image of een betrouwbare back-up. Vervang ook de inloggegevens en applicatiegeheimen die de PHP-worker kon lezen, waaronder databasewachtwoorden en API-sleutels.
Als je niet direct kunt patchen
Haal de PHP-dienst zo mogelijk tijdelijk van het openbare internet. Volgens PHP is een update de enige volledige oplossing voor de oorspronkelijke twee CVE's.
Het upstreamadvies noemt enkele gedeeltelijke maatregelen. Het uitschakelen van session.upload_progress blokkeert bevestigde sessiegerelateerde aanvalspaden voor CVE-2026-109619 en beschermt tegen CVE-2026-115560. Beheerders van PHP 8.5 kunnen fatal_error_backtraces uitschakelen om één bevestigde trigger te blokkeren. Bij CVE-2026-109618 voorkomt een door de beheerder afgedwongen memory_limit=-1 de voorspelbare geheugenlimietfout die de bevestigde exploit gebruikt. Andere allocatiefouten blijven mogelijk en één request kan al het beschikbare geheugen verbruiken. Gebruik deze instelling daarom uitsluitend met een zorgvuldig ingestelde cgroup- of containerlimiet en conservatieve limieten voor de requestgrootte.
Deze instellingen kunnen uploadvoortgang, foutopsporing, grote uploads of geheugenbeperkingen verstoren. Leg ze vast in php.ini, een FPM-pool of een serverconfiguratie die al vóór het verwerken van het request actief is. Start daarna de workers opnieuw. Een WAF-regel of losse configuratiewijziging is geen vervanging voor de patch.
De update afronden
Installeer het gecorrigeerde pakket vanuit de pakketbron die je server al vertrouwt. Start alle PHP-workers opnieuw en controleer voor iedere PHP-runtime die webverkeer verwerkt de volledige pakketrevisie.
Voor klanten van QDE Shared Hosting is de PHP-runtime al bijgewerkt. Klanten met een VPS of dedicated server van QDE moeten hun eigen besturingssysteem, containers en controlepanelen bijwerken. Weet je niet zeker welke pakketbron of dienstenopzet je server gebruikt, open dan een ticket voordat je repository's wijzigt.
Veelgestelde vragen over PHP2Shell
Lost een update van WordPress of een andere PHP-applicatie PHP2Shell op?
Nee. De kwetsbare code zit in de PHP-runtime. Werk het PHP-pakket van het besturingssysteem, de container of het controlepaneel bij, ook als de applicatie zelf actueel is.
Is PHP-FPM kwetsbaar?
Ja. PHP noemt PHP-FPM als een van de kwetsbare serverinterfaces. Het advies over achtergebleven statusgegevens beschrijft bovendien een bevestigd RCE-pad in de sessielevenscyclus van FPM. Door bepaald opstartgedrag is het aangetoonde out-of-memory-pad bij FPM moeilijker te misbruiken dan bij mod_php. Een ongepatchte FPM-installatie is daarmee nog steeds niet veilig.
Is php -v voldoende om de oplossing te controleren?
Alleen bij een eenvoudige upstreaminstallatie waarbij de CLI en webserver hetzelfde binaire bestand gebruiken. Backports van distributies kunnen een ouder upstreamnummer behouden. Daarnaast kan één server meerdere FPM-versietakken of containerimages draaien. Controleer de pakketrevisies en iedere runtime die webrequests verwerkt.
Moeten klanten met een QDE VPS zelf updaten?
Ja, als op de VPS PHP draait. QDE VPS-hosting is unmanaged, dus klanten beheren het gastbesturingssysteem en de updates daarvan zelf. Patches aan de infrastructuur van QDE vervangen geen pakketten binnen de virtuele machine van een klant.
Moeten klanten met QDE Shared Hosting PHP bijwerken?
Nee. QDE heeft de PHP-runtimes op de Shared Hosting-servers al gepatcht. Klanten blijven zelf verantwoordelijk voor updates van hun websites, plug-ins, thema's en applicatieafhankelijkheden.