# PHP2Shell: Hvad er dokumenteret, og hvad er ikke

> PHP2Shell fakta tjekket: hvilke udsagn php.net, BSI og producenter dokumenterer, hvad der kun er rapporteret, og hvilke rygter I roligt kan ignorere.

Kilde: https://phpsos.de/da/blog/php2shell-was-belegt-ist/  
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:** Til de dokumenterede PHP2Shell-fakta hører de to CVE-numre, vurderingen til CVSS v4.0 9,2, de rettede PHP-versioner og php.net's midlertidige foranstaltninger. Ligeledes dokumenteret er BSI's advarselsniveau orange. Ikke dokumenteret er en vurdering til CVSS 10, bekræftede vellykkede angreb i bredden og en liste over kendetegn. Den, der holder de tre niveauer adskilt, træffer bedre beslutninger.

## Hvorfor et faktatjek om PHP2Shell er nødvendigt

Næppe nogen sikkerhedssårbarhed de seneste år har skabt så mange overskrifter så hurtigt. Allerede før PHP-teamet den 21. oktober 2026 offentliggjorde opdateringerne, cirkulerede der ifølge rapporter forumindlæg, skærmbilleder og angivelige detaljer. Derefter fulgte myndighedsadvarsler, producentblogs, optællinger af eksponerede servere og en strøm af tips.

