PHP2Shell oplossen: PHP bijwerken en workers herstarten

Doelversies

• PHP 8.5.12 of nieuwer in de tak 8.5
• PHP 8.4.27 of nieuwer in de tak 8.4
• PHP 8.3.36 of nieuwer in de tak 8.3
• PHP 8.2.35 of nieuwer in de tak 8.2
• Alles wat ouder is: overstappen naar een van deze versies of een backport van de leverancier bevestigen en die als overgang behandelen. De CISA adviseert ongepatchte PHP van het netwerk te halen als bijwerken niet mogelijk is, uitdrukkelijk ook PHP 8.1 en ouder.

Brontarballs en Windows-builds vindt u op de downloadpagina van PHP. Volgens php.net kregen Linux-distributies en LTS-leveranciers de patches vóór de openbare release, dus het distributiepakket is vaak de juiste weg. Hetzelfde advies zegt dat de vrijwillige Remi-repository (rpms.remirepo.net) de updates op 21 oktober niet had, en raadt gebruikers ervan aan over te stappen op distributiepakketten of zelf te bouwen.

Debian, Ubuntu en andere apt-systemen

Debian heeft fixes gepubliceerd: DLA-4848-1 (Debian LTS) voor Debian 12 bookworm, php8.2 8.2.35-1~deb12u1, en DSA-6574-1 voor Debian 13 trixie, php8.4 8.4.27-1~deb13u1. De security-tracker vermeldt de builds van de basissuite (bookworm php8.2 8.2.32-1~deb12u1, trixie php8.4 8.4.24-1~deb13u1) als kwetsbaar; de fix komt dus alleen aan als de security-suite in uw pakketbronnen staat. Op 22 oktober vermeldde de tracker testing (forky) php8.4 8.4.26-1 nog steeds als kwetsbaar.

Werk de metadata bij en installeer de PHP-pakketten die daadwerkelijk zijn gepubliceerd. De namen volgen de minor-tak (php8.3-fpm, php8.3-cli, php8.3-common en het Apache-modulepakket bij mod_php). Ligt de kandidaatversie nog onder de fix, wacht dan op de distributie: er ontbreekt geen optie.

sudo apt-get update
apt-cache policy php8.3-cli php8.3-fpm php8.3-common
sudo apt-get install --only-upgrade php8.3-cli php8.3-fpm php8.3-common
php8.3 -v
# Web SAPI, not just the CLI:
php-fpm8.3 -v
sudo systemctl restart php8.3-fpm
# If Apache loads mod_php, restart Apache as well:
sudo systemctl restart apache2

RHEL, Alma, Rocky, Fedora: dnf of yum

sudo dnf clean expire-cache
sudo dnf update php php-cli php-fpm php-common
php -v
php-fpm -v
sudo systemctl restart php-fpm
# mod_php under httpd:
sudo systemctl restart httpd

Docker en andere images

Opnieuw bouwen en opnieuw uitrollen. Een nieuwe basisimage ophalen doet niets zolang de workload die verkeer afhandelt niet is vervangen. Officiële image-tags volgen meestal de PHP-versie; controleer op Docker Hub of de tag bestaat voordat u hem vastzet. Het advies van Google Cloud voor Cloud Run en GKE is hetzelfde: de uitgerolde image opnieuw bouwen, behalve bij een serverless basisimage die Google naar eigen zeggen zelf vervangt.

FROM php:8.3.36-fpm
# or: php:8.3.36-apache, php:8.4.27-fpm, php:8.2.35-fpm, php:8.5.12-cli

# then, on the host:
# docker pull php:8.3.36-fpm
# docker build -t your-app:php2shell-fix .
# redeploy and confirm the running container's PHP version

cPanel

