CVE-2026-109618: RCE via out-of-memory-tilstand

Kort sagt: CVE-2026-109618 er en af de to sårbarheder bag PHP2Shell. En out-of-memory-tilstand kan afbryde PHP, mens forespørgselsdata kun er delvist initialiseret; ved oprydningen kan ugyldige data så gælde som gyldige. Det muliggør kodeudførelse uden login. Fejlen er rettet i PHP 8.5.12, 8.4.27, 8.3.36 og 8.2.35.

Hvad er CVE-2026-109618?

CVE-2026-109618 (GitHub-betegnelse GHSA-w8hw-w9fx-j79w) er en hukommelsesfejl-sårbarhed i PHP's kerne. Den er vurderet til CVSS v4.0 9,2. Sammen med CVE-2026-109619 udgør den det, der i medierne betegnes som PHP2Shell.

Virkningen er en såkaldt unauthenticated Remote Code Execution: En angriber kan på afstand og uden brugerkonto køre kode på webserveren. Dermed hører sårbarheden til den farligste klasse af svagheder, en webserver kan have.

Hvordan sårbarheden grundlæggende opstår

Når PHP behandler en webforespørgsel, opretter det internt datastrukturer til denne forespørgsel, f.eks. til indsendte formulardata. Rammer PHP herved sin hukommelsesgrænse, afbrydes det med en out-of-memory-tilstand. Ifølge php.net kan det ske, mens forespørgselsdata kun er delvist initialiseret.

I slutningen af hver forespørgsel rydder PHP op og frigiver hukommelsen. Netop dér ligger fejlen: Oprydningen kan behandle ugyldige, kun halvt oprettede data som gyldige. Ud af denne fejlagtige opførsel kan der under visse betingelser udledes kodeudførelse.

Hvorfor er sådan en fejl så alvorlig? En hukommelsesfejl i programmeringssproget berører alle applikationer, der kører på det, uafhængigt af hvor omhyggeligt de er programmeret. En velplejet WordPress-installation med aktuelle plugins er lige så berørt som en gammel egenudvikling. Derfor hjælper en opdatering af applikationen ikke her, kun en opdatering af PHP.

Yderligere tekniske enkeltheder om udnyttelsen offentliggør vi bevidst ikke. Til forsvaret er de ikke nødvendige: Afgørende er, om jeres server bruger en rettet version, og om de nye processer faktisk kører.

Berørte versioner og driftsformer

Berørt er driftsformerne PHP-FPM, Apache med mod_php, php-cgi, FrankenPHP og LiteSpeed. PHP-teamet vurderer risikoen som højest ved mod_php. Distributioner og hostingudbydere indspiller nogle gange backports, så et ældre versionsnummer vises, selv om fejlen er rettet. Afgørende er pakkestatus og udbyderens bekræftelse.

Til størrelsesordenen: Palo Alto Networks (Unit 42) talte mere end 22,6 millioner eksponerede, potentielt sårbare instanser. BSI (det tyske forbundsagentur for informationssikkerhed) har udsendt advarselsniveau 3 (orange) og regnede med hurtig udnyttelse i stor skala.

Udbedre CVE-2026-109618: opdatering og genstart

Den eneste fuldstændige afhjælpning er opdateringen. Kontrollér først version og pakkestatus. Pakkenavne afviger fra distribution til distribution; eksemplerne tager udgangspunkt i PHP 8.3:

php -v
apt policy php8.3-fpm          # Debian/Ubuntu
dnf info php-fpm               # RHEL, AlmaLinux, Rocky, Fedora
rpm -q --changelog php-fpm | grep -i "CVE-2026-109618"

Nævner pakkens changelog CVE-nummeret, er backporten indspillet. Mangler det, betyder det ikke automatisk, at pakken er sårbar; så hjælper sammenholdningen med versionstabellen eller en forespørgsel hos udbyderen.

Efter opdateringen skal alle PHP-processer genstartes, f.eks. med systemctl restart php8.3-fpm eller ved mod_php med en genstart af Apache. Hvordan I sikrer, at ingen gammel worker kører længere, står under Genstart PHP-FPM og alle workers.

Midlertidige foranstaltninger, hvis opdateringen endnu ikke er mulig

php.net har offentliggjort midlertidige foranstaltninger til PHP2Shell. De gælder for begge sårbarheder samlet og er udtrykkeligt ingen fuld beskyttelse. At flere af dem knytter sig til hukommelsesgrænser, passer til out-of-memory-udløseren i CVE-2026-109618; en officiel tilordning af enkelte foranstaltninger til enkelte CVE'er findes dog ikke.

; Eksempel FPM-pool, f.eks. /etc/php/8.3/fpm/pool.d/www.conf (sti afhænger af distributionen)
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M          ; 32M, hvis der er brug for uploads
php_admin_value[upload_max_filesize] = 6M    ; immer unter post_max_size
php_admin_flag[session.upload_progress.enabled] = off

Værdierne skal sættes, så applikationer ikke kan overskrive dem, derfor php_admin_value. Med memory_limit=-1 har tjenesten brug for en hukommelsesgrænse udefra, via container eller cgroup, ikke via RLIMIT_AS eller RLIMIT_DATA. På PHP 8.5 kommer fatal_error_backtraces=0 til. Alle detaljer står under Akutforanstaltninger, hvis I endnu ikke kan rette.

Hvordan hjælper PHP SOS konkret?

Via vores PHP-patch-service lukker vi CVE-2026-109618 struktureret:

• Registrere aktuel status: PHP-gren, driftsform, pakkekilde og backportstatus pr. server.
• Indspille opdateringen fra den passende pakkekilde eller, hvor det ikke kan lade sig gøre, sætte de midlertidige foranstaltninger rent i pool- eller serverkonfigurationen.
• Kontrollere genstarten: Vi kontrollerer, at ingen gamle PHP-processer kører længere.
• Dokumentation: I får en dokumentation med versioner og pakkestatus før og efter indgrebet, f.eks. til direktion, forsikringsselskab eller databeskyttelse.

Ofte stillede spørgsmål

Kilder

• php.net: Sikkerhedsmeddelelser
• PHP 8 ChangeLog
• BSI: det tyske forbundsagentur for informationssikkerhed