PHP2Shell: CVE-2026-109618 og CVE-2026-109619

To fejl i selve PHP, ikke i et framework eller et plugin, der lader en angriber køre kode på serveren uden at logge ind. Kører en server PHP til en hjemmeside, er det denne opdatering, du skal installere i dag.

Af David Kabel · Opdateret 2026-10-21 · 5 min læsning

Hvad de to fejl er

CVE-2026-109618, RCE via hukommelsesmangel. Løber PHP tør for hukommelse på det forkerte tidspunkt, kan request-data blive efterladt halvt initialiseret, og oprydningen behandler det derefter som gyldigt. En angriber, der kan bringe en request i den tilstand, kan ødelægge hukommelsen.

CVE-2026-109619, RCE via forældet global tilstand. Noget af den tilstand, der hører til én request, bliver liggende i en global variabel, efter at requestens hukommelse er frigivet. Næste request på samme worker kan bruge den, før den normale initialisering nulstiller den. Det er en use after free. Advisoriet bekræfter to veje: tidlige INI-diagnosticeringer og session upload progress, som er slået til som standard og ikke kræver, at applikationen kalder session_start().

Ubuntu udsender rettelser til sine pakker helt tilbage til PHP 5, så regn med, at alle versioner, du kører, er ramt. watchTowr, der udgav en FAQ samme dag, melder om udnyttelse i praksis. PHP-projektets egen meddelelse siger det ikke, så betragt det som rapporteret og ikke bekræftet.

Hvor rettelsen findes

Bruger du det frivilligt drevne Remi-repository, skrev PHP-teamet, at det ikke ville have opdateringer på udgivelsesdagen, og anbefalede distributionspakker eller at bygge fra kilden.

Tjek hvad du kører

# Hvilken PHP kører webserveren faktisk? CLI kan være en anden end FPM.
php -v
php-fpm8.4 -v                       # Debian/Ubuntu, ret versionen til
dpkg -l 'php*-common' | awk '/^ii/ {print $2, $3}'
rpm -q php-common                   # RHEL-familien

# Er den risikable standard stadig slået til? (afbødning for CVE-2026-109619)
php -i | grep session.upload_progress.enabled

Tjek FPM-programmet eller pakkeversionen, ikke kun php -v. På servere med flere PHP-versioner installeret side om side er CLI ofte ikke den, der leverer siden.

Opdatér og genstart

# Debian / Ubuntu
sudo apt update && sudo apt install --only-upgrade 'php8.*'
sudo systemctl restart php8.4-fpm   # hver FPM-version du kører
sudo systemctl reload apache2       # hvis du bruger mod_php

# RHEL-familien
sudo dnf upgrade 'php*'
sudo systemctl restart php-fpm httpd

En pakkeopgradering alene er ikke nok. Gamle FPM-workers holder den sårbare kode i hukommelsen, indtil de genstarter. I containere henter du det nye base-image og bygger igen. En kørende container ændrer sig ikke, fordi tagget på Docker Hub er flyttet.

Hvis du ikke kan opdatere i dag

PHP's sikkerhedsteam har udgivet nødløsninger, der lukker de bekræftede angrebsveje. Teamet skriver tydeligt, at de mindsker eksponeringen og ikke gør en server sikker:

; Kun nødløsninger fra PHP's sikkerhedsteam. Ikke en rettelse.
; Skal stå i php.ini eller FPM-poolen (php_admin_value), ikke ini_set() eller .user.ini
session.upload_progress.enabled = 0
post_max_size = 8M        ; 32M hvis siden tager imod uploads
; Kun PHP 8.5:
fatal_error_backtraces = 0

Genstart alle workers efter ændringen. Teamet foreslår også at begrænse request-størrelse, antal felter og multipart-dele i webserveren eller proxyen og at bruge en hukommelsesgrænse i containeren eller cgroup frem for RLIMIT_AS eller RLIMIT_DATA, som kan udløse netop den allokeringsfejl, der rammer sårbarheden. memory_limit=-1 fjerner PHP's egen hukommelsesgrænse for CVE-2026-109618, men en underliggende allokeringsfejl kan stadig nå fejlen.

Faldgruber

• CLI er ikke webserveren. php -v kan vise en rettet version, mens en ældre FPM-pool fra en anden pakke stadig betjener requests. Tjek hver FPM-tjeneste.
• ini_set() og .user.ini virker ikke som afbødning. Advisoriet skriver, at indstillingen for session upload progress skal være på plads, før requesten bliver læst, så brug php.ini eller pool-konfigurationen.
• At skjule fejl hjælper ikke. Advisoriet skriver, at display_errors, error_reporting og @-operatoren ikke blokerer vejen via diagnosticeringer. Fjern de ugyldige eller forældede indstillinger pr. request, der udløser dem.
• PHP 8.2 udløber i december. PHP-projektet skriver, at 8.2 ikke får sikkerhedsrettelser efter 31. december 2026. Patcher du 8.2 i dag, så planlæg skiftet til 8.4 eller 8.5 nu.

Sådan blev det kontrolleret. Den 21. oktober 2026 læste vi PHP's sikkerhedsmeddelelse og de to advisories på GitHub, Debians sikkerhedstracker for begge CVE'er og Ubuntus CVE-side. Vi bekræftede opdateringstidspunkterne for Docker Hub-taggene php:8.5 og php:8.4 via Docker Hubs API. Ikke testet: selve sårbarhederne. Vi har ikke forsøgt at genskabe nogen af fejlene.

Kilder

1. PHP News Archive 2026, PHP-projektet, sikkerhedsmeddelelse og udgivelsesnoter, 21. oktober 2026
2. GHSA-w8hw-w9fx-j79w: RCE via OOM corruption, php/php-src
3. GHSA-6wmf-4rv5-p3rp: RCE via stale global state, php/php-src
4. CVE-2026-109618 og CVE-2026-109619, Debians sikkerhedstracker
5. CVE-2026-109618, Ubuntu security
6. PHP Remote Code Execution FAQ, watchTowr