1 Vind elke PHP op de server

Veel servers draaien meer dan één PHP: het systeempakket, versies die door een controlepaneel zijn geïnstalleerd (cPanel EA-PHP, Plesk, CWP/CloudLinux alt-php, DirectAdmin), containers en command-line builds die door cron worden gebruikt. Elke PHP die webverzoeken afhandelt, moet worden bijgewerkt.

Voer php -v uit, toon de php-fpm-processen met ps aux | grep php-fpm en controleer de PHP-selector van uw paneel.

2 Bijwerken naar een gepatchte versie

De gepatchte upstream versies zijn 8.5.12, 8.4.27, 8.3.36 en 8.2.35. Distributiepakketten kunnen de oplossing onder een ouder versienummer bevatten — controleer de changelog op CVE-2026-109618 en CVE-2026-109619.

PHP 8.1 en ouder krijgen geen release van het PHP-project. Voor wie zelf compileert, zijn minimale source-backports gepubliceerd voor 7.4, 8.0 en 8.1, maar de duurzame oplossing is de overstap naar een ondersteunde branch.

Debian / Ubuntu (distributiepakketten)

Installeer de beveiligingsupdate van uw distributie en herstart PHP. Het versienummer kan gelijk blijven; de changelog van het pakket vermeldt de CVE.

sudo apt update && sudo apt install --only-upgrade 'php*'
sudo systemctl restart 'php*-fpm' apache2 2>/dev/null
apt changelog php8.3-fpm | grep -i -m3 CVE-2026-1096

RHEL / AlmaLinux / Rocky (dnf)

Pas de errata van de leverancier toe voor uw PHP-modulestream en herstart daarna.

sudo dnf upgrade --refresh 'php*'
sudo systemctl restart php-fpm httpd
rpm -q --changelog php-common | grep -i -m3 CVE-2026-1096

Docker / officiële php-images

Haal de gepatchte tag op of bouw opnieuw, en maak de containers opnieuw aan.

docker pull php:8.3-fpm   # must report 8.3.36 or later
docker compose up -d --build --force-recreate
docker compose exec app php -v

cPanel, Plesk, CWP, DirectAdmin

Gebruik de updatefunctie van het paneel voor elke geïnstalleerde PHP-versie (EA-PHP, Plesk PHP-handlers, alt-php, CustomBuild) en herstart daarna PHP-FPM. Panelen houden vaak oude versies geïnstalleerd voor afzonderlijke sites — werk die ook bij of verwijder ze.

Shared of managed hosting

Meestal kunt u PHP niet zelf bijwerken. Gebruik het bericht op de resultaatkaart om uw provider te vragen naar de exacte versie, de patchdatum en de bevestiging dat de workers zijn herstart.

Windows / IIS

Download de gepatchte build van windows.php.net, vervang de PHP-map en recycle de IIS-applicatiepools.

3 Herstart elk PHP-proces

Het installeren van een pakket verandert geen code die al draait. Herstart PHP-FPM, Apache (voor mod_php), LiteSpeed, FrankenPHP, queue workers en supervisors. Voor containers bouwt u het nieuwe image of haalt u het op — dezelfde image herstarten installeert geen patch.

4 Controleren

Voer php -v uit voor elke binary en ga na of de draaiende processen de nieuwe build gebruiken (bijvoorbeeld ls -l /proc/$(pgrep -o php-fpm)/exe mag geen “deleted” tonen). Voer daarna deze checker opnieuw uit.

5 Als u vandaag niet kunt bijwerken

Pas de gedeeltelijke mitigaties hieronder toe en beperk wie de site kan bereiken totdat u kunt bijwerken. Ze verkleinen het risico; ze nemen het niet weg.

6 Zoek naar tekenen van compromittering — en vervang geheimen

Als een kwetsbare site vanaf internet bereikbaar was, controleer dan de activiteit vanaf 20 oktober 2026: crashes van PHP-workers (SIGSEGV) in de foutlog van PHP-FPM of Apache, nieuwe of gewijzigde PHP-bestanden in de webroot, nieuwe cronjobs, nieuwe beheerdersaccounts en onverwachte uitgaande verbindingen.

Omdat CVE-2026-109619 het geheugen van het PHP-proces kan blootleggen zonder dat er code wordt uitgevoerd, is een schoon bestandssysteem geen bewijs dat er niets is uitgelekt. Wijzig databasewachtwoorden, API-sleutels en betaal- en mailgegevens, en maak gebruikerssessies ongeldig voor sites die blootgesteld waren.

7 Na het bijwerken

De oplossing introduceert een nieuwe harde geheugenlimiet: een proces dat die bereikt, wordt onmiddellijk beëindigd en shutdown-handlers worden niet uitgevoerd. Controleer hoe uw applicatie zich gedraagt bij geheugendruk, bekijk memory_limit samen met post_max_size en max_input_nesting_level, en draai een tijdelijke memory_limit = -1 die u vóór het patchen hebt ingesteld terug. De versie verbergen met expose_php = Off is optionele hardening, geen oplossing.

Gedeeltelijke mitigaties (van php.net en de adviezen)

Deze beperken alleen de bekende aanvalspaden. php.net stelt dat bijwerken de enige veilige keuze is.

; php.ini / FPM pool (php_admin_value) — herstart daarna alle workers
session.upload_progress.enabled = 0
fatal_error_backtraces = 0        ; PHP 8.5
post_max_size = 8M                ; 32M als uploads nodig zijn
max_input_nesting_level = 16      ; default 64
display_errors = 0

; FPM pool
pm.max_requests = 200

Stel deze in via php.ini, de PHP-FPM-pool (php_admin_value) of de serverconfiguratie — niet met ini_set() of .user.ini — en herstart de workers. Aanvullende maatregelen uit de adviezen en van het onderzoeksteam:

memory_limit = -1 blokkeert sommige paden die op de eigen geheugenlimiet van PHP steunen, maar laat geheugenuitputting over aan het besturingssysteem — gebruik het alleen samen met een cgroup v2-limiet memory.max. Gebruik geen RLIMIT_AS of RLIMIT_DATA; die kunnen dezelfde kwetsbare paden activeren.
Verlaag max_input_nesting_level zo ver als uw formulieren toelaten.
Verlaag pm.max_requests van PHP-FPM zodat workers vaker worden vervangen (ten koste van prestaties).
Limieten voor verzoekgrootte, aantal velden en nesting op de webserver of proxy; verwijder ongeldige of verouderde INI-instellingen per verzoek.
SELinux- of AppArmor-beleid kan beperken wat een gecompromitteerde worker mag uitvoeren — dat verkleint de impact, maar voorkomt het uitlekken van geheugen niet.

Bronnen

Bron: beveiligingsadvies van php.net, 21 oktober 2026. Laatst gecontroleerd 2026-10-23.