# PHP2Shell-tidslinje: kronologi fra 17. til 25. oktober 2026

> PHP2Shell-tidslinjen kort: fra det første angrebsforsøg den 17.10. til status 25.10.2026. Hvad hver dato betyder for jeres logs og kontrol.

Kilde: https://phpsos.de/da/ratgeber/php2shell-chronologie/  
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:** PHP2Shell-tidslinjen omfatter hidtil fire dokumenterede datoer: et første observeret angrebsforsøg den 17.10., forhåndsvarslingen fra php.net den 20.10., rettelserne den 21.10. kl. 16 tysk tid og en yderligere meddelelse om CVE-2026-115560 den 23.10.2026. For driftsansvarlige betyder det: patch, genstart alle PHP-processer og sikr logs senest fra den 20.10.

## Hvorfor en PHP2Shell-tidslinje er vigtig for driftsansvarlige

Ved en sårbarhed af denne alvor tæller det ikke kun, om jeres server er patchet i dag. Det afgørende er også, hvor længe den var sårbar før. Dette tidsvindue afgør, hvilke logs I sikrer, hvilke filer I kontrollerer, og om I med god grund kan udelukke en kompromittering.

PHP2Shell berører PHP selv, ikke et enkelt CMS. To kritiske sårbarheder, CVE-2026-109618 og CVE-2026-109619, muliggør kørsel af skadelig kode på afstand uden login. Begge er vurderet til CVSS v4.0 9,2. En letforståelig indføring finder I under [Hvad er PHP2Shell?](https://phpsos.de/da/php2shell/was-ist-php2shell/).

Den følgende kronologi indeholder kun datoer, der er dokumenteret pr. 25.10.2026. Hvor en oplysning bygger på medierapporter, er det anført.

| Dato | Begivenhed | Grundlag |
|---|---|---|
| 17.10.2026 | Første observerede angrebsforsøg (Amazon) | Medierapporter |
| 20.10.2026 | Forhåndsvarsling fra php.net | php.net |
| 21.10.2026, 14:00 UTC | Offentliggørelse af rettelserne (kl. 16 tysk tid) | php.net |
| 23.10.2026 | Meddelelse om CVE-2026-115560 | php.net |
| 25.10.2026 | Status for dette overblik | – |

## 17. oktober: det første observerede angrebsforsøg

Ifølge medierapporter blev et første angrebsforsøg observeret den 17.10.2026, meldt af Amazon. Det var fire dage før rettelserne. Der var altså en periode, hvor der allerede blev forsøgt angreb, men hvor der endnu ikke fandtes en opdatering.

Om og hvor mange angreb der lykkedes i denne fase, er ikke dokumenteret. Vigtigt for jeres egen kontrol er følgen: En server, der er patchet i dag, kan være kompromitteret tidligere. En patch fjerner ikke skadelig software, der allerede er smuttet ind, og beviser ikke, at der ikke skete noget før.

## 20. og 21. oktober: forhåndsvarsling og rettelser

Den 20.10.2026 varslede PHP-projektet sikkerhedsopdateringerne på php.net. Den 21.10.2026 kl. 14:00 UTC, altså kl. 16 tysk tid, fulgte de rettede versioner.

| Gren | Seneste sårbare status | Rettet i |
|---|---|---|
| PHP 8.5 | 8.5.11 | 8.5.12 |
| PHP 8.4 | 8.4.26 | 8.4.27 |
| PHP 8.3 | 8.3.35 | 8.3.36 |
| PHP 8.2 | 8.2.34 | 8.2.35 |

For PHP 8.1 og ældre findes der ikke længere officielle opdateringer, kun minimale kildekode-backports til 7.4, 8.0 og 8.1. Ifølge fagpressen er næsten alle versioner helt tilbage til PHP 5.4 berørt. Berørt er driftsformerne PHP-FPM, Apache med mod_php, php-cgi, FrankenPHP og LiteSpeed. Den højeste risiko ser PHP-teamet ved mod_php, hvor en exploit blev vist, før der overhovedet kører applikationskode.

Distributioner og hostingudbydere indspiller til tider backports. Så viser f.eks. Plesk fortsat 8.2.34, selv om serveren er patchet. Afgørende er pakkestatus og udbyderens bekræftelse, ikke det viste versionsnummer. Hvordan I kontrollerer det ordentligt, står under [Kontrollér PHP-version og patchstatus korrekt](https://phpsos.de/da/php2shell/php-version-pruefen/).

## 23. oktober: meddelelse om CVE-2026-115560

Den 23.10.2026 offentliggjorde PHP-projektet endnu en meddelelse, denne gang om CVE-2026-115560. En udnyttelse er ifølge den kun mulig ved en usædvanlig konfiguration: I konfigurationen står serialize_handler `php_binary` eller `php_serialize`, applikationen sætter den før `session_start()` om til `php` via `ini_set()`, og Session Upload Progress er aktiv.

Afhjælpningen er enkel og bør sættes uafhængigt af, om I kender denne konstellation hos jer selv:

```ini
; i php.ini, i FPM-poolen eller i serverkonfigurationen
; ikke via ini_set() eller .user.ini
session.upload_progress.enabled = 0
```

Genstart derefter alle PHP-workere. Den fuldstændige advisory skal følge med den næste almindelige bugfix-release. Indtil da er indstillingen den anbefalede overgangsløsning.

## Status 25. oktober: situation og åbne spørgsmål

BSI (det tyske forbundskontor for informationssikkerhed) har udråbt varslingsniveau 3 / orange. Det anbefaler øjeblikkelig opdatering og, hvis det ikke er muligt med det samme, midlertidigt at tage webserverne af nettet. BSI regnede med hurtig udnyttelse i stor skala; bekræftede vellykkede angreb i bredden var ifølge BSI til at begynde med ikke kendt. BSI's vurdering sammenfatter siden [Hvad BSI anbefaler om PHP2Shell](https://phpsos.de/da/compliance/bsi-empfehlungen/).

Cloudflare meldte om observerede angrebsforsøg og har udrullet beskyttelsesregler, men advarer om, at regler alene på baggrund af forespørgselsdata ikke er nok. Palo Alto Networks (Unit 42) talte mere end 22,6 millioner eksponerede, potentielt sårbare instanser. Bekræftede Indicators of Compromise er ikke offentliggjort; opdagelsen bygger på adfærdsanalyse.

Nogle udbydere har som forholdsregel taget websites offline. Det betyder ikke automatisk, at disse sider er blevet hacket. Åbent er pr. status for dette overblik først og fremmest, hvor mange servere der i tiden før patchen faktisk blev kompromitteret.

## Hvad tidslinjen betyder for jeres logs og kontrol

Af datoerne fremgår tre tidsrum: før 17.10., mellem 17.10. og jeres eget patch- og genstartstidspunkt samt derefter. Det midterste tidsrum er det kritiske. Jo længere det varede hos jer, desto grundigere bør kontrollen være.

> **Vigtigt:**
> Fagpressen anbefaler at gemme serverlogs fra den 20.10.2026. Sikr også eksisterende ældre logs, før den automatiske rotation sletter dem.

En enkel måde at sikre logs uændret og fastholde status på:

```bash
# Sikr logs samlet (tilpas stierne til jeres system)
sudo tar czf /root/logs-sicherung-$(date +%F).tar.gz /var/log/apache2 /var/log/nginx /var/log/php*
# Kontrolsum til det senere bevis
sha256sum /root/logs-sicherung-*.tar.gz
# Hvor længe opbevarer systemet logs?
grep -R "rotate" /etc/logrotate.d/
```

Notér desuden, hvornår præcis opdateringen blev indspillet, og hvornår PHP-processerne blev genstartet. Nye filer alene beskytter ikke, så længe gamle processer kører i hukommelsen. Hvordan I analyserer sikrede logs, beskriver vejledningen [Analysér weblogs efter et angreb](https://phpsos.de/da/ratgeber/logfiles-auswerten/).

## Hvordan hjælper PHP SOS konkret?

- Vi fastlægger sammen med jer serverens faktiske sårbarhedsvindue: pakkestatus, patchtidspunkt, genstart af alle workere.
- Vi sikrer logs og systemtilstand sporbart, før noget ændres.
- Vi undersøger for adfærdsmæssige påfaldende forhold som nye PHP-filer, fremmede processer og usædvanlige udgående forbindelser.
- Vi dokumenterer resultatet, så ledelse, databeskyttelsesansvarlige og forsikringsselskaber kan arbejde med det.

Forløbet beskriver vi nærmere i vores [PHP2Shell-akuthjælp](https://phpsos.de/da/leistungen/php2shell-soforthilfe/).


## Ofte stillede spørgsmål

**Hvornår blev PHP2Shell-rettelserne offentliggjort?**  
PHP-projektet offentliggjorde de rettede versioner den 21.10.2026 kl. 14:00 UTC, altså kl. 16 tysk tid. Rettet er PHP 8.5.12, 8.4.27, 8.3.36 og 8.2.35.

**Fra hvilken dato bør jeg gemme serverlogs?**  
Fagpressen anbefaler at gemme logs fra den 20.10.2026. Fordi et første angrebsforsøg ifølge medierapporter allerede blev observeret den 17.10., kan det betale sig også at sikre eksisterende ældre logs, før rotationen sletter dem.

**Er CVE-2026-115560 lige så farlig som de to første sårbarheder?**  
Ifølge meddelelsen fra 23.10.2026 kan den kun udnyttes ved en usædvanlig session-konfiguration. Som afhjælpning gælder session.upload_progress.enabled=0, indtil den næste almindelige bugfix-release udkommer.

**Findes der bekræftede Indicators of Compromise for PHP2Shell?**  
Nej, pr. 25.10.2026 er der ikke offentliggjort bekræftede Indicators of Compromise. Opdagelsen bygger på adfærdsanalyse, f.eks. usædvanlige processer, nye filer og påfaldende forbindelser.

## Kilder

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