Het PHP-project heeft de beveiligingsupdates uitgebracht voor de twee kritieke kwetsbaarheden die unauthenticated remote code execution mogelijk maken. Alle PHP-installaties die webverzoeken afhandelen lopen risico. Het advies is om direct te updaten naar PHP 8.5.12, 8.4.27, 8.3.36 of 8.2.35.
De lekken zitten in de kern van PHP. Ze treffen PHP-FPM, Apache met mod_php, php-cgi, FrankenPHP en LiteSpeed. Volgens het PHP-securityteam is het risico het grootst bij mod_php. Daar bestaat een werkende exploit waarbij een verzoek zonder authenticatie de aanval al start voordat er ook maar één regel applicatiecode draait.
Twee manieren om code uit te voeren
De eerste kwetsbaarheid, CVE-2026-109618, draait om de out-of-memory-afhandeling. Een geheugentekort kan PHP onderbreken terwijl interne requestdata nog maar half is geïnitialiseerd. Bij het opruimen van het verzoek behandelt PHP die ongeldige data vervolgens als geldig.
Bij CVE-2026-109619 gaat het om achtergebleven globale state. Interne gegevens van een verzoek kunnen blijven bestaan nadat het onderliggende geheugen al is vrijgegeven. Een volgend verzoek op dezelfde worker kan die verouderde state gebruiken, nog voordat de normale initialisatie alles reset.
Ook backports voor oude versies
Linux-distributies en LTS-leveranciers kregen de patches vooraf, dus bijgewerkte pakketten zouden daar beschikbaar moeten zijn. PHP 8.1 en ouder krijgen officieel geen updates meer. Toch heeft het securityteam vanwege de ernst minimale source-backports gemaakt voor PHP 7.4, 8.0 en 8.1. Gebruikers van de door vrijwilligers onderhouden repository rpms.remirepo.net krijgen vandaag nog geen updates. Het PHP-project raadt hen aan over te stappen op distributiepakketten of zelf te compileren.
Kan je niet direct updaten? Dan zijn er mitigaties, maar die maken een installatie volgens het PHP-project niet veilig. Voor de OOM-kwetsbaarheid helpt het om memory_limit op -1 te zetten via bijvoorbeeld php_admin_value, en post_max_size te verlagen naar 8M, of 32M als uploads nodig zijn. Een container- of cgroup-limiet kan als grens dienen. RLIMIT_AS of RLIMIT_DATA zijn juist af te raden, omdat die de kwetsbare allocatiefout kunnen veroorzaken.
Voor de tweede kwetsbaarheid adviseert het team session.upload_progress.enabled=0 in php.ini of de FPM-pool, gevolgd door een herstart van alle workers. Op PHP 8.5 geldt hetzelfde voor fatal_error_backtraces=0. Foutmeldingen verbergen met error_reporting of display_errors helpt niet. De volledige technische details staan in de advisories van het PHP-project.
Tip: PHP legt internet plat: Waarom PHP2Shell elk bedrijf raakt