# CVE-2026-109619: RCE via forældet global tilstand

> CVE-2026-109619 forklaret forståeligt: hvorfor intern tilstand mellem forespørgsler bliver farlig, hvilke PHP-versioner der er rettet, og hvordan I sikrer jer.

Kilde: https://phpsos.de/da/php2shell/cve-2026-109619/  
Status: 25.10.2026  
Udbyder: PHP SOS, PHP-nødhjælp og serversikkerhed. Akut hjælp på WhatsApp: https://wa.me/491736494914?text=Hej%20PHP%20SOS%2C%20vi%20har%20brug%20for%20hj%C3%A6lp%20med%20vores%20PHP-server.%20Firma%3A%20%E2%80%A6%20Website%3A%20%E2%80%A6

**Kort sagt:** CVE-2026-109619 er den anden sårbarhed bag PHP2Shell. Intern tilstand, der hører til en forespørgsel, kan bestå efter frigivelsen af hukommelsen; en senere forespørgsel i samme worker kan bruge den, før den nulstilles. Følgen er kodeudførelse uden login. Afhjælpning: opdatering til PHP 8.5.12, 8.4.27, 8.3.36 eller 8.2.35 og genstart af alle workers.

## Hvad er CVE-2026-109619?

CVE-2026-109619 (GitHub-betegnelse GHSA-6wmf-4rv5-p3rp) er vurderet til CVSS v4.0 9,2. Sammen med [CVE-2026-109618](https://phpsos.de/da/php2shell/cve-2026-109618/) udgør den PHP2Shell. Begge sårbarheder sidder i selve PHP og ikke i en applikation.

Virkningen er den samme som ved søstersårbarheden: En angriber kan på afstand, uden adgangskode og uden brugerkonto, køre kode på serveren. Årsagen er dog en anden.

## Hvorfor forældet tilstand i workeren er farlig

En PHP-webserver starter ikke en ny proces til hver forespørgsel. Ved PHP-FPM, Apache med mod_php, LiteSpeed eller FrankenPHP behandler en worker mange forespørgsler efter hinanden. Mellem to forespørgsler nulstiller PHP sin interne tilstand, så intet fra forespørgsel A når ind i forespørgsel B.

Ved CVE-2026-109619 lykkes denne nulstilling ikke fuldstændigt. Ifølge php.net kan intern tilstand, der hører til forespørgslen, bestå efter frigivelsen af hukommelsen. En senere forespørgsel i samme worker kan bruge denne forældede tilstand, før den nulstilles. Forenklet sagt: Noget bliver genbrugt, som egentlig allerede ikke længere er gyldigt.

Set fra driftens side er det bemærkelsesværdigt. Genbrugen af workers er tilsigtet, fordi den gør webservere hurtige: En worker behøver ikke at genstarte til hver forespørgsel, indlæse udvidelser og oprette hukommelse. Sårbarheden rammer altså en egenskab, som stort set enhver produktiv PHP-installation har. php.net nævner ingen konfiguration, der fuldstændigt undgår problemet; derfor går vejen via opdateringen.

Enkeltheder om udnyttelsen offentliggør vi ikke. For driftsansvarlige tæller: Enhver driftsform, hvor workers betjener flere forespørgsler, skal holdes under opsyn, og netop disse driftsformer er de sædvanlige.

## De to PHP2Shell-sårbarheder sammenlignet

| Kendetegn | CVE-2026-109618 | CVE-2026-109619 |
|---|---|---|
| GitHub-betegnelse | GHSA-w8hw-w9fx-j79w | GHSA-6wmf-4rv5-p3rp |
| Vurdering | CVSS v4.0 9,2 | CVSS v4.0 9,2 |
| Udløser | Out-of-memory under initialiseringen af forespørgselsdata | Intern tilstand består efter frigivelse |
| Virkning | Kodeudførelse uden login | Kodeudførelse uden login |
| Rettet i | 8.5.12, 8.4.27, 8.3.36, 8.2.35 | 8.5.12, 8.4.27, 8.3.36, 8.2.35 |

Berørt er PHP-FPM, Apache med mod_php, php-cgi, FrankenPHP og LiteSpeed. Den højeste risiko ser PHP-teamet ved mod_php; hvorfor, forklarer vi under [Hvorfor mod_php bærer den højeste risiko](https://phpsos.de/da/php2shell/mod-php-risiko/).

## Luk CVE-2026-109619: opdatering, derefter genstart af alle workers

Netop ved denne sårbarhed er genstarten afgørende. Så længe gamle workers kører i hukommelsen, arbejder serveren videre med den fejlbehæftede kode, selv om de nye filer for længst ligger på disken.

Kontrollér version og pakkestatus. Pakkenavne afviger fra distribution til distribution og fra hostingudbyderens grænseflade:

```bash
php -v
php-fpm8.3 -v                  # FPM-binæren kan have en anden version end CLI
apt policy php8.3-fpm          # Debian/Ubuntu
dnf info php-fpm               # RHEL-familien
rpm -q --changelog php-fpm | grep -i "CVE-2026-109619"
```

Genstart derefter alle berørte tjenester:

```bash
sudo systemctl restart php8.3-fpm     # pr. installeret PHP-version
sudo systemctl restart apache2        # ved mod_php; under RHEL hedder tjenesten httpd
```

Hvis jeres distribution eller hostingudbyder indspiller en backport, forbliver det viste versionsnummer måske det samme. Så tæller pakkens changelog og udbyderens skriftlige bekræftelse. En trin-for-trin-kontrol finder I under [Genstart PHP-FPM og alle workers](https://phpsos.de/da/php2shell/php-fpm-neustart/).

> **Tip:**
> Notér dato og klokkeslæt for genstarten. Til den senere vurdering af, om et angreb fandt sted før eller efter rettelsen, er dette tidspunkt det vigtigste holdepunkt.

## Hvad der stadig er at gøre efter rettelsen

En rettelse beviser ikke, at der ikke skete noget før. Ifølge mediernes rapporter blev et første angrebsforsøg observeret den 17. oktober, fire dage før rettelserne. Gem serverlogs fra og med 20. oktober, som fagpressen anbefaler, og kontrollér serveren for uregelmæssigheder. Henvisninger hertil giver siden [Er jeg allerede kompromitteret?](https://phpsos.de/da/php2shell/bin-ich-gehackt-anzeichen/).

Tænk herved på rækkevidden: Ved en vellykket kodeudførelse har angriberen PHP-processens rettigheder. Vedkommende kan læse, hvad applikationen må læse, f.eks. konfigurationsfiler med databaseadgange eller API-nøgler. Bekræftes en hændelse, hører det med at fornye disse adgangsdata efter oprydningen.

## Hvordan hjælper PHP SOS konkret?

Med [PHP-patch-servicen](https://phpsos.de/da/leistungen/php-patch-service/) gennemfører vi rettelsen på en måde, der kan følges:

- **Registrere:** Hvilke PHP-versioner og driftsformer kører på hvilken server, og hvilken pakkekilde leverer dem?
- **Rette:** Opdatering fra den rigtige kilde eller midlertidige foranstaltninger efter php.net, hvor opdateringen endnu er blokeret.
- **Kontrollere genstarten:** Vi kontrollerer proces for proces, at kun den rettede version kører.
- **Dokumentere:** Versioner, pakkestatus og genstartstidspunkter, så I kan dokumentere status.


## Ofte stillede spørgsmål

**Hvad adskiller CVE-2026-109619 fra CVE-2026-109618?**  
CVE-2026-109618 opstår, når en out-of-memory-tilstand afbryder forespørgslen midt i initialiseringen. CVE-2026-109619 vedrører tilstand, der bliver tilbage i workeren efter afslutningen af en forespørgsel. Begge fører til kodeudførelse uden login og er rettet i de samme PHP-versioner.

**Hjælper det at genstarte PHP-FPM-workers oftere?**  
Som erstatning for opdateringen er det ikke egnet. php.net nævner ikke hyppigere worker-genstarter som midlertidig foranstaltning. Genstarte skal I dog workers efter opdateringen, så den rettede version overhovedet kører.

**Er jeg beskyttet mod CVE-2026-109619 med en CMS-opdatering?**  
Nej. Sårbarheden ligger i PHP og ikke i WordPress, Shopware, TYPO3 eller et andet system. Kun en PHP-opdatering eller en bekræftet backport fra udbyderen lukker den.

**Findes der kendte spor af et angreb via CVE-2026-109619?**  
Bekræftede Indicators of Compromise er hidtil ikke offentliggjort. Opdagelse bygger på adfærdsanalyse, f.eks. nye PHP-filer, usædvanlige udgående forbindelser eller ukendte cronjobs.

## Kilder

- [php.net: Sikkerhedsmeddelelser](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)
- [BSI: det tyske forbundsagentur for informationssikkerhed](https://www.bsi.bund.de/)