11 września 2026 zaczęła obowiązywać pierwsza część unijnego Cyber Resilience Act. To nowe prawo dotyczy prawie każdego oprogramowania sprzedawanego w Unii Europejskiej. Dotyczy też komercyjnych wtyczek i motywów WordPress. Jeśli tworzysz, sprzedajesz albo wdrażasz oprogramowanie dla klientów w Europie, ten przepis prawdopodobnie już cię obowiązuje.

W tym artykule wyjaśniamy, czym jest Cyber Resilience Act, co konkretnie zmieniło się 11 września i jakie obowiązki mają teraz twórcy wtyczek WordPress.

Czym jest Cyber Resilience Act

Cyber Resilience Act, w skrócie CRA, to Rozporządzenie UE 2024/2847. To nowe unijne prawo o cyberbezpieczeństwie produktów cyfrowych. Obejmuje bardzo szeroki zakres produktów. Chodzi o każde oprogramowanie i sprzęt z komponentami cyfrowymi, które trafia na rynek europejski.

Komercyjne wtyczki i motywy WordPress mieszczą się w tym zakresie. Mieszczą się w nim też agencje, które tworzą i dostarczają własne wtyczki klientom z Unii Europejskiej. Nie ma znaczenia, gdzie ma siedzibę twoja firma. Liczy się to, czy twój produkt trafia do użytkowników w UE i czy ma element komercyjny.

Co zmieniło się 11 września 2026

CRA wchodzi w życie etapami. Pełny zestaw obowiązków zacznie obowiązywać dopiero w grudniu 2027. Ale od 11 września 2026 działa już pierwszy, ważny element. Chodzi o obowiązek raportowania aktywnie wykorzystywanych podatności.

W praktyce oznacza to, że jeśli wtyczka ma lukę bezpieczeństwa i ktoś realnie ją wykorzystuje w atakach, musisz to zgłosić. Zgłoszenie trafia do ENISA, europejskiej agencji do spraw cyberbezpieczeństwa, przez jeden wspólny system zwany Single Reporting Platform. Masz na to 24 godziny od momentu, kiedy się o tym dowiesz. Musisz też bez zbędnej zwłoki poinformować użytkowników swojego produktu.

W ekosystemie WordPress ten przepis ma szczególne znaczenie. Popularne wtyczki bywają aktywnie atakowane w ciągu kilku godzin od publicznego ujawnienia luki. To oznacza, że aktywne wykorzystanie podatności jest tu raczej regułą niż wyjątkiem, a nie rzadkim scenariuszem.

Co musisz mieć, żeby spełnić wymogi

Żeby w ogóle móc zgłosić podatność w ciągu 24 godzin, musisz najpierw wiedzieć, że ona istnieje. To brzmi jak oczywista oczywistość, ale wielu twórców wtyczek nie ma dziś żadnego procesu, który by to umożliwiał. CRA wymaga kilku konkretnych elementów.

Polityka zgłaszania podatności (VDP). Jasny kanał kontaktu dla badaczy bezpieczeństwa, opisany proces zgłaszania i ujawniania luk.
SBOM, czyli lista komponentów. Spis bibliotek i zależności użytych w produkcie, żeby wiedzieć, co dokładnie trzeba monitorować.
Bieżący monitoring podatności. Aktywne śledzenie znanych luk w komponentach, z których korzysta twój produkt.
Ustalony proces wewnętrzny. Wiadomo z góry, kto ocenia zgłoszenie, kto pisze raport do ENISA i kto informuje klientów.
Dokumentacja techniczna. Materiały potwierdzające, że powyższe procesy faktycznie działają, gotowe na wypadek kontroli.

Pełny zestaw wymogów, w tym deklaracja zgodności UE i oznaczenie CE, zacznie obowiązywać w grudniu 2027. Elementy związane z raportowaniem podatności działają już teraz.

Jakie są konsekwencje braku zgodności

Kary za naruszenie CRA są wysokie. Mowa o grzywnach do 15 milionów euro albo do 2,5% globalnego rocznego obrotu firmy, w zależności od tego, która kwota jest wyższa. Organy nadzoru mogą też nakazać wycofanie produktu z rynku europejskiego.

Warto podkreślić jedną rzecz. Nie chodzi o karanie za samo istnienie luki w kodzie. Luki bezpieczeństwa zdarzają się każdemu, nawet najlepszym zespołom. Chodzi o to, czy masz proces, który pozwala tę lukę wykryć, ocenić i zgłosić na czas. Firma bez kanału zgłaszania podatności i bez monitoringu zależności może naruszyć przepisy, nawet jeśli niczego świadomie nie ukrywała. Po prostu nigdy się nie dowiedziała, że problem istnieje.

Co to oznacza w praktyce dla firm korzystających z WordPress’a

Jeśli prowadzisz sklep na WooCommerce albo stronę firmową na WordPressie, CRA nie nakłada obowiązków bezpośrednio na ciebie jako użytkownika. Ale ma znaczenie, z czyich wtyczek korzystasz. Dostawca z realnym procesem zgłaszania podatności i monitoringiem zależności zwykle reaguje szybciej, kiedy coś się dzieje. To realna różnica, kiedy okno między ujawnieniem luki a atakiem liczy się w godzinach.

Przy wtyczkach, które sami rozwijamy, w tym BookingHive, Firevert i Sentrix, traktujemy te wymogi jako naturalną część rozwoju produktu, nie jako dodatkowe obciążenie na papierze. Podobnie w utrzymaniu WordPressa w modelu SiteCare zwracamy uwagę na to, czy używane wtyczki mają udokumentowany proces bezpieczeństwa, a nie tylko dobrą opinię w katalogu.

Jeśli chcesz sprawdzić, jak wygląda to u ciebie, możesz zacząć od audytu technicznego swojej strony albo skontaktować się z nami bezpośrednio.

Najczęściej zadawane pytania

Czy Cyber Resilience Act dotyczy darmowych wtyczek WordPress

Bezpłatne wtyczki bez elementu komercyjnego zwykle nie podlegają bezpośrednio pod CRA. Jeśli jednak taka wtyczka trafia do produktu komercyjnego, obowiązki i tak spadają na firmę, która ten produkt sprzedaje.

Od kiedy trzeba spełniać wymogi CRA

Obowiązek raportowania aktywnie wykorzystywanych podatności działa od 11 września 2026. Pełny zestaw wymogów, w tym dokumentacja techniczna i oznaczenie CE, zacznie obowiązywać w grudniu 2027.

Czy agencja tworząca wtyczki na zamówienie też podlega pod CRA

Tak. Agencje dostarczające własne wtyczki lub motywy klientom z Unii Europejskiej mieszczą się w zakresie CRA, niezależnie od tego, gdzie ma siedzibę sama agencja.

Źródła: WordPress.org, HackerOne, DEV Community, EU Cyber Resilience Act and WordPress.