PHP2Shell var en alvorlig påmindelse om, hvor afhængig nettet er af software, der kræver løbende sikkerhedsarbejde. I oktober 2026 udløste to kritiske fejl i PHP hasteopdateringer af et sprog, som ifølge rapporter bruges af op mod 70 procent af websites.
11 Episoden satte også fokus på et større spørgsmål: Har open source-projekter kapacitet og finansiering nok til at gennemgå, rette og vedligeholde software, som store dele af nettet bygger på?
22
Hvad skete der med PHP2Shell?
Sårbarhederne CVE-2026-109618 og CVE-2026-109619 kunne gøre det muligt for en angriber at afvikle kode på afstand på berørte PHP-systemer – uden først at logge ind. Begge fik en alvorlighedsscore på 9,2.
9
17 Der var tale om fejl i selve PHP-miljøet; det betyder ikke, at alle PHP-applikationer var usikre.
PHP udgav rettelser den 21. oktober 2026 i versionerne 8.5.12, 8.4.27, 8.3.36 og 8.2.35.
18
27 Calif oplyser i sin forskningsbeskrivelse, at Calif, OpenAI og Wiz fandt sårbarhederne.
15 Medier beskrev også et sammenbrud i den koordinerede offentliggørelse: PHP’s vedligeholdere beskyldte Chainguard for at have delt oplysninger før den planlagte offentliggørelse, hvorefter projektet udsendte rettelserne tidligere end planlagt.
35
37
PHP’s udbredelse er med til at forklare, hvorfor sagen hastede. Medier anslog, at sproget bruges af op mod 70 procent af websites, men det tal siger noget om udbredelsen – ikke hvor mange websites der var sårbare eller kompromitterede.
11 De tilgængelige kilder bekræfter heller ikke den specifikke påstand om, at EFF anslog, at mere end 33 millioner systemer stadig var sårbare den 23. oktober.
Angrebsforsøg er ikke det samme som vellykkede indbrud
Amazon skal ifølge rapportering have registreret et forsøg på at udnytte sårbarhederne den 17. oktober, før rettelserne blev offentliggjort. Senere beskrev virksomheden omfattende forsøg på at udnytte fejlene.
34 Andre medier skrev om millioner af forsøg.
6 Separat blev der rapporteret om forebyggende nedlukninger, mens organisationer håndterede sårbarhederne, blandt andet af tjenester med tilknytning til Japans finansministerium og Rotterdam Havn.
12
Men et forsøg på at udnytte en sårbarhed dokumenterer ikke i sig selv, at et angreb lykkedes. BBC skrev den 22. oktober, at der endnu ikke var rapporteret om vellykket udnyttelse, og Security Affairs skrev tilsvarende den 23. oktober, at vellykkede angreb ikke var bekræftet.
9
31 Forskellen kan skyldes, at medierne rapporterede på forskellige tidspunkter eller brugte ordet »udnyttelse« på forskellige måder. Kilderne her underbygger bekymring over angrebsaktivitet – ikke en konklusion om, at millioner af systemer blev kompromitteret.
Læren for open source: Fund af fejl kræver opfølgning
PHP2Shell viser, at sårbarheder kan findes selv i veletableret, udbredt software. Men opdagelsen er kun begyndelsen: Rettelser skal gennemgås og udgives, og de ansvarlige for systemerne skal finde de berørte installationer og installere opdateringerne. Sovereign Tech beskrev selv sagen som et tegn på et finansieringshul i sikkerhedsarbejdet med kritisk open source-software.
22
Derfor er kapaciteten til at håndtere sikkerhedsarbejdet mindst lige så vigtig som antallet af fejl, der bliver fundet. Flere fund kan betyde mere arbejde for vedligeholdere og sikkerhedsteams. Men en rapporteret stigning i sårbarheder beviser ikke i sig selv, at software bliver mindre sikker, eller at AI har forårsaget stigningen. At finde en fejl skaffer ikke automatisk de mennesker, der skal validere fundet, koordinere offentliggørelsen eller udvikle og installere en pålidelig rettelse.
Den forsigtige konklusion er altså ikke, at PHP i sig selv er usikkert. Pointen er, at software, som bruges på en stor del af nettet, kræver vedvarende sikkerhedsgennemgang og vedligeholdelse – og at hurtigere opdagelse gør arbejdet mere presserende.
11
22
Hvad bør organisationer, der bruger PHP, gøre?
Organisationer med PHP bør:
- Få overblik over systemer, der er tilgængelige fra internettet. Find ud af, hvilke tjenester der bruger PHP, og registrér de versioner, der faktisk kører.
- Installere den relevante rettelse. Brug opdateringen til den PHP-gren, systemet kører på, eller følg verificerede anvisninger fra leverandøren, hvis PHP-miljøet leveres eller vedligeholdes af en tredjepart. PHP offentliggjorde rettelser den 21. oktober.
18
27
- Kontrollere den kørende tjeneste. Bekræft, at systemets aktive processer bruger den opdaterede PHP-version. Vejledningen anbefaler også at genstarte PHP-processer efter opdateringen.
32
- Beskrive hændelser præcist. Skeln mellem berørte systemer, angrebsforsøg, bekræftede kompromitteringer og ubekræftede påstande. En forebyggende nedlukning eller registreret angrebstrafik er ikke dokumentation for et vellykket indbrud.
Den varige lære fra PHP2Shell handler om hele sikkerhedskæden: opdagelse, gennemgang, koordineret offentliggørelse, udgivelse af rettelser og udrulning er alle nødvendige led. Finansiering af vedligeholdelsen bag kæden er en del af beskyttelsen af kritisk open source-infrastruktur – ikke en valgfri ekstraudgift.
22