1 Find hver PHP på serveren

Mange servere kører mere end én PHP: systempakken, versioner installeret af et kontrolpanel (cPanel EA-PHP, Plesk, CWP/CloudLinux alt-php, DirectAdmin), containere og kommandolinje-builds brugt af cron. Hver PHP, der håndterer webforespørgsler, skal opdateres.

Kør php -v, vis php-fpm-processer med ps aux | grep php-fpm, og tjek dit panels PHP-vælger.

2 Opdater til en rettet version

De rettede upstream-versioner er 8.5.12, 8.4.27, 8.3.36 og 8.2.35. Distributionspakker kan indeholde rettelsen under et ældre versionsnummer — tjek changeloggen for CVE-2026-109618 og CVE-2026-109619.

PHP 8.1 og ældre får ingen udgivelse fra PHP-projektet. Minimale kilde-backports er udgivet for 7.4, 8.0 og 8.1 til dem, der bygger fra kildekode, men den holdbare løsning er at skifte til en understøttet gren.

Debian / Ubuntu (distributionspakker)

Installer sikkerhedsopdateringen fra din distribution, og genstart PHP. Versionsnummeret kan forblive det samme; pakkens changelog nævner CVE’en.

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)

Anvend leverandørens errata for din PHP-modulstream, og genstart derefter.

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

Docker / officielle php-images

Hent eller byg igen med det rettede tag, og genskab containerne.

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

Brug panelets opdateringsværktøj til hver installeret PHP-version (EA-PHP, Plesk PHP-handlers, alt-php, CustomBuild), og genstart derefter PHP-FPM. Paneler beholder ofte gamle versioner installeret til enkelte websites — opdater eller fjern også dem.

Delt eller administreret hosting

Du kan som regel ikke selv opdatere PHP. Brug beskeden på resultatkortet til at bede din udbyder om den præcise version, patchdatoen og bekræftelse på, at workers er genstartet.

Windows / IIS

Download det rettede build fra windows.php.net, udskift PHP-mappen, og genbrug (recycle) IIS-applikationspuljerne.

3 Genstart alle PHP-processer

Installation af en pakke ændrer ikke kode, der allerede kører. Genstart PHP-FPM, Apache (for mod_php), LiteSpeed, FrankenPHP, queue workers og supervisors. For containere skal du bygge eller hente det nye image — en genstart af samme image installerer ikke en patch.

4 Verificer

Kør php -v for hver binær fil, og bekræft, at de kørende processer bruger det nye build (for eksempel bør ls -l /proc/$(pgrep -o php-fpm)/exe ikke vise »deleted«). Kør derefter dette tjek igen.

5 Hvis du ikke kan opdatere i dag

Anvend de delvise afhjælpninger nedenfor, og begræns hvem der kan nå websitet, indtil du kan opdatere. De mindsker risikoen; de fjerner den ikke.

6 Tjek for tegn på kompromittering — og skift hemmeligheder

Hvis et sårbart website var tilgængeligt fra internettet, så gennemgå aktiviteten fra 20. oktober 2026 og frem: nedbrud i PHP-workers (SIGSEGV) i fejlloggen for PHP-FPM eller Apache, nye eller ændrede PHP-filer i webroden, nye cronjobs, nye administratorkonti og uventede udgående forbindelser.

Fordi CVE-2026-109619 kan afsløre PHP-processens hukommelse uden at der køres nogen kode, er et rent filsystem ikke bevis for, at intet er lækket. Skift databaseadgangskoder, API-nøgler samt betalings- og mailoplysninger, og ugyldiggør brugersessioner for websites, der var eksponeret.

7 Efter opdateringen

Rettelsen indfører en ny hård hukommelsesgrænse: en proces, der når den, afsluttes øjeblikkeligt, og shutdown-handlers køres ikke. Tjek, hvordan din applikation opfører sig under hukommelsespres, gennemgå memory_limit sammen med post_max_size og max_input_nesting_level, og fjern en midlertidig memory_limit = -1, som du har sat før patchingen. At skjule versionen med expose_php = Off er valgfri hardening, ikke en rettelse.

Delvise afhjælpninger (fra php.net og sikkerhedsmeddelelserne)

Disse indsnævrer kun de kendte angrebsveje. php.net fastslår, at opdatering er det eneste sikre valg.

; php.ini / FPM pool (php_admin_value) — genstart alle workers bagefter
session.upload_progress.enabled = 0
fatal_error_backtraces = 0        ; PHP 8.5
post_max_size = 8M                ; 32M hvis uploads er nødvendige
max_input_nesting_level = 16      ; default 64
display_errors = 0

; FPM pool
pm.max_requests = 200

Angiv disse i php.ini, PHP-FPM-puljen (php_admin_value) eller serverkonfigurationen — ikke med ini_set() eller .user.ini — og genstart dine workers. Yderligere tiltag fra meddelelserne og forskerholdet:

memory_limit = -1 blokerer nogle veje, der afhænger af PHP’s egen hukommelsesgrænse, men overlader hukommelsesudtømning til operativsystemet — brug det kun sammen med en cgroup v2-grænse memory.max. Brug ikke RLIMIT_AS eller RLIMIT_DATA; de kan udløse de samme sårbare veje.
Sænk max_input_nesting_level så meget, som dine formularer tillader.
Sænk pm.max_requests i PHP-FPM, så workers udskiftes oftere (på bekostning af ydeevnen).
Grænser for forespørgselsstørrelse, antal felter og nesting på webserveren eller proxyen; fjern ugyldige eller forældede INI-indstillinger pr. forespørgsel.
SELinux- eller AppArmor-politikker kan begrænse, hvad en kompromitteret worker må køre — de mindsker konsekvenserne, men forhindrer ikke læk af hukommelse.

Referencer

Kilde: sikkerhedsmeddelelse fra php.net, 21. oktober 2026. Senest verificeret 2026-10-23.