Weryfikacja sum kontrolnych WordPressa: zmodyfikowane pliki

Gdy podejrzewasz włamanie, weryfikacja sum kontrolnych to użyteczna wstępna kontrola, ale nie może opóźniać izolowania incydentu ani zabezpieczania dowodów. Jedno polecenie pokazuje, czy pliki rdzenia są co do bajta identyczne z oficjalnym wydaniem. Pliki objęte oficjalną listą sum kontrolnych powinny odpowiadać dokładnie Twojej wersji i wersji językowej. Pliki specyficzne dla witryny, takie jak wp-config.php, w tym porównaniu nie występują. Każda różnica to albo zmiana lokalna, o której wiesz, albo coś, co trzeba zbadać jeszcze dziś.

Dlaczego pliki rdzenia WordPressa zmieniają się po włamaniu

Rdzeń to dobra kryjówka, bo nikt go nie czyta. Właściciele stron zaglądają do ustawień motywu i wtyczek. Prawie nikt nie otwiera wp-includes/load.php ani nie liczy plików w wp-admin/includes. Atakujący może ukryć kod w regularnie ładowanym pliku rdzenia albo dorzucić wiarygodnie wyglądający plik, który posłuży mu do późniejszego dostępu. Sam fakt, że dodany plik leży w katalogu rdzenia, nie oznacza jeszcze, że zostanie wykonany.

Sumy kontrolne zamieniają „wygląda w porządku” w porównanie, które można udowodnić. WordPress.org publikuje skrót MD5 każdego pliku rdzenia w każdym wydaniu. Porównujesz swoje pliki z tą listą.

Nie trać jednak z oczu przyczyny. State of WordPress Security in 2026 firmy Patchstack to raport dostawcy. W 2025 roku naliczył on w rdzeniu WordPressa tylko 6 podatności, wszystkie o niskim priorytecie. Ta liczba nie mówi, którędy atakujący wszedł na Twoją stronę. Zmodyfikowane pliki rdzenia mogą być skutkiem włamania przez wtyczkę, motyw lub przejęte dane logowania. Wymiana rdzenia naprawia te pliki, ale punkt wejścia nadal trzeba znaleźć i zamknąć.

Jak zweryfikować sumy kontrolne WordPressa przez WP-CLI

Połącz się przez SSH i uruchom polecenie z katalogu głównego WordPressa:

cd /var/www/example.com
wp core verify-checksums

Jeśli jesteś w innym katalogu, dodaj --path=/var/www/example.com. Uruchamiaj polecenie jako użytkownik będący właścicielem plików witryny, nie jako root. WP-CLI odmawia pracy jako root, chyba że dodasz --allow-root, i to rozsądne ustawienie domyślne. Uruchomiony jako root złośliwy kod ładowany przez WordPressa też działałby z uprawnieniami roota.

Domyślnie WP-CLI odczytuje wersję z wp-includes/version.php. Na przejętej stronie ten plik też mógł zostać zmieniony. Jeśli wiesz, którą wersję zainstalowano, podaj ją jawnie. W instalacjach nieangielskojęzycznych ustaw dodatkowo język (dla polskiej instalacji będzie to pl_PL):

wp core verify-checksums --version=6.8.3 --locale=de_DE

Użyj własnego numeru wersji. Na czystej stronie zobaczysz jedną linię:

Success: WordPress installation verifies against checksums.

Na stronie z problemem pojawią się ostrzeżenia w rodzaju:

Warning: File doesn't verify against checksum: wp-includes/functions.php
Warning: File should not exist: wp-includes/class-wp-cache-handler.php
Error: WordPress installation doesn't verify against checksums.

Jak czytać wyniki: pliki zmodyfikowane a dodatkowe

Oba typy ostrzeżeń znaczą co innego i wymagają innego postępowania.

Zmodyfikowany plik traktuj poważnie, chyba że znasz legalną lokalną łatkę. Takie łatki zdarzają się rzadko, a ten, kto ją wprowadził, powinien ją udokumentować.

Dodatkowy plik to przypadek mniej oczywisty. Niektóre aktualizacje zostawiają pliki ze starszych wersji, więc sam dodatkowy plik nie dowodzi obecności malware. Plik PHP o przypadkowej nazwie w wp-includes jest podejrzany, dopóki go nie przeczytasz. Tak samo plik, którego nazwa tylko brzmi jak komponent rdzenia.

Dodatkowe pliki mogą być zgłaszane jako ostrzeżenia, bez przerywania polecenia błędem. Zdarza się więc, że po liniach File should not exist widać na końcu Success. Przeczytaj każde ostrzeżenie, zamiast polegać na ostatniej linii.

Domyślnie kontrola dodatkowych plików obejmuje wp-admin i wp-includes. Niektóre wersje WP-CLI potrafią sprawdzić także katalog główny. Uruchom wp help core verify-checksums, żeby zobaczyć, czy Twoja wersja oferuje --include-root.

