PHP2Shell oplossen · patchgids

PHP2Shell oplossen

De oplossing is een PHP-update plus een herstart. Geen configuratiewijziging, plugin-update of WAF-regel vervangt dat. Commando’s voor elk gangbaar platform, en hoe je bewijst dat de patch echt is toegepast.

Laatst gecontroleerd 2026-10-22

Doelversies

8.5.12, 8.4.27, 8.3.36, 8.2.35 of nieuwer — of een pakket van je OS-leverancier waarvan de changelog CVE-2026-109618 en CVE-2026-109619 vermeldt. PHP 8.1 en ouder krijgen geen nieuwe release — zie hieronder.

BranchKwetsbaarOpgelost in
8.5< 8.5.128.5.12
8.4< 8.4.278.4.27
8.3< 8.3.368.3.36
8.2< 8.2.358.2.35
8.1 · 8.0 · 7.4alleAlleen source-backport
5.4 – 7.3alleGeen fix

1. Vind elke PHP-runtime

Vergeten runtimes zijn de meest voorkomende reden dat een serverpark blootgesteld blijft. Draai dit op elke host.

shell
# PHP processes running right now, and when they started
ps -eo pid,lstart,cmd | grep -E '[p]hp-fpm|[h]ttpd|[a]pache2|[f]rankenphp|[l]sphp'

# CLI and FPM can be different builds — check both
php -v
ls /usr/sbin/php-fpm* 2>/dev/null && for f in /usr/sbin/php-fpm*; do "$f" -v | head -1; done

# Is Apache running PHP in-process (mod_php)? That is the highest-risk setup.
apachectl -M 2>/dev/null | grep -i php

# PHP version inside every running container
docker ps --format '{{.Names}}' | while read c; do
  printf '%s: ' "$c"; docker exec "$c" php -r 'echo PHP_VERSION, PHP_EOL;' 2>/dev/null || echo 'no php'
done

Controleer ook base images in je registry, CI-runners, staging- en preview-omgevingen, appliances met ingebouwde PHP en oude servers waar niemand meer eigenaar van is. Van buitenaf onthult curl -sI https://site | grep -i x-powered-by soms de versie, maar de meeste sites verbergen die. Gebruik de NCSC-NL-productinventaris om ingebouwde PHP te vinden; bevestig de status bij de leverancier.

2. Installeer de gepatchte release

Geldt voor OS-pakketten en de PPA / packages.sury.org van Ondřej Surý. Standaardpakketten van Debian/Ubuntu houden hun oude upstream-nummer en backporten de fix, dus de controle van de changelog is wat telt.

shell
sudo apt update

# Upgrade only the PHP packages that are installed
sudo apt install --only-upgrade $(dpkg-query -W -f='${db:Status-Abbrev} ${binary:Package}\n' 'php*' | awk '$1=="ii"{print $2}')

# Proof the fix is in: the changelog should mention the CVE
# (replace 8.3 with your version)
apt changelog php8.3-common 2>/dev/null | grep -m1 -E 'CVE-2026-10961[89]' || echo 'NOT FIXED in this package yet'

3. Herstart alles wat PHP draait

Een pakket installeren vervangt bestanden op schijf. Draaiende processen blijven de oude, kwetsbare code uitvoeren tot ze herstarten.

shell
# Debian / Ubuntu (adjust the version)
sudo systemctl restart php8.3-fpm
sudo systemctl restart apache2        # if using mod_php

# RHEL family
sudo systemctl restart php-fpm httpd

# Anything still mapped to the old, deleted PHP binary needs a restart
sudo grep -l -E '(php|libphp)[^ ]* \(deleted\)' /proc/[0-9]*/maps 2>/dev/null
sudo needrestart -r l                 # Debian/Ubuntu helper, if installed

# Long-running PHP workers
php artisan queue:restart             # Laravel queues
php artisan octane:reload             # Octane (Swoole / RoadRunner / FrankenPHP)
sudo supervisorctl restart all        # supervisor-managed workers

4. Verifieer vanuit het oogpunt van de webserver

shell
# Version of the FPM binary that actually serves traffic
php-fpm8.3 -v 2>/dev/null || php-fpm -v

# Compare process start times with when you upgraded
ps -o pid,lstart,cmd -C php-fpm8.3,php-fpm,apache2,httpd

# Ask the web server itself (use a random name, delete straight after)
F="v-$(openssl rand -hex 8).php"
echo '<?php echo PHP_VERSION;' | sudo tee /var/www/html/$F >/dev/null
curl -s https://your-site.example/$F; echo
sudo rm /var/www/html/$F

Nieuw gedrag na de patch

De fix vervangt het afbreken bij OOM door een zachte limiet die op een veilig punt wordt gecontroleerd, plus een tweede, hogere harde geheugenlimiet die het proces direct beëindigt met _exit(). Wordt de harde limiet geraakt, dan draaien shutdown-functies en destructors niet. Doet je app werk in register_shutdown_function (logging, opruimen), test dan na de upgrade de geheugenintensieve paden.

Op PHP 8.1, 8.0, 7.4 of ouder?

Deze branches zijn end-of-life. Het PHP-project brengt er geen releases meer voor uit, maar heeft vanwege de ernst minimale source-backports gepubliceerd.

  1. Het beste: migreer naar PHP 8.4 of 8.5. Moet het snel, dan is 8.3 een kleinere stap vanaf 8.1 (8.2 verliest eind 2026 de ondersteuning).
  2. OS-pakket: Ubuntu (incl. Ubuntu Pro / ESM), Debian LTS, RHEL en andere LTS-leveranciers kregen de patches vooraf. Zoek de CVE in de changelog van je pakket, zoals hierboven.
  3. Zelf bouwen vanuit source: de backport-branches van het PHP-team — PHP 8.1, PHP 8.0, PHP 7.4. Ze lossen alleen deze twee CVE’s op; de branch blijft niet ondersteund.
  4. Oudere branches: het PHP-project vermeldt geen broncodebackport onder dit bereik. Distributieleveranciers kunnen wel fixes leveren: Ubuntu bevestigt gepatchte pakketten, ook voor oudere branches via Pro / ESM. Bevestig dekking van beide CVE’s en herstart workers; is er geen gepatchte build, isoleer dan de host en migreer.

5. Daarna

  • Verwijder tijdelijke mitigaties die de prestaties schaden, zoals pm.max_requests = 1 of memory_limit = -1, en ga terug naar normale limieten.
  • Zoek naar sporen van eerder misbruik: detectiegids. Patchen maakt een compromittering niet ongedaan.
  • Op PHP 8.2? De security-ondersteuning stopt op 2026-12-31. Plan de overstap naar 8.4 of 8.5 nu, nu het upgradepad nog vers is.

Gerelateerd