Aktualizacja wtyczek WordPress: co się dzieje, gdy jej nie robisz
Powiadomienie o aktualizacji w kokpicie to nie prośba o zrobienie porządku. Dlaczego dopiero aktualizacja bezpieczeństwa ujawnia lukę, która wtyczka jest naprawdę groźna i co zmienia się od 11 września.
W niemal każdym kokpicie WordPressa obok pozycji „Wtyczki” widnieje mała liczba. Nikomu nie przeszkadza. Odkłada się ją na później, bo akurat jest coś pilniejszego, a przy następnym logowaniu liczba jest większa. Najciekawsze w tym wszystkim: nic się nie dzieje. Strona się ładuje, formularz kontaktowy wysyła wiadomości, sklep przyjmuje płatności. I właśnie w tym tkwi problem. Koszty bezczynności są niewidoczne, dopóki nie staną się widoczne, a wtedy widać je wszystkie naraz.
Ten artykuł wyjaśnia, co naprawdę dzieje się między powiadomieniem o aktualizacji a sytuacją kryzysową, i to z perspektywy tych, którzy te aktualizacje piszą. Sami tworzymy wtyczki do WordPressa, publikujemy aktualizacje, o których tu mowa, i widzimy, co dzieje się potem.
Dlaczego powiadomienie o aktualizacji to nie prośba o zrobienie porządku
1. Dopiero aktualizacja bezpieczeństwa ujawnia lukę
O tym prawie nikt nie wie, a przeczy to intuicji. Dopóki luka w zabezpieczeniach tkwi nieodkryta we wtyczce, nikt o niej nie wie. W chwili, gdy programista ją zamyka i publikuje nową wersję, powstaje coś nowego: publiczne porównanie stanu „przed” i „po”. Wtyczki do WordPressa są objęte licencją GPL, ich kod źródłowy jest otwarty, a każda wersja pozostaje dostępna w katalogu. Położenie dwóch wydań obok siebie i sprawdzenie, która linia się zmieniła, to rutyna.
Publikacja aktualizacji bezpieczeństwa jest więc zarazem mapą prowadzącą do luki w starej wersji. To nie jest argument przeciwko aktualizacjom, tylko najmocniejszy argument za szybkimi aktualizacjami. Najniebezpieczniejszy okres w życiu luki nie zaczyna się w chwili jej powstania, tylko w chwili jej usunięcia. Kto zaktualizuje trzy tygodnie później, przez trzy tygodnie miał na stronie udokumentowaną podatność.
2. Nikt cię nie atakuje, ktoś cię skanuje
Najczęstsze zastrzeżenie brzmi: „Moja strona jest przecież o wiele za mała, nikt nie będzie chciał się do niej włamać”. To zakłada, że po drugiej stronie siedzi człowiek, który wybiera. Nie siedzi. Działają automatyczne skanery, które po kolei przechodzą przez listy adresów i szukają odcisków palców: ścieżek charakterystycznych tylko dla konkretnej wtyczki, informacji o wersji w publicznie dostępnych plikach, odpowiedzi, które zdradzają konkretne wydanie.
Dla takiego procesu nie ma znaczenia, czy twoja strona ma dziesięciu odwiedzających, czy dziesięć tysięcy. Liczy się nie twój zasięg, tylko serwer, skrzynka do wysyłania spamu i miejsce na przekierowania. Mała strona nie jest więc gorszym celem, a jedynie mniej rzucającym się w oczy. Nawiasem mówiąc, właśnie dlatego włamania często pozostają niezauważone przez wiele miesięcy.
3. Wtyczka to coś więcej niż kod napisany przez jej twórcę
Niemal każda większa wtyczka zawiera zewnętrzne biblioteki: do generowania plików PDF, obróbki obrazów, integracji płatności, wykresów. Znajdują się one w folderze wtyczki i są dostarczane razem z nią. Jeśli w takiej bibliotece zostanie ujawniona luka, wyłącznie od dostawcy wtyczki zależy, czy zaktualizowana wersja do ciebie dotrze. Tych zależności nie widzisz w kokpicie i nie możesz też samodzielnie ich zaktualizować.
Z perspektywy programisty to spora część naszej pracy nad aktualizacjami, której z zewnątrz w ogóle nie widać. Wydanie, które w dzienniku zmian wymienia tylko „zaktualizowane zależności”, wygląda niepozornie, a mimo to może być najważniejszym wydaniem kwartału.
4. Najniebezpieczniejsza jest wtyczka porzucona
Wtyczka, która od dwóch lat nie dostała żadnej aktualizacji, nie jest niegroźna dlatego, że nic się nie dzieje. Jest groźna, bo nic więcej już się nie wydarzy. Jeśli ktoś znajdzie w niej lukę, żadna aktualizacja już nie przyjdzie, a ty z reguły się o tym nie dowiesz.
Jak bardzo jest to powszechne, przekonaliśmy się podczas własnej analizy. Na potrzeby naszego przeglądu rynku sprawdziliśmy niemieckojęzyczne artykuły porównawcze i zweryfikowaliśmy polecane wtyczki u źródła. W jednym aktualnym artykule z dwudziestoma rekomendacjami pięć z nich było zamkniętych w katalogu WordPressa. Artykuł nadal je poleca, a kto je zainstalował, widzi na swojej liście wtyczek dokładnie to samo co wcześniej: nazwę, numer wersji, żadnego ostrzeżenia. Zamknięta wtyczka nie znika z twojej strony, po prostu przestaje dostawać aktualizacje.
Skalę tego zjawiska w całym katalogu przestaliśmy szacować, teraz ją policzyliśmy. Z raportu Plugin Directory Census 01/2026 wynika, że 58,4% spośród 70 909 wtyczek widniejących w katalogu nie miało żadnego wydania od ponad roku, a spośród 123 970 kiedykolwiek nadanych identyfikatorów (slugów) 53 061 nie figuruje już dziś w katalogu. W ujęciu ważonym liczbą instalacji jest to tylko od 3,7 do 7,8%, bo wtyczki, które są naprawdę w użyciu, są też utrzymywane. Czy twoje wtyczki są wśród nich, sprawdzisz tam po identyfikatorze.
Jak to wygląda u nas
Stoimy po drugiej stronie tego procesu, więc oto ta mniej efektowna część.
Potrzebny jest adres, na który można napisać. Kto znajdzie lukę, musi mieć możliwość jej zgłoszenia bez przechodzenia przez formularz kontaktowy, z którego wiadomości trafiają do działu sprzedaży. Utrzymujemy w tym celu osobny adres do zgłoszeń bezpieczeństwa. To nic wielkiego, ale to różnica między zgłoszeniem, które dociera, a takim, które w końcu staje się publiczne, bo nikt nie odpowiedział.
Wolimy publikować często i w małych porcjach niż rzadko i w dużych. Przykład z tego tygodnia: 17 sierpnia ukazała się nasza wersja 2.3.0, a 18 sierpnia wersja 2.3.1, bo baner zgody wyświetlał się ponownie odwiedzającym, którzy już dokonali wyboru. To nie była luka w zabezpieczeniach, tylko irytujący błąd. Mimo to taka poprawka wychodzi od razu i nie czeka na następny duży pakiet. Powód jest bardzo praktyczny: wydanie, które zmienia jedną rzecz, da się sprawdzić. W wydaniu, które zmienia osiem rzeczy, nikt już nie wskaże tej jednej zmiany, która rozsypała układ strony.
I część, o której dostawcy niechętnie piszą: aktualizacje czasem się nie udają. To nie teoria, to nasza codzienność, tak samo jak twoja. Kto twierdzi, że jego aktualizacje są wolne od ryzyka, ma albo niewielu użytkowników, albo krótką pamięć. Właściwą odpowiedzią nie jest rzadsze aktualizowanie, tylko to, żeby pojedyncza aktualizacja była mała i dało się ją odwrócić. Jeśli po aktualizacji zobaczysz na swojej stronie biały ekran (po angielsku), to jest to irytujące, ale da się to naprawić w dziesięć minut. Z włamaniem tak nie jest.
Powiedzenie „Never touch a running system” pochodzi ze świata, w którym system stał w pomieszczeniu, a drzwi były zamknięte na klucz. Twoja instalacja WordPressa stoi w internecie. Jej otoczenie zmienia się codziennie, nawet jeśli niczego nie dotykasz: wersje PHP, przeglądarki, rdzeń WordPressa i narzędzia tych, którzy szukają starych wersji. System, który się nie zmienia, nie staje się w takim otoczeniu stabilniejszy, tylko starszy.
Co zmienia akt o cyberodporności (CRA) od 11 września
Cyber Resilience Act to unijne rozporządzenie dotyczące produktów z elementami cyfrowymi, a należy do nich także oprogramowanie. Od 11 września 2026 stosuje się obowiązki zgłaszania: aktywnie wykorzystywane podatności i poważne incydenty dotyczące bezpieczeństwa trzeba zgłaszać. Pozostałe obowiązki będą stosowane etapami.
Dla producentów sprowadza się to w gruncie rzeczy do trzech kwestii, które wcześniej były dobrowolne: uporządkowanej obsługi podatności, dostarczania aktualizacji bezpieczeństwa przez wskazany okres i zapewnienia dostępnego punktu kontaktowego w tych sprawach. Kto choć raz próbował skontaktować się z autorem wtyczki, której nie aktualizowano od 2021 roku, od razu rozumie, jaki problem ma to rozwiązać.
Uczciwie trzeba dodać dwa zastrzeżenia. Po pierwsze, wciąż sporne jest właśnie to, kogo w przypadku wolnego oprogramowania open source uznaje się za producenta w rozumieniu rozporządzenia. Opisujemy to tutaj, ale nie rozstrzygamy tego za ciebie. Ten artykuł nie jest poradą prawną, a w twojej własnej sytuacji nie obejdzie się bez fachowej analizy. Po drugie: CRA nie zaktualizuje twojej strony. Zmienia to, czego możesz oczekiwać od dostawcy, a nie to, kto instaluje aktualizację. To nadal twoje zadanie, a jeśli opiekujesz się stronami klientów, staje się ono zobowiązaniem wynikającym z umowy.
W praktyce oznacza to przy wyborze wtyczki: taka, która nie podaje ani adresu do zgłoszeń bezpieczeństwa, ani okresu wsparcia, nie jest automatycznie zła. Mówi ci jednak coś o tym, ile porządku i organizacji za nią stoi, a tę informację dostaniesz odtąd bez pytania.
W praktyce: jak aktualizować, nie psując sobie strony
Kopia zapasowa, którą już raz udało ci się przywrócić. Kopia, której nigdy nie przywrócono, to nie zabezpieczenie, tylko nadzieja. Wypróbuj to raz, a będziesz wiedzieć, ile to trwa i czy w ogóle działa. Jakie narzędzia się do tego nadają, opisujemy w artykule o wtyczkach do kopii zapasowych WordPressa (po angielsku).
Automatyczne aktualizacje dla wydań bezpieczeństwa, ręczne dla całej reszty. WordPress potrafi samodzielnie aktualizować wtyczki. Dla małych wydań poprawkowych to właściwe ustawienie, bo tam najbardziej liczy się czas między publikacją a instalacją. Przy dużych skokach wersji, które wprowadzają nowe funkcje, warto samemu rzucić okiem.
Trzydzieści sekund na dziennik zmian. Jeśli jest tam „security fix”, sprawa jest pilna i nie podlega dyskusji. Jeśli jest tam nowa funkcja, której nie potrzebujesz, możesz poczekać do weekendu.
Środowisko testowe, gdy tylko strona zarabia pieniądze. Przy blogu wystarczy kopia zapasowa. Przy sklepie albo strefie członkowskiej warto najpierw zobaczyć aktualizację gdzie indziej, zanim zobaczą ją klienci.
Dwa razy w roku inwentaryzacja. Każda wtyczka, której już nie potrzebujesz, to powierzchnia ataku bez żadnej korzyści. Samo wyłączenie nie wystarczy, bo pliki nadal leżą na serwerze. Usuń ją.
Jak rozpoznać wtyczkę, która zostawi cię na lodzie
| Sygnał | Gdzie to widać | Co to oznacza |
|---|---|---|
| Ostatnia aktualizacja ponad rok temu | Strona wtyczki w katalogu | Utrzymanie wstrzymane lub mocno spowolnione |
| „Testowano do” o dwie wersje w tyle | Strona w katalogu, lista wtyczek | Dostawca nie testuje już wtyczki z aktualnymi wersjami rdzenia |
| Wątki na forum wsparcia bez odpowiedzi | Forum wsparcia na wordpress.org | Nikt już tam nie zagląda |
| Strona w katalogu nie jest już dostępna | wordpress.org, wtyczka zamknięta | Aktualizacje już nie przychodzą, a wtyczka nadal działa na twojej stronie |
| Nie da się znaleźć adresu do zgłoszeń bezpieczeństwa | Strona dostawcy, security.txt | Zgłoszenie luki prawdopodobnie nie trafi do twórcy |
| Dziennik zmian podaje tylko „różne poprawki błędów” | Dziennik zmian | Nie ocenisz, jak pilna jest aktualizacja |
Wtyczki, które wciąż są utrzymywane, kiedy ich potrzebujesz
Tworzymy nasze wtyczki w Niemczech, publikujemy małe poprawki od razu zamiast zbiorczo i prowadzimy osobny adres do zgłoszeń bezpieczeństwa. Każda wersja Free pozostaje na stałe bezpłatna, a płatne plany znajdziesz na stronie z cennikiem.
Najczęściej zadawane pytania
Czy naprawdę muszę od razu instalować każdą aktualizację wtyczki?
W przypadku aktualizacji bezpieczeństwa tak, i to z konkretnego powodu: wraz z publikacją luka w starej wersji staje się łatwa do namierzenia, bo obie wersje da się porównać. Przy aktualizacjach z nowymi funkcjami możesz się nie spieszyć, do oceny wystarczy rzut oka na dziennik zmian. Zasada jest prosta: „security fix” od razu, wszystko inne na spokojnie.
Co zrobić, gdy aktualizacja zepsuje mi stronę?
Przywróć kopię zapasową albo zmień przez FTP nazwę folderu wtyczki, której dotyczy problem, a WordPress przy następnym wczytaniu strony sam ją wyłączy. Następnie zgłoś problem dostawcy, bo jeśli dotyczy ciebie, dotyczy też innych. Dlatego obowiązuje zasada: najpierw sprawdź kopię zapasową, potem aktualizuj, a nie odwrotnie.
Po czym poznać, że wtyczka została porzucona?
Na stronie wtyczki w katalogu znajdziesz datę ostatniej aktualizacji, wersję WordPressa, z którą ją przetestowano, i forum wsparcia. Rok bez aktualizacji, wątki bez odpowiedzi i nieaktualna wartość w polu „Testowano do” to razem wyraźny sygnał. Najpoważniejszy przypadek to strona w katalogu, która w ogóle nie jest już dostępna: wtedy wtyczka jest zamknięta, aktualizacje już nie przychodzą, a na twojej stronie i tak nadal działa.
Czy Cyber Resilience Act dotyczy mnie jako właściciela strony?
Obowiązki wynikające z rozporządzenia są skierowane do producentów, importerów i dystrybutorów produktów z elementami cyfrowymi, a nie do ciebie jako użytkownika wtyczki. W praktyce zmienia się dla ciebie przede wszystkim wybór: kontakt w sprawach bezpieczeństwa i wskazany okres wsparcia stają się tym, czego oczekuje się od dostawcy. Kto jednak opiekuje się stronami na zlecenie klientów, powinien poprosić specjalistę o wyjaśnienie swojej roli. Ten artykuł nie jest poradą prawną.
Czy automatyczne aktualizacje są niebezpieczne?
To coś za coś. Oddajesz kontrolę nad momentem aktualizacji, a zyskujesz szybkość dokładnie tam, gdzie szybkość się liczy. Przy wydaniach poprawkowych to prawie zawsze lepszy interes, bo ryzykowny okres po publikacji pozostaje krótki. Przy dużych skokach wersji na stronie, która zarabia pieniądze, rozsądniejsza jest droga ręczna ze środowiskiem testowym.
