PHP2Shell er fællesbetegnelsen for to kritiske sårbarheder i PHP: CVE-2026-109618 og CVE-2026-109619. Under bestemte forhold kan de gøre det muligt for en angriber at køre kode på en berørt server uden først at logge ind. PHP udsendte rettelser 21. oktober 2026, og nogle organisationer lukkede midlertidigt tjenester, mens de undersøgte og håndterede risikoen. Rapporter om scanning og angrebsforsøg skal dog ikke forveksles med bekræftede vellykkede indbrud.
4
7
18
Hvad går PHP2Shell ud på?
Fejlene ligger i PHP selv – ikke i et bestemt website, plugin eller indholdsstyringssystem. Den ene handler om håndtering af situationer, hvor PHP løber tør for hukommelse; den anden om forældet global tilstand. Under visse omstændigheder kan en særligt udformet forespørgsel føre til fjernkørsel af kode. Den ene fejl kan også afsløre følsomme data fra processens hukommelse.
4
11
PHP bruges bredt på nettet. Nogle opgørelser anslår, at sproget driver op mod 70 procent af websites. Det betyder ikke, at alle PHP-websites var sårbare eller lige udsatte: Risikoen afhænger blandt andet af PHP-versionen, konfigurationen og om den berørte kodevej kan nås.
45
46
AI-assisteret research og en læk før offentliggørelsen
Rapporteringen krediterer forskere og teams hos Wiz, Calif og OpenAI for arbejdet med at finde og håndtere fejlene; noget af dækningen beskriver AI som en del af researchprocessen. De tilgængelige oplysninger fastslår ikke alle detaljer i forløbet – herunder en bestemt rækkefølge fra et WordPress- til et Drupal-angreb eller den præcise fordeling af arbejdet med de to CVE’er.
14
45
Ifølge omtalen var den underliggende fejl i håndteringen af hukommelse blevet bemærket tidligere, men dens potentiale for fjernkørsel af kode blev først demonstreret senere. Det er en vigtig forskel: At opdage en mistænkelig fejl er ikke det samme som at have vist, at den kan bruges i et praktisk angreb.
22
38
Oplysninger om sårbarhederne blev lækket før den planlagte offentliggørelse. Det øgede presset på de involverede og bidrog til kapløbet om at få rettelser klar.
6
23 Forløbet viser, hvordan en sikkerhedsopdatering hurtigt kan blive en driftsmæssig udfordring, når offentliggørelse, afprøvning og installation skal ske på kort tid.
Rettelser, angrebsforsøg og hvad rapporterne viser
De rettede PHP-versioner, der blev udsendt 21. oktober, var 8.2.35, 8.3.36, 8.4.27 og 8.5.12. Administratorer bør også kontrollere sikkerhedsmeddelelsen fra deres hosting- eller operativsystemleverandør: Nogle leverandører indarbejder rettelser i ældre versionsgrene, så versionsnummeret ikke nødvendigvis svarer direkte til PHP-projektets.
4
39
Sikkerhedsfirmaer rapporterede scanning og forsøg på udnyttelse omkring offentliggørelsen. Omtale af Cloudflare beskrev også en kraftig stigning i antallet af forsøg. Sådanne tal tæller forespørgsler eller forsøg, som bestemte tjenester har observeret; de viser ikke, hvor mange systemer der faktisk blev kompromitteret.
5
36
Rapporterne var forskellige i deres vurdering af, om vellykket udnyttelse var blevet bekræftet. BBC skrev 22. oktober, at der ikke var rapporteret om vellykkede angreb. En senere meddelelse fra Beazley omtalte omfattende forsøg, men ikke bekræftede masseudnyttelse. Sansec nedjusterede også sin første vurdering og skrev, at masseudnyttelse virkede mindre sandsynlig end først antaget. Vurderingerne gælder på det tidspunkt, de blev fremsat, og gør ikke en uopdateret server sikker.
7
9
18
Hvorfor gik nogle tjenester midlertidigt offline?
Nogle organisationer lukkede eller begrænsede tjenester midlertidigt, mens de vurderede deres eksponering og forberedte opdateringer. Ifølge rapporteringen tog den britiske regering 32 tjenester offline. En statussporing registrerede desuden mere end 100 tjenester, som offentliggjorde driftsforstyrrelser, vedligeholdelsesbeskeder eller advarsler om PHP2Shell, før en rettelse var tilgængelig. Det viser, at hastetiltagene kunne forstyrre driften – ikke i sig selv, at tjenesterne var blevet angrebet.
22
34
Andre artikler beskrev myndigheders og organisationers reaktioner i flere lande. De tilgængelige oplysninger giver dog ikke en fuldstændig, uafhængigt bekræftet liste over berørte tjenester eller dokumentation for alle navngivne lokale driftsafbrydelser.
20
25
Hvad bør webansvarlige gøre?
- Find alle PHP-installationer. Gennemgå produktionsservere, containere, sekundære systemer og administrerede hostingmiljøer – ikke kun hovedwebsitet.
- Installer den relevante rettelse hurtigst muligt. Brug en rettet PHP-version eller en rettelse, som leverandøren bekræfter som tilsvarende. Genstart PHP-processer eller tjenester efter behov, og kontrollér, hvilken version der rent faktisk kører. Opdateringer af plugins eller PHP-applikationer erstatter ikke en rettelse af selve PHP-runtime-miljøet.
14
39
- Begræns eksponeringen, hvis du ikke kan opdatere med det samme. Overvej at begrænse offentlig adgang eller midlertidigt lukke en berørt tjeneste ud fra dens eksponering og betydning for driften. Netværksregler er en midlertidig beskyttelse – ikke en erstatning for opdateringen.
- Undersøg tegn på kompromittering. Gennemgå relevante logfiler, og se efter uventede filer, processer eller administratorkonti. Hvis der er mistanke om indbrud, så bevar dokumentationen og undersøg hændelsen. En installeret rettelse fjerner ikke nødvendigvis sporene efter et tidligere angreb.
- Få leverandøren til at bekræfte dækningen. Mindre organisationer, der bruger hosting eller administrerede tjenester, bør bede om en tydelig bekræftelse på, at alle PHP-installationer, de er afhængige af, er håndteret.
NSA anbefalede kritiske sikkerhedsopdateringer og oplyste, at myndigheden prioriterede at identificere ondsindede aktører, der kunne forsøge at udnytte PHP2Shell. FBI opfordrede også organisationer til at opdatere deres PHP-installationer. De tilgængelige kilder dokumenterer ikke én fælles ordre fra FBI, NSA og CISA om, at alle organisationer skulle lukke systemer ned, hvis de ikke kunne opdatere.
17
28
Hvad kan privatpersoner gøre?
Hold personlige enheder, programmer og routere opdaterede, og brug multifaktorgodkendelse samt unikke adgangskoder. Det er gode generelle sikkerhedsvaner, men de retter ikke PHP på et website. Det ansvar ligger hos den, der driver websitet, eller hos hostingudbyderen.
Den praktiske lære af PHP2Shell er at installere og kontrollere sikkerhedsrettelser hurtigt – og at være forberedt på korte reaktionstider. Hændelsen understreger, hvor hurtigt sikkerhedsforskning og angrebsforsøg kan udvikle sig. Men dokumentationen giver ikke grundlag for at sidestille forsøgstal med bekræftede masseindbrud eller for at beskrive hændelsen som et generelt sammenbrud i websikkerheden.