1. Werk cPanel zelf bij, zodat EasyApache een gepatchte PHP-build aanbiedt. Menu’s veranderen; leidend is de cPanel-documentatie.
2. Open in WHM EasyApache 4 en stel een PHP-versie beschikbaar op of boven de fix van de tak. In MultiPHP Manager wijst u domeinen een PHP-versie toe.
3. Haal publiek bereikbare domeinen weg van handlers met PHP 8.1 of ouder, tenzij uw leverancier heeft bevestigd dat de build de backport bevat.
4. Herstart Apache en PHP-FPM via WHM, controleer de PHP-versie van een domein en verwijder tijdelijke testpagina’s.

Plesk

1. Installeer updates van Plesk en de systeempakketten. Het actuele klikpad staat in de Plesk-documentatie.
2. Controleer onder Tools & Settings de updates en de lijst met PHP-handlers. De PHP-instellingen van het domein tonen welke versie een abonnement werkelijk gebruikt.
3. Kies een gepatchte handler (8.2.35, 8.3.36, 8.4.27 of 8.5.12, of een geverifieerde leveranciersbuild). Pas hem eerst toe op publieke websites.
4. Herstart de door Plesk gebruikte PHP-dienst en controleer de versie op het domein, niet alleen op de paneelhost.

宝塔面板 (BT Panel)

Volgens het 宝塔-advies van 22 oktober 2026 hebben de Linux- en Windows-panelen 8.2.35, 8.3.36, 8.4.27 en 8.5.12 gesynchroniseerd. De alleen voor Linux aangeboden pakketten 7.4.34, 8.0.31 en 8.1.35 zijn 宝塔-builds, geen releases van het PHP-project. Klikpad en de onvolledige Windows-instelling staan op de BT-Panel-pagina.

mod_php vergeleken met PHP-FPM

Beide staan op de risicolijst van het PHP-project. mod_php geldt als hoogste risico, omdat het gedemonstreerde pad zonder authenticatie vóór de applicatiecode ingrijpt. Een Apache-herstart laadt mod_php opnieuw. PHP-FPM is een eigen proces: herstart elke pool (systemctl restart php8.3-fpm of de overeenkomstige unit) en houd er rekening mee dat pools een eigen binair bestand kunnen vastleggen. De php in het PATH van uw shell kan een andere build zijn dan die van de pool. FrankenPHP, php-cgi en LiteSpeed noemt PHP als webverzoeken afhandelend en dus getroffen; volg hun upgradehandleidingen in plaats van aan te nemen dat een apt-pakket php-fpm ze dekt.

Tijdelijke maatregelen, volgens PHP onvolledig

Gebruik deze alleen als overbrugging, overgenomen uit het php.net-advies. Ze verkleinen bepaalde paden en maken een host niet veilig. Stel ze in via php.ini of via een pool- of Apache-instelling op beheerdersniveau (php_admin_value). ini_set() en per-directory .user.ini komen volgens PHP te laat voor het session-upload-pad.

CVE-2026-109618

• memory_limit=-1, zo vastgezet dat de applicatie geen eindige limiet meer kan instellen. Volgens PHP vervalt daarmee de stuurbare geheugenlimietfout, maar een onderliggende toewijzingsfout kan de fout nog steeds bereiken.
• Een lage post_max_size. PHP raadt 8M aan zonder uploads en 32M met uploads, waarbij upload_max_filesize onder post_max_size blijft.
• Limieten voor de verzoekgrootte op de webserver of proxy, ook voor verzoeken zonder bruikbare Content-Length. PHP noemt gedecodeerde verzoekgrootte, aantal invoervelden, multipart-delen, headers en nestingdiepte.
• Een container- of cgroup-limiet als beschikbaarheidsgrens die de getroffen worker beëindigt. PHP raadt af RLIMIT_AS of RLIMIT_DATA te gebruiken, omdat die de kwetsbare toewijzingsfout kunnen veroorzaken.

CVE-2026-109619

