aktualizacja rdzenia WordPressa

Aktualizacja rdzenia WordPressa to wymiana plików samego oprogramowania WordPress na nowszą wersję, niezależna od aktualizacji wtyczek i motywów. Wydania bezpieczeństwa rdzenia usuwają konkretne, zgłoszone podatności: zespół bezpieczeństwa WordPressa przygotowuje poprawki i publikuje je w wydaniach poprawkowych ^[2]. Podręcznik utwardzania WordPressa zaleca, żeby zawsze używać najnowszej wersji ^[8]. CERT Polska wymienia utrzymywanie aktualnych wersji systemu CMS, wtyczek, motywów i oprogramowania serwera wśród zaleceń po przejęciu strony ^[7].

Jak działa

Dokumentacja rozróżnia aktualizacje główne (major) i drobne (minor) rdzenia ^[1]. Wydanie główne zmienia jedną z dwóch pierwszych liczb wersji, na przykład z 7.0 na 7.1, i wnosi nowe funkcje. Wydanie drobne zmienia trzecią liczbę, na przykład z 7.1.1 na 7.1.2, i zawiera poprawki; takim wydaniem bezpieczeństwa był WordPress 7.1.2 ^[3].

Aktualizację można uruchomić z kokpitu w sekcji Kokpit → Aktualizacje przyciskiem „Zaktualizuj teraz”; metoda działa na większości serwerów, choć problemy z uprawnieniami plików mogą ją zablokować ^[1]. Przy aktualizacji ręcznej zostawia się plik wp-config.php i katalog wp-content, a pozostałe pliki rdzenia zastępuje nowymi ^[1]. Przed rozpoczęciem dokumentacja zaleca wykonanie kopii zapasowej (backup), żeby w razie problemów móc przywrócić stronę ^[1].

Bezpieczną kolejność pokazuje schemat poniżej.

RYS. 1Aktualizacja rdzenia krok po kroku

Rodzaje

Automatyczne aktualizacje w tle wprowadzono w WordPressie 3.7 ^[1]. Od wersji 5.6 nowe instalacje domyślnie otrzymują automatycznie zarówno drobne, jak i główne aktualizacje rdzenia ^[1]. Zachowanie można zmienić stałą WP_AUTO_UPDATE_CORE w pliku wp-config.php ^[1].

// wp-config.php: automatycznie tylko wydania drobne, w tym bezpieczeństwa
define( 'WP_AUTO_UPDATE_CORE', 'minor' );

Wyłączenie aktualizacji drobnych odbiera stronie najszybszą drogę dostarczania łatek bezpieczeństwa.

W WordPressie

WordPress napędza według jego twórców ponad 43% stron internetowych, a w zespole bezpieczeństwa działa ponad 50 zaufanych ekspertów, w tym główni programiści i badacze bezpieczeństwa ^[2]. Oficjalnie wspierana jest tylko najnowsza wersja WordPressa ^[2]. Zespół bezpieczeństwa przenosi jednak poprawki do starszych gałęzi, żeby starsze strony otrzymały krytyczne łatki (patch) przez automatyczne aktualizacje; robi to z uprzejmości, nie z obowiązku ^[2]. W czerwcu 2025 roku ogłoszono, że od lipca 2025 roku wersje 4.1–4.6 nie będą już otrzymywać aktualizacji bezpieczeństwa ^[4]. Według ogłoszenia ponad 99% instalacji używało wtedy nowszych wersji ^[4].

Aktualny rdzeń nie chroni przed błędami dodatków. Większość znanych luk dotyczy wtyczek i motywów, stąd hasła podatność we wtyczce i podatność w motywie, a wtyczki aktualizuje się osobno. Rdzeń bywa jednak celem sam w sobie, co pokazują przykłady w ostatniej sekcji. Aktualizacja rdzenia nie usuwa też skutków wcześniejszego włamania: tylna furtka (backdoor) w katalogu wp-content przetrwa wymianę plików rdzenia, bo ten katalog przy aktualizacji zostaje nietknięty ^[1].

Znaczenie

Wydanie bezpieczeństwa jest publiczne, więc po jego ukazaniu się atakujący mogą porównać kod starej i nowej wersji. Dlatego przy WordPressie 4.7.2 zespół odłożył ujawnienie jednej z poprawek o tydzień, żeby aktualizacje dotarły do stron, zanim atakujący poznają szczegóły ^[5]. Ogłoszenie WordPressa 7.1.2 zalecało natychmiastową aktualizację, bo było to wydanie bezpieczeństwa ^[3]. Strona na starej wersji staje się łatwym celem, a ujawnianie wersji ułatwia atakującym jej znalezienie.

Automatyczne aktualizacje skracają ten czas do godzin. Przy WordPressie 4.7.2 zespół podał, że w ciągu kilku godzin od wydania miliony stron z wersją 4.7.x otrzymały poprawkę automatycznie ^[5].

Dobre praktyki

• Zostawić włączone automatyczne aktualizacje co najmniej dla wydań drobnych ^[1].
• Przed wydaniem głównym zrobić kopię zapasową ^[1] i sprawdzić zgodność wtyczek w środowisku testowym (staging).
• Przy aktualizacji ręcznej zachować własne pliki .htaccess i robots.txt oraz wyłączyć wtyczki przed aktualizacją, a po niej włączyć je ponownie ^[1].
• Nie modyfikować plików rdzenia; dokumentacja zastrzega, że pozostawianie zmienionego starego kodu zwykle prowadzi do problemów ze zgodnością ^[1].
• Włączyć aktualizację rdzenia w szerszy proces zarządzania poprawkami (patch management) i śledzić biuletyny bezpieczeństwa.
• Po przejęciu strony zaktualizować rdzeń dopiero po oczyszczeniu, zgodnie ze ścieżką czyszczenia przejętej strony ^[7].

Historia i przykłady

WordPress 4.7.2 (2017). 20 stycznia 2017 roku firma Sucuri zgłosiła podatność eskalacji uprawnień bez uwierzytelnienia w punkcie końcowym REST API w wersjach 4.7 i 4.7.1 ^[5]. Poprawka ukazała się 26 stycznia, a opis luki zespół opublikował 1 lutego, celowo z tygodniowym opóźnieniem, żeby automatyczne aktualizacje zdążyły dotrzeć do milionów stron ^[5]. Luka pozwalała na podmianę treści (defacement) wpisów ^[6]. Sekurak 7 lutego 2017 roku opisał kampanię, w której według Sucuri zainfekowanych było około 66 tysięcy stron, także w Polsce, i zalecał aktualizację co najmniej do wersji 4.7.2 ^[6].

WordPress 7.1.2 (2026). Wydanie z 22 września 2026 roku usuwało jedną krytyczną podatność ^[3]. Atakujący bez uwierzytelnienia mógł, przy określonych warunkach serwera i motywu, doprowadzić do zdalnego wykonania kodu (RCE) przez dołączenie lokalnych plików PHP spoza katalogu aktywnego motywu, co przypomina LFI ^[3]. Poprawkę przeniesiono do wszystkich uprawnionych gałęzi, wtedy od wersji 4.7 wzwyż, a strony z automatycznymi aktualizacjami w tle miały zaktualizować się same ^[3].