For driftsansvarlige betyder det: Ikke ethvert tal og ikke ethvert råd har samme kvalitet. En del stammer fra primære kilder, en del fra seriøs journalistik, en del fra spekulation. Denne artikel sorterer, hvad I kan bruge som sikkert grundlag for jeres beslutninger. Grundlaget for selve sårbarheden forklares på siden [Hvad er PHP2Shell?](https://phpsos.de/da/php2shell/was-ist-php2shell/).

## Hvilke kilder der vejer hvad

En enkel rangorden hjælper, når I læser enhver meddelelse:

1. **php.net:** PHP-projektet er den primære kilde til CVE-numre, vurderinger, berørte driftsformer, rettede versioner og midlertidige foranstaltninger. Hvordan projektet grundlæggende behandler sikkerhedsmeddelelser, beskriver vores indlæg om [PHP's sikkerhedsproces](https://phpsos.de/da/php/php-sicherheitsprozess/).
2. **Myndigheder:** BSI leverer vurderingen af situationen i Tyskland og handlingsanbefalinger, CERT-EU og CERT-Bund (det tyske statslige CERT) supplerer.
3. **Distributioner og udbydere:** Debian, Ubuntu, Red Hat, hostingudbydere og platformtjenester udtaler sig bindende kun om deres egne pakker og tjenester.
4. **Sikkerhedsfirmaer:** Cloudflare, Unit 42, CybelAngel og andre rapporterer ud fra egne målinger. Værdifuldt, men hver gang med egen metode.
5. **Medier og sociale netværk:** Gode til tempo, svage på detaljer. Udsagn herfra kræver en bekræftelse længere oppe i listen.

## Dokumenteret, rapporteret, ikke dokumenteret: oversigten

Tabellen nedenfor placerer de hyppigste udsagn. „Dokumenteret“ betyder: primær kilde eller myndighed. „Rapporteret“ betyder: fra medier eller producentoplysninger, ikke uafhængigt bekræftet.

| Udsagn | Vurdering | Grundlag |
|---|---|---|
| To sårbarheder, CVE-2026-109618 og CVE-2026-109619 | dokumenteret | php.net |
| Vurdering CVSS v4.0 9,2, kritisk | dokumenteret | php.net |
| Vurdering CVSS 10 | ikke holdbar | ifølge rapporter fra et forumindlæg før meddelelsen |
| Rettet i 8.5.12, 8.4.27, 8.3.36, 8.2.35 | dokumenteret | php.net |
| mod_php med højeste risiko, exploit vist før applikationskode | dokumenteret | php.net |
| Næsten alle versioner til og med PHP 5.4 berørt | rapporteret | fagpresse |
| Første angrebsforsøg den 17.10. | rapporteret | mediedækning med henvisning til Amazon |
| Mere end 22,6 mio. eksponerede instanser | rapporteret | Unit 42, ifølge TechTarget |
| Vellykkede angreb i bredden | ikke dokumenteret | ifølge BSI indledningsvis ikke kendt |
| Bekræftede Indicators of Compromise | findes ikke | ingen offentliggørelse |
| Midlertidige foranstaltninger beskytter fuldstændigt | forkert | php.net kalder dem udtrykkeligt ufuldstændige |

Det er påfaldende, hvor tidligt tal gør sig selvstændige. Vurderingen 10,0 fra forumindlægget dukkede stadig op i indlæg flere dage senere, selv om PHP-teamet for længst havde offentliggjort 9,2.

## Hvor usikkerheden egentlig ligger

Det største åbne spørgsmål er ikke teknisk, men tidsmæssigt: Hvad er der sket mellem det første rapporterede angrebsforsøg og patchen på de enkelte servere? Det findes der ikke noget generelt svar på. Cloudflare og Patchstack rapporterede om angrebsforsøg, watchTowr har efter egne oplysninger genskabt CVE-2026-109618. Huntress så til gengæld på tidspunktet for sin meddelelse ingen angreb i partnermiljøer.

Disse udsagn modsiger ikke hinanden. De beskriver forskellige udsnit: en stor proxytjeneste, et sikkerhedsfirma for plugins, et forskerhold og et firma med egen kundebase. Et samlet billede fremkommer ikke heraf.

Tilsvarende ved spørgsmålet om, hvilke versioner der er berørt. For 8.2 til 8.5 er situationen klar. For ældre grene findes der minimale kildekode-backports til 7.4, 8.0 og 8.1, men ingen officielle udgivelser. Det, der ligger før, er ifølge fagpressen næsten uden undtagelse berørt. For jeres planlægning gør det næppe nogen forskel: En server med PHP 8.1 eller ældre uden bekræftet backport skal behandles som udsat.

> **Vigtigt:**
> Manglende beviser for angreb er ikke bevis for sikkerhed. Fordi der ikke findes bekræftede kendetegn, kan et angreb på en enkelt server kun vurderes ved at undersøge adfærden, ikke ved hjælp af en liste.

## Hvad I kan udlede heraf for jeres servere

Af de dokumenterede fakta følger få, klare trin. Af de ikke dokumenterede følger først og fremmest forsigtighed.

1. **Kontrollér patchstatus:** rettet version eller backport bekræftet af udbyderen. Det viste versionsnummer alene er ikke nok.
2. **Genstart alle PHP-processer:** Nye filer virker først, når der ikke længere kører gamle processer.
3. **Sikr logs fra og med den 20.10.:** Fagpressen anbefaler det, så en senere undersøgelse fortsat er mulig.
4. **Undersøg for spor:** Nye PHP-filer i upload-mapper, ukendte cronjobs, webserverprocesser med shell. Siden [Er jeg allerede kompromitteret?](https://phpsos.de/da/php2shell/bin-ich-gehackt-anzeichen/) fører jer igennem undersøgelsen.
5. **Kontrollér råd:** Gennemfør kun tips fra fora og sociale netværk, hvis de kan føres tilbage til php.net eller en myndighed. Hvilke anbefalinger der lige nu gør skade, samler indlægget [Farlige falske tips om PHP2Shell](https://phpsos.de/da/blog/gefaehrliche-falschtipps/).

Til den interne kommunikation hjælper den samme adskillelse. Den, der forelægger ledelsen „dokumenteret“, „rapporteret“ og „åbent“ hver for sig, undgår både alarmisme og falsk afblæsning.

## Hvordan hjælper PHP SOS konkret?

- **Situationen for jeres systemer:** Vi overfører de dokumenterede fakta til jeres servere og adskiller i dokumentationen, hvad der er målt, hvad der er rapporteret, og hvad der er åbent.
- **Patch og dokumentation:** Vi kontrollerer pakkestatus og genstart af hver PHP-tjeneste og fastholder det skriftligt.
- **Sporundersøgelse:** Vi sikrer logs fra og med den 20. oktober og leder efter afvigende adfærd, indtil hændelsen er afsluttet og dokumenteret.
- **Løbende vurdering:** Nye meddelelser vurderer vi for jer, før de bliver til foranstaltninger.

Forløbet beskrives under [PHP2Shell-akuthjælp](https://phpsos.de/da/leistungen/php2shell-soforthilfe/).

## Konklusion

PHP2Shell er alvorligt, og det er veldokumenteret. Netop derfor er det værd at se nøgternt på sagen: De primære kilder rækker til alle vigtige beslutninger. Det, der cirkulerer ud over dem, er ofte hurtigere end præcist. Patch, genstart, sikring af logs og undersøgelse for spor er fortsat svaret, uanset hvilket tal der lige nu gør rundt.


## Ofte stillede spørgsmål

**Er PHP2Shell vurderet til CVSS 10?**  
Nej. Tallet 10 stammer ifølge rapporter fra et forumindlæg, der cirkulerede før den officielle meddelelse. PHP-teamet vurderer begge sårbarheder til CVSS v4.0 9,2. Det er alligevel kategorien kritisk.

**Findes der en liste med kendetegn for PHP2Shell-angreb?**  
Ikke hidtil. Der findes ingen offentliggjorte, bekræftede Indicators of Compromise. Den, der vil undersøge, om en server har været berørt, må holde øje med afvigende adfærd, f.eks. webserverprocesser, der starter en shell, eller nye PHP-filer i upload-mapper.

**Hvilken kilde er mest pålidelig ved PHP2Shell?**  
For de tekniske fakta meddelelserne på php.net, for vurderingen af situationen i Tyskland BSI (det tyske forbundsagentur for informationssikkerhed). Mediedækning og producentblogs supplerer billedet, men bør markeres som rapporter og læses op imod den primære kilde.

**Er virkelig alle PHP-versioner fra og med PHP 5 berørt?**  
Situationen er dokumenteret for grenene 8.2 til 8.5, hvor der findes opdateringer. Ifølge fagpressen er næsten alle versioner helt tilbage til PHP 5.4 berørt; CERT-EU anså ifølge rapporter versioner fra og med PHP 5 for mulige. Der findes ingen officielle opdateringer til ældre versioner, så I bør under alle omstændigheder behandle dem som udsatte.

## Kilder

- [php.net: Sikkerhedsmeddelelser](https://www.php.net/)
- [BSI: Bundesamt für Sicherheit in der Informationstechnik (det tyske forbundsagentur for informationssikkerhed)](https://www.bsi.bund.de/)
- [BleepingComputer: PHP ships emergency patches for critical PHP2Shell flaws](https://bleepingcomputer.com/news/security/php-ships-emergency-patches-for-critical-php2shell-flaws)
- [TechTarget: PHP2Shell, 22M exposed servers at risk](https://www.techtarget.com/cybersecurity/news/366652444/PHP2Shell-22M-exposed-servers-at-risk-as-emergency-patches-released)