• session.upload_progress.enabled=0, daarna elke worker herstarten. Volgens PHP blokkeert dit de bevestigde sessiepaden, niet andere varianten.
• Alleen bij PHP 8.5: fatal_error_backtraces=0, daarna herstarten. Volgens PHP blokkeert dit alleen het bevestigde fatal-backtrace-pad.
• Ongeldige of verouderde verzoekgebonden instellingen verwijderen die vóór de initialisatie diagnostiek uitvoeren. Fouten uitschakelen met error_reporting, display_errors of @ dicht het lek niet.
• Fatale fouten en time-outs verhelpen die een aanvaller kan bereiken, ook in callbacks en bij het opruimen na uploads of imports. Zo formuleert het project het; het is een hardeningadvies, geen uitspraak dat foutloze applicatiecode FPM veilig maakt.

Web application firewalls

De CISA zegt dat een web application firewall tot de update enige bescherming kan bieden. Cloudflare zegt dat beheerde regels voor dit probleem vanaf 21 oktober 2026, 03:02 UTC, actief waren voor klanten met gratis en betaalde WAF-abonnementen, nog onder embargo ontwikkeld met de PHP Foundation en anderen, en dat klanten toch moesten patchen. Een regel kan worden omzeild; Cloudflare zag zelf hoe aanvallers payloads aanpasten. Houd de WAF, maar gebruik hem niet als fix.

Het AWS-bulletin 2026-143-AWS noemt compenserende maatregelen voor gebruikers van AWS WAF. Voor CVE-2026-109618: de regel SizeRestrictions_BODY in de AWS WAF Core rule set (CRS), als extra bescherming tegen request-bodies groter dan 8 KB (8.192 bytes). Voor CVE-2026-109619: AWS heeft versie 2.3 van de AWS WAF PHP Managed Rule Group gepubliceerd en wereldwijd tot standaardversie gemaakt. Het bulletin publiceert ook een aangepaste regel in JSON die POST-requests blokkeert met PHP_SESSION_UPLOAD_PROGRESS in de body en PHPSESSID in de body of een cookie. Ook AWS zegt dat alleen upgraden een volledige oplossing is, en dat er voor de end-of-life-versies 5.4 tot en met 8.1 geen fix voor CVE-2026-109618 is.

Na de upgrade

• Controleer de versie op de SAPI die HTTP-verzoeken beantwoordt, en herstart die. Expel en de University of Toronto benadrukken beide de herstart.
• Geef voorrang aan publiek bereikbare systemen, dan aan alles wat onbetrouwbare uploads of imports verwerkt, dan aan appliances. Het Britse NCSC en het Canadian Cyber Centre zeggen beide dat producten van derden met ingebedde PHP eigen leveranciersupdates nodig hebben.
• Was een host blootgesteld en kon hij niet snel worden gepatcht, dan adviseert de CISA te zoeken naar PHP-workers die shells starten of tools downloaden. Het Britse NCSC adviseert naar achterdeurtjes te zoeken voordat u een blootgestelde, bijgewerkte host vertrouwt. Een geverifieerde lijst met indicatoren kunnen wij daar niet aan toevoegen. Elastic Security Labs (21 oktober) beschrijft dezelfde gedragsgerichte aanpak uitgebreider: let op webservers of PHP-workers die shells starten, met curl of wget tools downloaden of nieuwe scriptbestanden in de webroot schrijven.
• De in het Britse advies gelinkte NCSC-NL-notities zijn een startinventaris van producten, geen verklaring dat een niet-vermeld product veilig is.

Hardening die je na de update houdt

De volledige PHP-advisory raadt verzoeklimieten aan de rand aan (gedecodeerde grootte, nestdiepte, invoervariabelen, multipart-delen en headers per deel), multipart weigeren op routes zonder uploads, en RLIMIT_AS en RLIMIT_DATA vermijden. Waarom uploadlimieten alleen het geheugen niet begrenzen en hoe mod_php, FPM, FrankenPHP en LiteSpeed verschillen: zie de pagina over CVE-2026-109618.