PHP-larmet: när blir en sårbarhet en incident ni måste rapportera?
Två kritiska sårbarheter i PHP fick myndigheter i flera länder att släcka ner webbplatser under onsdagen. För er som omfattas av cybersäkerhetslagen är den tekniska frågan bara den ena halvan. Den andra är vad som händer om någon faktiskt tog sig in.
Vad har hänt
Två kritiska sårbarheter i programmeringsspråket PHP, CVE-2026-109618 och CVE-2026-109619, gör det möjligt att köra skadlig kod på en server utan att logga in. CERT-SE sätter allvarlighetsgraden till 9,2 av 10.
PHP driver en stor del av webben, bland annat WordPress, Drupal, Joomla, Magento och Laravel. Akuta säkerhetsuppdateringar släpptes under onsdagseftermiddagen: PHP 8.5.12, 8.4.27, 8.3.36 och 8.2.35.
I Finland stängde statliga Valtori ner myndigheternas webbtjänster, i Nederländerna togs parlamentets sajt tillfälligt ur drift, och åtgärder vidtogs även i Frankrike och Japan. Cloudflare uppger att man såg tidiga attackförsök redan före patchen. Hur utbrett utnyttjandet är varierar mellan källorna.
Under onsdagskvällen skickade NCSC ut ett blixtmeddelande med rekommenderade åtgärder, och civilförsvarsminister Carl-Oskar Bohlin gick ut med en skarp uppmaning i en skriftlig kommentar till TT: “Det är allvarliga sårbarheter som berör väldigt många organisationer och webbplatser.” Hans slutsats: berörda organisationer bör agera omedelbart.
Resonemanget bakom uppmaningen är värt att förstå, för det är inte självklart. När en säkerhetsuppdatering väl är släppt blir den också en karta. Angripare kan jämföra den nya koden med den gamla och räkna ut precis var hålet satt. Fönstret mellan att patchen blir tillgänglig och att den är installerad hos er är därför den farligaste perioden, inte veckorna innan någon visste något.
Måste vi rapportera det här?
Inte för att sårbarheten finns. En kritisk sårbarhet är i sig ingen incident. Rapporteringsplikten i cybersäkerhetslagen utlöses av en betydande incident, alltså när något faktiskt har hänt i er miljö: ett intrång, en driftstörning, data som läckt eller förvanskats.
Det betyder att den avgörande frågan de närmaste dygnen inte är "finns PHP hos oss", utan "har någon varit inne". Därför är spårsökningen minst lika brådskande som patchningen. Utan loggar och utan en genomgång vet ni inte vilken av de två situationerna ni befinner er i, och då kan klockan redan ha börjat ticka utan att någon märkt det.
Tidsfristerna, om det visar sig vara en incident
Cybersäkerhetslagen (2025:1506) gäller sedan den 15 januari 2026. Rapporterna går till NCSC vid FRA, som är Sveriges CSIRT-enhet. Fristerna räknas från det att ni fick kännedom om incidenten, inte från när den inträffade.
Inom 24 timmar: tidig upplysning till NCSC. Kort och preliminär, ni behöver inte ha hela bilden klar. Myndigheter som lyder under beredskapsförordningen har 6 timmar på sig.
Inom 72 timmar: incidentanmälan med en första bedömning av allvarlighetsgrad och konsekvenser. Betrodda tjänster har 24 timmar.
Inom en månad: slutrapport. Pågår incidenten fortfarande lämnas en lägesrapport, och slutrapporten kommer inom en månad efter att incidenten är löst.
Och om personuppgifter är inblandade
Då löper ett andra spår parallellt. En personuppgiftsincident ska anmälas till IMY inom 72 timmar, och i vissa fall ska de registrerade informeras. Det är en egen anmälan enligt GDPR, inte något som täcks av rapporten till NCSC. Två regelverk, två mottagare, delvis samma underlag.
Det här gör ni nu
Inventera. Var finns PHP hos er? Glöm inte det som följer med andra system: kontrollpaneler, containrar, gamla kampanjsajter, verktyg ni ärvt.
Uppdatera. Till de versioner leverantören släppt. Kan ni inte uppdatera direkt, isolera tjänsten från internet tills ni kan.
Leta spår. Gå igenom loggarna. Fråga leverantörerna som driftar åt er, i er egen takt och skriftligt.
Ta fram rapporteringsvägen innan ni behöver den. Vem fattar beslutet att anmäla, vem skriver, vem informerar ledningen? Det är sådant som inte går att improvisera klockan två på natten.
Dokumentera bedömningen. Även beslutet att inte rapportera behöver ha ett underlag.
Den här veckan blev en påminnelse om att det sällan är själva sårbarheten som avgör hur en organisation klarar sig. Det är om någon vet vad som ska hända i timmarna efteråt.
Behöver ni stöd i bedömningen?
Att veta vad lagen kräver är en sak. Att ha rapporteringsvägen på plats, med beslutsordning, underlag och dokumentation, är en annan. Det är den delen vi arbetar med varje dag, tillsammans med verksamheter i både privat och offentlig sektor.
Hör av er om ni vill gå igenom hur ni ligger till, eller om ni sitter med en konkret bedömning just nu och vill ha någon att stämma av med.
Kontakta oss: https://draftit.se/kontakt
Vill ni ha ämnet på djupet sänder vi webbinariet "Cybersäkerhetslagen är här. Vad behöver ni göra nu?" torsdag 22 oktober kl. 11.00. Anmäl dig även om du inte kan vara med live, då får du inspelningen efteråt: https://draftit.se/webbinarium/cybersakerhetslagen
Källor: CERT-SE, Kritiska sårbarheter i PHP (21 oktober 2026) · SVT Nyheter · TT · BleepingComputer · NCSC, Rapportera en betydande incident enligt cybersäkerhetslagen · Cybersäkerhetslagen (2025:1506).
