Aktuel situation: PHP2Shell. To kritiske PHP-sårbarheder (CVSS 9,2) tillader skadelig kode uden login. Rettelser siden 21.10.2026.Hvad der skal gøres nu →

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

Alle dokumenterede datoer for PHP2Shell i ét overblik, fra det første observerede angrebsforsøg til status 25.10.2026, og hvad det betyder for jeres kontrol.

Status 5 min. læsetidVejledninger

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?.

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.

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:

; 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.

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å:

# 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.

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.

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

Akut kontakt

Hver time tæller. Skriv til os nu.

Beskriv kort system, PHP-version og observation. Vi vender tilbage, afklarer situationen og arbejder på afstand, indtil hændelsen er afsluttet og dokumenteret.

Akut hjælp