Automatyczna aktualizacja wtyczki położyła stronę w pięć minut: analiza i zabezpieczenia

O 18:06 WordPress na obsługiwanej przez nas stronie sam zaktualizował wtyczkę. O 18:11 strona przestała się otwierać. Nikt niczego nie klikał, nikt nie wchodził do panelu administracyjnego, nie było ani włamania, ani awarii hostingu. System po prostu zrobił to, do czego został skonfigurowany lata temu, i zrobił to bez zarzutu.

Ta analiza dotyczy tego, dlaczego automatyczna aktualizacja, która miała chronić stronę, czasem ją kładzie, i co zrobić, żeby to nie spotkało Państwa. Bez teorii: wszystko poniżej to chronologia jednego wieczoru i jednego następnego poranka.

Chronologia: pięć minut od aktualizacji do martwej strony

18:06. WordPress uruchamia zaplanowaną automatyczną aktualizację wtyczki Elementor — konstruktora, na którym zbudowane są wszystkie strony serwisu. Na stronie stała wersja 3.6.5, wydana jeszcze w 2022 roku. Aktualizacja instaluje od razu 4.3.5, przeskakując kilka lat zmian.

18:11. Strona główna zwraca błąd. Odwiedzający widzą biały ekran zamiast strony. Edytor w panelu administracyjnym nie może ani otworzyć strony, ani jej zapisać.

18:14. Do grupy roboczej przychodzi wiadomość: „strona się nie zapisuje”. O tym, że cała strona leży, nikt jeszcze nie wie.

19:25. Strona działa. Między tymi dwoma punktami jest godzina analizy i to właśnie ona jest interesująca.

Dlaczego do tego doszło: trzy przyczyny, które złożyły się w jedną

1. Wersja wtyczki z 2022 roku

Automatyczna aktualizacja nie aktualizowała tej wtyczki od czterech lat — a potem zadziałała. Dlaczego akurat tego wieczoru, nie ma znaczenia: ważne, że skok z wersji 3.6 na 4.3 to nie „łatka”, lecz zmiana pokolenia. Deweloper w tym czasie usunął część starego kodu, który uznał za przestarzały. To normalna praktyka — ale tylko dla tych, którzy aktualizują się regularnie i zauważają ostrzeżenia po drodze.

2. Motyw strony opierał się na tym samym starym kodzie

Motyw graficzny też pochodzi z 2022 roku i też nie był aktualizowany. W ośmiu jego blokach używano funkcji, które w nowym Elementorze zniknęły. Motyw wywołuje funkcję — funkcji nie ma — PHP zatrzymuje wykonywanie. Dla odwiedzającego wygląda to jak pusta strona z błędem.

3. Sąsiednia wtyczka zgubiła ustawienia

Na stronie działała jeszcze jedna wtyczka, która ukrywa standardowe adresy WordPressa przed robotami i skanerami. Podczas aktualizacji zgubiła regułę podmiany adresów właśnie dla plików Elementora. Dlatego nawet tam, gdzie motyw się nie psuł, edytor nie mógł załadować własnych plików: serwer odpowiadał „nie znaleziono”.

Automatyczna aktualizacja nie wie, że Państwa motyw pochodzi z 2022 roku, że obok działa wtyczka przechwytująca adresy i że na tej stronie nikt nie aktualizował się od czterech lat. Wie tylko jedno: jest nowa wersja i trzeba ją zainstalować.

Jak to naprawiono

• Przywrócono wtyczkę do wersji 3.6.5 — tej, która działała rano. Nowej nie usunięto, tylko odłożono: wrócić do niej można w minutę, gdy motyw będzie gotowy.
• Odtworzono zgubioną regułę we wtyczce, która ukrywa adresy.
• Wyłączono automatyczne aktualizacje właśnie dla Elementora. Inaczej w nocy wszystko by się powtórzyło — WordPress nie pamięta, że ostatnim razem zrobiło się gorzej.
• Sprawdzono stronę główną i podstrony — otwierają się, błędów nie ma, wygląd na miejscu.

