I tisdags kväll började det cirkulera uppgifter om två kritiska sårbarheter i PHP. Dagen efter släppte PHP-projektet nödpatchar, ett dygn tidigare än planerat, eftersom informationen hade läckt innan embargot gick ut. Sårbarheterna heter CVE-2026-109618 och CVE-2026-109619 och kallas sammantaget PHP2Shell. Båda har fått 9,2 på CVSS v4.0, och i klartext betyder det att en angripare utan konto kan köra egen kod på en webbserver.
Den som har arbetat med webbsäkerhet en längre tid tänker nog först på filuppladdning. PHP-miljöer har klassiskt angripits genom att någon lyckas ladda upp en fil med körbar kod, en webshell, och sedan anropar den. Det är inte vad som händer här, och skillnaden spelar roll både för hur man bedömer risken och, som vi ska se, för hur juridiken slår.
Felet sitter inte i WordPress, Drupal eller i den kod ditt företag har skrivit. Det sitter i själva PHP-motorn, i hur den hanterar ett fatalt fel som uppstår när minnet tar slut mitt i en förfrågan. PHP avbryter då det pågående arbetet genom att hoppa rakt ur sammanhanget, utan att städa ordentligt efter sig. Kvar blir interna pekare som visar på minne som redan har lämnats tillbaka. När nästa förfrågan hanteras av samma serverprocess kan PHP använda den gamla pekaren som om den vore giltig, och den som kan styra vad som hamnar i det återanvända minnet kan också styra vad PHP gör.
Angreppet blir möjligt utifrån eftersom PHP tolkar förfrågningar i multipartformat, samma format som en webbläsare använder när den skickar filer, redan innan applikationen har startat. Uppladdningsmekanismen är alltså vägen in, men ingen fil behöver sparas och applikationen behöver inte ens ha ett uppladdningsformulär. Forskarna på Wiz visar att en sida som bara skriver ut Hello World är lika sårbar. Det skal som angriparen sedan öppnar mot servern är följden av angreppet, inte själva angreppet.
Det finns en andra effekt som riskerar att hamna i skymundan. En av angreppsvägarna gör det möjligt att läsa ut innehåll ur serverprocessens minne, inbakat i en sessionscookie i svaret. Där kan det ligga lösenord, API-nycklar, sessionstoken och certifikat som tillhör helt andra användares förfrågningar. Den som tänker på Heartbleed från 2014 har rätt association. En server kan alltså ha läckt hemligheter utan att någon någonsin körde kod på den, och en patch i efterhand gör inte de läckta uppgifterna mindre läckta.
Koden har funnits i PHP sedan version 5.4 från 2012. Enligt PHP Foundation hittades tecken på felet redan vid en extern granskning 2024, men ingen kunde då visa hur det skulle utnyttjas och arbetet med en rättelse stannade av. Det som ändrade läget i år var att forskare använde AI-modeller för att kedja ihop flera svåra minnesfel till fungerande attacker, enligt Wiz en veckas arbete för en person i stället för månader för ett team. Jag tror att det är den detalj från den här veckan som kommer att leva kvar längst. Sårbarheter som tidigare var för komplicerade att utnyttja i praktiken är det inte längre, och komplexitet räcker inte som skydd.
Läget när jag skriver detta är att flera aktörer, bland annat Cloudflare och watchTowr, rapporterar exploateringsförsök. Amerikanska CISA hade i sin varning i onsdags inte sett någon exploatering, och sårbarheterna finns ännu inte i myndighetens katalog över utnyttjade sårbarheter. Något bekräftat intrång i ett namngivet system har jag inte sett. Skillnaden mellan försök och bekräftat utnyttjande låter som en teknisk nyans, men den får direkt juridisk betydelse.
Den första juridiska frågan en företagare bör ställa sig är vilken roll man har. Samma sårbarhet träffar olika regelverk beroende på om man säljer en produkt där PHP ingår eller driver en verksamhet som använder PHP.
Säljer du en produkt med digitala element som bygger på PHP, till exempel en nätverksapparat, en lagringsenhet eller programvara som kunden installerar själv, är du tillverkare enligt Cyber Resilience Act. Förordningens huvudkrav gäller först från december 2027, men skyldigheten att rapportera aktivt exploaterade sårbarheter har gällt sedan den 11 september i år. Den omfattar dessutom produkter som redan finns på marknaden, även sådana som såldes långt innan förordningen fanns. Fristerna är korta. En tidig varning ska lämnas inom 24 timmar, en anmälan inom 72 timmar och en slutrapport senast 14 dagar efter att en rättelse finns, allt via ENISA:s gemensamma rapporteringsplattform. EU-kommissionen, ENISA och CERT-EU påminde uttryckligen om den skyldigheten i sitt gemensamma uttalande om PHP i onsdags.
Här blir skillnaden från den tekniska bilden avgörande. Rapporteringsplikten utlöses inte av att en sårbarhet är allvarlig eller av att det finns en fungerande exploit. Den utlöses av tillförlitliga bevis för att en illasinnad aktör faktiskt har utnyttjat den. Kommissionens vägledning är dessutom tydlig med att när sårbarheten sitter i en tredjepartskomponent, som PHP, ska slutproduktens tillverkare rapportera först när den är exploaterad i den egna produkten. Att Cloudflare ser angreppstrafik mot sina kunder räcker alltså inte i sig. En kund som hör av sig om ett intrång, den egna telemetrin eller ett besked från en myndighet kan däremot göra det, och klockan börjar ticka när du med rimlig grad av säkerhet har konstaterat exploateringen. Mitt råd är att redan nu bestämma vem som gör den bedömningen och att skriva ner när och på vilket underlag den görs. Ett dygn är kort tid att reda ut ansvarsfördelning i.
Driver du i stället en webbplats, en webbshop eller en tjänst som kunderna når via webbläsaren faller du enligt kommissionens vägledning normalt utanför CRA, och då tar andra regelverk över. Omfattas verksamheten av cybersäkerhetslagen, som genomför NIS2 i Sverige och har gällt sedan den 15 januari, är kärnan inte rapporteringen utan riskhanteringen. Lagen kräver lämpliga och proportionella säkerhetsåtgärder, och direktivet pekar uttryckligen ut sårbarhetshantering och säkerhet i leverantörskedjan. Ledningen ska godkänna åtgärderna och kan hållas ansvarig för dem. PHP2Shell blir därför ett praktiskt prov på om verksamheten vet var den kör PHP, hur snabbt den kan patcha och vad den vet om sina leverantörers system. Det provet skrivs nu och inte den dag tillsynsmyndigheten hör av sig.
Att vara sårbar är inte en incident i lagens mening. Ett intrång eller ett läckage är det. Om händelsen har orsakat eller kan orsaka allvarlig driftsstörning, ekonomisk skada eller betydande skada för andra är den en betydande incident som ska rapporteras inom 24 timmar, följt av en anmälan inom 72 timmar och en slutrapport inom en månad. Notera att mottagaren har bytts. Sedan den 1 juli går rapporterna till Nationellt cybersäkerhetscenter vid FRA, där CERT-SE nu ingår, och inte längre till MCF.
Det finns också en bestämmelse som jag tror att många missar. Vid ett betydande cyberhot ska verksamhetsutövaren så snart det kan ske informera de kunder som kan påverkas om vilka skydds- och motåtgärder de själva kan vidta. En oautentiserad fjärrkörning av kod i den teknik som bär tjänsten ligger nära lagens definition av ett betydande cyberhot, och plikten kan alltså aktualiseras utan att något intrång har skett. Jag har inte sett någon myndighetsvägledning om just det här fallet, så det är min bedömning, men den är värd att ta på allvar.
Till detta kommer GDPR, som gäller oavsett storlek och sektor. Minnesläckan gör att inloggningsuppgifter och sessionsdata kan ha lämnat servern utan att det syns i applikationens loggar. Rör det personuppgifter ska incidenten anmälas till IMY inom 72 timmar, om det inte är osannolikt att den medför risk för de registrerade. Oavsett om den anmäls ska den dokumenteras.
Vad bör du då göra den här veckan? Uppdatera PHP till 8.5.12, 8.4.27, 8.3.36 eller 8.2.35 och starta om alla PHP-processer efteråt. Att uppdatera WordPress eller andra applikationer räcker inte, eftersom det är körmiljön under applikationen som är sårbar, och den kommer från serverpaketet, hostingleverantören eller containeravbilden. Fråga din hostingleverantör rakt ut om de har patchat och be om svaret skriftligt. Inventera var PHP finns hos er, även i kontrollpaneler, apparater och köpta system där det inte syns utåt. Kör ni PHP 8.1 eller äldre finns ingen ordinarie uppdatering, och CERT-SE rekommenderar att sådana system isoleras från internet om de inte kan uppdateras. De inställningar som cirkulerar som tillfälliga lösningar minskar risken för vissa angreppsvägar men gör inte servern säker. Har en internetexponerad server stått opatchad sedan i tisdags bör du byta de lösenord, nycklar och andra hemligheter som funnits på den, och leta efter tecken på intrång som nya PHP-filer i webbkatalogen eller skal som startats av webbservern.
Jag har länge hävdat att cybersäkerhet inte stannar i serverrummet, och den här veckan ger ett ovanligt tydligt exempel. Samma fel i minneshanteringen avgör om ett produktbolag har en rapporteringsplikt med ett dygns frist, om en verksamhet under cybersäkerhetslagen måste informera sina kunder och om ett litet e-handelsbolag har en personuppgiftsincident att anmäla. För att svara på de frågorna räcker det inte att läsa lagtexten, och det räcker inte att förstå vad som händer i serverns minne. Svaret finns där de två möts.