Bez WP-CLI? Użyj API sum kontrolnych WordPress.org

Niektórzy dostawcy hostingu dają SSH, ale nie WP-CLI. Wtedy odpytaj bezpośrednio API sum kontrolnych i pozwól md5sum porównać pliki. Potrzebujesz curl i jq:

cd /var/www/example.com
VER=6.8.3        # dokładna wersja WordPressa
LOC=en_US        # albo de_DE, fr_FR, ...
(
  set -e
  WORK=$(mktemp -d)
  trap 'rm -rf -- "$WORK"' EXIT
  curl -fsS "https://api.wordpress.org/core/checksums/1.0/?version=$VER&locale=$LOC" \
    -o "$WORK/response.json"
  jq -er '.checksums | select(type == "object" and length > 0) | to_entries[] | select(.key | startswith("wp-content/") | not) | "\(.value)  \(.key)"' \
    "$WORK/response.json" > "$WORK/core.md5"
  test -s "$WORK/core.md5"
  md5sum -c --quiet "$WORK/core.md5"
)

Filtr select pomija dołączone motywy i wtyczki w wp-content, które mogły zostać usunięte celowo. Z opcją --quiet md5sum wypisuje tylko pliki, które nie przeszły weryfikacji.

Brak wyjścia i zerowy kod zakończenia oznaczają, że pliki z przefiltrowanej listy sum kontrolnych są zgodne. Błąd pobierania, parsowania lub weryfikacji nie jest wynikiem czystym. Podpowłoka używa prywatnego katalogu tymczasowego i zatrzymuje się, gdy któryś wcześniejszy krok się nie powiedzie.

Ta metoda nie wykrywa dodatkowych plików. Aby je znaleźć, pobierz to samo wydanie, na przykład https://wordpress.org/wordpress-6.8.3.zip. Dla instalacji nieangielskojęzycznych użyj paczki z odpowiedniej wersji językowej witryny WordPress.org. Rozpakuj archiwum i porównaj katalogi:

diff -rq wordpress/wp-includes /var/www/example.com/wp-includes
diff -rq wordpress/wp-admin /var/www/example.com/wp-admin

Linie Only in /var/www/... wskazują dodatkowe pliki w instalacji. Linie Only in wordpress/... wskazują pliki, których w instalacji brakuje. Linie Files ... differ wskazują różnice w zawartości. Obejrzyj też nieoczekiwane katalogi.

Wtyczki i motywy: gdzie sumy kontrolne przestają działać

WP-CLI potrafi sprawdzić także wtyczki:

wp plugin verify-checksums --all

Działa to tylko dla wtyczek z repozytorium WordPress.org, bo tylko dla nich publikowane są sumy kontrolne. Wtyczek bez odpowiadającego zestawu sum w WordPress.org w ten sposób nie sprawdzisz.

Jeśli „nulled” lub zmanipulowana kopia zachowuje slug i wersję wtyczki z WordPress.org, polecenie nadal może ją porównać i oznaczy zmienione pliki. WP-CLI nie ma analogicznego wbudowanego polecenia dla motywów.

W przypadku pozostałych wtyczek i motywów pobierz dokładnie tę wersję, która jest zainstalowana, z oficjalnego źródła lub zaufanego archiwum buildów. Dla kodu pisanego na zamówienie użyj sprawdzonego artefaktu wydania, a nie kopii wziętej z podejrzanej strony. Następnie porównaj ją z zainstalowaną kopią:

diff -rq ~/clean/some-premium-plugin wp-content/plugins/some-premium-plugin

Poszukaj też folderów wtyczek, których nie umiesz powiązać z niczym, co instalowano. Nieznany folder w wp-content/plugins to sygnał alarmowy. Wtyczka typu „nulled” jest problemem sama w sobie, niezależnie od wyniku diff. O wymianie takich i porzuconych wtyczek mówi poradnik o podatnościach wtyczek.

Bezpieczna ponowna instalacja rdzenia WordPressa

Najpierw zabezpiecz dowody i zrób pełną kopię zapasową. Potem zastąp rdzeń czystą kopią tej samej wersji:

wp core download --force --skip-content --version=6.8.3

W razie potrzeby dodaj --locale=pl_PL lub kod innego języka. Polecenie nadpisuje pliki rdzenia. Nie rusza wp-config.php, bo w paczce takiego pliku nie ma. --skip-content zostawia wp-content bez zmian.

Polecenie nie usuwa dodatkowych plików. Plik taki jak wp-includes/class-wp-cache-handler.php zostaje na miejscu, bo pobieranie zapisuje wyłącznie pliki oficjalne. Każdy dodatkowy plik najpierw skopiuj i przejrzyj. Potem usuń te, które są złośliwe albo których zbędność potwierdzono. Uruchom wp core verify-checksums ponownie i upewnij się, że nie zostały żadne niewyjaśnione ostrzeżenia.

Czego czysty wynik sum kontrolnych nie mówi

Zielony wynik dotyczy wyłącznie rdzenia WordPressa. Nie mówi nic o:

• wp-content: motywach, wtyczkach premium i własnych, mu-plugins oraz uploads
• wp-config.php i .htaccess, których nie ma na liście sum kontrolnych
• bazie danych: wstrzykniętych opcjach, spamie we wpisach, nieznanych kontach administratorów, zaplanowanych zdarzeniach crona
• plikach poza WordPressem, takich jak inne pliki PHP na koncie hostingowym czy konfiguracja na poziomie serwera

Atakujący wiedzą, które pliki są sprawdzane. To jeden z powodów, dla których wp-content/uploads jest ulubionym miejscem web shelli. Pozostałe kontrole znajdziesz w artykule o oznakach zhakowanej strony. Do katalogu uploads przyda się poradnik o web shellach.

Stałe monitorowanie integralności plików

Jednorazowa kontrola pomaga podczas incydentu. Kontrola cykliczna może skrócić czas, w którym modyfikacja pozostaje niezauważona, choć zmiany mogą dotknąć odwiedzających jeszcze przed kolejnym uruchomieniem. Wystarczy mały skrypt uruchamiany z crona:

#!/bin/bash
cd /var/www/example.com || exit 1
OUT=$(/usr/local/bin/wp core verify-checksums 2>&1)
if [ $? -ne 0 ] || echo "$OUT" | grep -q "Warning:"; then
  echo "$OUT" | mail -s "Core checksum alert: example.com" admin@example.com
fi

Zainstaluj go w crontabie właściciela witryny, nie roota. Skrypt alarmuje przy niezerowym kodzie zakończenia i przy każdym ostrzeżeniu, także o zgłoszonych dodatkowych plikach. Ustaw znaną zmienną PATH albo używaj pełnych ścieżek do programów, bo cron działa w ograniczonym środowisku. Sprawdź, czy alert faktycznie dociera; w razie potrzeby zamień mail na działający system powiadomień.

Dla wp-content prowadź własny punkt odniesienia po każdej aktualizacji, o której wiesz, że jest poprawna:

find wp-content/plugins wp-content/themes -type f -exec sha256sum {} + > ~/baseline-$(date +%F).sha256

Przechowuj ten plik poza katalogiem głównym serwera WWW, najlepiej poza samym serwerem. Aby sprawdzić zmiany, uruchom z katalogu głównego witryny sha256sum -c --quiet na pliku bazowym. Wychwyci to pliki zmodyfikowane i usunięte, ale nie nowe. Nowe pliki znajdziesz, porównując świeżą listę z find z listą zapisaną w pliku bazowym. Po każdej legalnej aktualizacji utwórz nowy punkt odniesienia, inaczej następna kontrola oznaczy Twoje własne zmiany.

Regularne kontrole wspierają też zgodność z przepisami. RODO art. 32 ust. 1 lit. d wymaga procesu regularnego testowania, mierzenia i oceniania skuteczności środków bezpieczeństwa. Cykliczna kontrola integralności z zapisanymi wynikami to konkretny dowód takiego procesu. Szerszy obraz daje artykuł art. 32 RODO a WordPress.

Jeśli nie chcesz utrzymywać skryptów, wtyczka Security Audit & Compliance z secaudit.eu prowadzi punkt odniesienia integralności plików i raportuje zmienione pliki oraz zaciemnioną zawartość. Uruchamia też weryfikację sum kontrolnych rdzenia. Wykrywa i raportuje. Sprzątanie pozostaje zadaniem Twoim lub Twojej agencji.

FAQ

Czy verify-checksums działa w multisite i w instalacjach nieangielskojęzycznych?

Tak. Sieć multisite korzysta z jednego zestawu plików rdzenia, więc jedno uruchomienie obejmuje całą sieć. W instalacjach nieangielskojęzycznych podaj właściwy --locale, bo spolszczone paczki mogą różnić się od en_US.

Czy ostrzeżenie „File should not exist” zawsze oznacza malware?

Nie. Wywołują je także pliki pozostawione przez starsze wersje WordPressa. Zachowaj kopię i obejrzyj plik. Usuń go, jeśli jest złośliwy lub potwierdzono, że jest zbędny. Niewyjaśniony kod PHP w katalogu rdzenia zawsze wymaga dokładnego przejrzenia.

Jak często to uruchamiać?

Dla większości firmowych stron rozsądne jest uruchamianie codziennie z crona. Uruchom też po incydencie, po każdej aktualizacji rdzenia i za każdym razem, gdy ktoś nowy dostaje dostęp do serwera.

Czy atakujący może sfałszować wynik sum kontrolnych?

Same sumy kontrolne pochodzą z WordPress.org przez HTTPS. Atakujący, który kontroluje Twój serwer, mógłby jednak zmanipulować lokalne narzędzia, na przykład plik WP-CLI albo binaria systemowe. W razie wątpliwości skopiuj pliki witryny na czystą maszynę i porównaj je tam ze świeżo pobranym tym samym wydaniem.