I osobno powiedziano właścicielowi uczciwie: wersja 3.6.5 ma cztery lata, nie warto trzymać jej długo. W starych wersjach z czasem znajduje się podatności i wtedy brak aktualizacji staje się niebezpieczny. Najnowsza wersja zgodna z tym motywem to 3.25. Ale i motyw jest z 2022 roku: prędzej czy później znów się o to potknie. Właściwa droga — zrobić kopię strony i tam spokojnie sprawdzić aktualizację, bez ryzyka dla wersji produkcyjnej.

Drugi dzwonek następnego ranka

O 9:49 nowa wiadomość: „błąd 503” przy zapisie strony. Na pierwszy rzut oka — ciąg dalszy wczorajszego. W rzeczywistości — inna historia, i ona też jest pouczająca.

Serwer nie odmawiał. Podczas zapisu padał sam proces PHP, a przeglądarka pokazywała to jako 503. Strona okazała się bardzo ciężka: 226 bloków, w tym 111 obrazów. A limity PHP na stronie były najmniejsze, fabryczne dla hostingu: 128 MB pamięci i 30 sekund na żądanie. Konstruktor do normalnej pracy wymaga co najmniej 256 MB i 300 sekund. Strona latami działała na granicy — i na najcięższej podstronie ta granica się skończyła.

Podniesiono limity, zrestartowano PHP — nie pomogło. Dziennik pokazał: pamięć i czas nie mają tu nic do rzeczy, proces ginie na samym zapisie. Przyczyną okazało się jedno z ustawień przyspieszania PHP, znany problem w tej wersji. Wyłączono je — zadziałało.

Lekcja jest prosta: awaria rzadko ma jedną przyczynę. Wczorajsza aktualizacja nie miała tu nic do rzeczy, ale strona, która latami żyje na minimalnych limitach, prędzej czy później zepsuje się na czymś innym.

Co robić właścicielowi strony

1. Proszę ustalić, co u Państwa aktualizuje się samo. W panelu WordPress: „Wtyczki” → kolumna „Automatyczne aktualizacje”. To samo dla motywów. Jeśli nie znają Państwo odpowiedzi — to już pierwszy problem.
2. Proszę rozdzielić aktualizacje na „bezpieczeństwa” i „duże”. Drobne poprawki wewnątrz wersji (3.25.10 → 3.25.11) można zostawić automatyczne. Przejście między dużymi wersjami (3 → 4) — tylko ręcznie i tylko po sprawdzeniu.
3. Proszę sprawdzać duże aktualizacje na kopii. Hostingi zazwyczaj dają kopię testową strony jednym kliknięciem. Zaktualizowano tam, sprawdzono, że nic się nie rozsypało — wtedy aktualizuje się wersję produkcyjną.
4. Proszę robić kopię przed każdą aktualizacją. Nie „backup jest na hostingu”, lecz kopię, z której osobiście wiedzą Państwo, jak odtworzyć stronę w dziesięć minut.
5. Proszę nie trzymać wersji sprzed czterech lat. Im dłużej się nie aktualizują, tym boleśniejszy będzie skok i tym więcej podatności się nagromadzi. Planowa aktualizacja raz w miesiącu jest tańsza niż jedna noc bez strony.
6. Proszę mieć kogoś, kto zauważy awarię w pięć minut. Strona leżała od 18:11, a wiadomość przyszła o 18:14 — i to nie o stronie, tylko o edytorze. Bez monitoringu właściciel dowiaduje się o martwej stronie od klienta, który nie mógł złożyć zamówienia.

Paradoks: nie aktualizować się też jest niebezpiecznie

Może się wydawać, że wniosek brzmi „wyłączyć automatyczne aktualizacje i żyć spokojnie”. Nie. Niedawno pisaliśmy o krytycznych podatnościach PHP, gdzie jedyną ochroną jest właśnie aktualizacja i nie można jej odkładać. Tam zwłoka kosztuje włamanie na serwer. Tu pośpiech kosztował wieczór bez strony.

Różnica jest jedna: aktualizacje bezpieczeństwa trzeba instalować szybko i wszystkie, a funkcjonalne — świadomie i po sprawdzeniu. Automatyczna aktualizacja tej różnicy nie widzi. Musi ją widzieć człowiek.

---

Nie są Państwo pewni, co u Państwa aktualizuje się samo i co stanie się po następnej aktualizacji? Proszę napisać do nas — przyjrzymy się Państwa stronie i powiemy wprost, gdzie jest na granicy.