EU:s Cyberresiliensakt ändrar spelreglerna för WordPress-tillägg

EU:s Cyberresiliensakt (Cyber Resilience Act, CRA) ställer för första gången hårda säkerhetskrav på programvara med digitala element, inklusive de WordPress-tillägg som miljontals webbplatser världen över bygger på. Lagen trädde i kraft i december 2024 och börjar bita med fullt kraft mot slutet av 2027. Det händer inte ett ögonblick för tidigt.

Under juni 2026 drabbades WordPress-ekosystemet av en serie leveranskedjeattacker mot populära tillägg, där angripare lyckades injicera skadlig kod i paket som sedan distribuerades till hundratusentals sajter. Det är precis det scenariot som CRA är konstruerad för att motverka: att göra tilläggens leveranskedja till en säkerhetsfråga snarare än bara ett underhållsärende. Reglerna förändrar vad du som sajtägare kan förvänta dig av de tillägg du installerar, och vad du som tilläggsutvecklare måste kunna visa upp.

Tre datum att hålla koll på

CRA rör sig i etapper. Det finns gott om tid att förbereda sig, men stegen kommer i ordning och den som väntar till sista stund riskerar att hamna fel.

Vad det betyder för dig som driver en WordPress-sajt

Låt oss vara tydliga med vad CRA faktiskt reglerar. Det är tillverkarna och tillhandahållarna av produkter med digitala element som träffas av lagen, inte sajtägaren som använder ett tillägg. Din sajt blir alltså inte olaglig om du kör ett tillägg utan CE-märkning den 12 december 2027. Det är utvecklaren som bär det regulatoriska ansvaret.

Det praktiska värdet för dig som sajtägare är indirekt men reellt. CRA tvingar tilläggsförfattare att upprätta en dokumenterad sårbarhetshanteringspolicy (på engelska: Vulnerability Disclosure Policy, VDP). Det innebär att du som användare kommer kunna se hur ett tillägg hanterar säkerhetsrapporter: om det finns ett officiellt sätt att rapportera problem, hur snabbt de lovar att agera och hur de kommunicerar fixar. De tillägg som saknar en sådan policy faller utanför EU-marknaden efter december 2027.

Märk att detta sätter press på den del av WordPress-ekosystemet som länge förlitat sig på informella processer. Att ett tillägg är populärt eller har bra betyg på WordPress.org är inte samma sak som att den hanterar säkerhetsrapporter professionellt. CRA skapar en tydligare signal att leta efter.

Vad det betyder för dig som säljer ett WordPress-tillägg

Är du en svensk utvecklare som säljer ett tillägg, antingen direkt, via WordPress.org med donate-knapp, via CodeCanyon eller via din egen sajt? Då är chansen stor att du omfattas av CRA. Monetisering i någon form räcker för att dra in dig i scopet, oavsett om koden är GPL och öppen källkod. Det är en viktig distinktion: det är inte licensen utan det kommersiella inslaget som avgör. Tillägg som distribueras helt kostnadsfritt och utan kommersiellt syfte är undantagna.

De flesta WordPress-tillägg hamnar i CRA:s "default"-kategori, den lägsta risknivån. Det innebär att du som utvecklare inte behöver anlita ett externt certifieringsorgan för att bli godkänd. En egenbedömning räcker. Men egenbedömningen är inte ett tomt pappersexercis. Du behöver dokumentera hur du hanterar säkerhetsfrågor, och dokumentationen måste vara tillgänglig för användare och myndigheter.

I praktiken handlar det om att upprätta en tydlig VDP som svarar på tre frågor: hur rapporterar man en sårbarhet till dig, hur lång tid tar det innan du svarar, och hur kommunicerar du när en fix är på plats. Från 11 september 2026 tillkommer rapporteringsskyldigheten, vilket innebär att aktivt utnyttjade sårbarheter ska anmälas till din nationella CSIRT (i Sverige: NCSC/CERT-SE) via ENISA:s plattform. Processen och teknisk vägledning hittar du på EU-kommissionens officiella CRA-sida.

Hur förbereder du dig redan nu

Tidslinjen ger ett riktigt antal månader att landa i rätt position, men det gäller att inte låta dem försvinna.

Som sajtägare är det viktigaste att börja titta på om de tillägg du är beroende av har en aktiv och kommunicerande underhållare. Finns det ett sätt att rapportera säkerhetsproblem? Uppdateras tillägget regelbundet? En tydlig VDP kommer bli en indikator att leta efter, ungefär som HTTPS-hänglåset en gång blev det. Sajter som kör en webbapplikationsbrandvägg (WAF) har dessutom ett extra lager skydd mot just den typ av injektion som vi såg i junivågen.

Som tilläggsutvecklare är det klokt att börja nu. Skriv ihop en VDP och publicera den, gärna på en fast URL i ditt repo. Inventera vilka tredjepartsbibliotek ditt tillägg är beroende av och hur du håller koll på säkerhetsbulletiner för dem. Det är just leveranskedjan, de paket som ditt paket i sin tur bygger på, som visade sig vara den svaga länken under junivågen. CRA ställer krav på att du kan följa den kedjan och agera när något brister.

Det återstår en del detaljer att klarlägga, bland annat hur rapporteringsinfrastrukturen via ENISA konkret ska fungera för enskilda tilläggsutvecklare. EU-kommissionen publicerar löpande vägledning och det är den primära källan att följa framöver.