Okiem informatyka ds. cyberbezpieczeństwa – gdzie naprawdę znajdują się słabe punkty WordPressa?

WordPress 7.1 „Mary Lou” został wydany 19 sierpnia 2026 roku. To kolejna duża wersja systemu CMS, która oprócz zmian funkcjonalnych i developerskich powinna być analizowana również pod kątem bezpieczeństwa całego stosu: WordPress + PHP + baza danych + serwer WWW + wtyczki + motyw + system operacyjny.

Samo zainstalowanie najnowszego WordPressa nie oznacza jeszcze bezpiecznej strony.

W praktyce bezpieczeństwo WordPressa jest sumą kilku warstw:

Core + PHP + serwer WWW + system plików + baza danych + konta użytkowników + pluginy + motyw + konfiguracja + monitoring + backup

WordPress w swojej oficjalnej dokumentacji wskazuje aktualizacje Core, wtyczek i motywów jako jeden z najważniejszych elementów bezpieczeństwa. (WordPress Developer Resources)

---

1. WordPress 7.1 – podstawowa specyfikacja bezpieczeństwa

Element	WordPress 7.1	Znaczenie dla bezpieczeństwa
Typ systemu	CMS / PHP	Duża powierzchnia ataku aplikacyjnego
Backend	PHP	Bezpieczeństwo zależne również od wersji PHP
Baza danych	MySQL / MariaDB	Ryzyko SQL injection i przejęcia danych
Web server	Apache / Nginx / inne	Konfiguracja serwera ma bezpośredni wpływ na bezpieczeństwo
Core	WordPress 7.1	Powinien być utrzymywany w aktualnej wersji
Pluginy	zewnętrzne komponenty	Jeden z największych wektorów ataku
Motyw	zewnętrzny lub własny	Może zawierać podatny kod PHP/JS
Uploads	wp-content/uploads	Szczególnie istotny obszar do kontroli
Panel administracyjny	/wp-admin/	Cel ataków brute-force i credential stuffing
API	REST API / inne mechanizmy	Wymaga kontroli uprawnień i ekspozycji danych
XML-RPC	xmlrpc.php	Potencjalny punkt ataku zależnie od konfiguracji
HTTPS	TLS	Powinien być standardem
2FA	zależne od konfiguracji	Silna dodatkowa warstwa ochrony
WAF	opcjonalny	Ochrona przed częścią ruchu atakującego
Monitoring	opcjonalny	Pozwala wykrywać modyfikacje i anomalie

---

2. Struktura plików WordPressa

Z punktu widzenia bezpieczeństwa podstawowa struktura wygląda następująco:

/
├── wp-admin/
├── wp-content/
│   ├── plugins/
│   ├── themes/
│   ├── uploads/
│   └── cache/
├── wp-includes/
├── wp-config.php
├── .htaccess
├── index.php
├── wp-login.php
├── wp-cron.php
├── xmlrpc.php
├── wp-load.php
├── wp-settings.php
└── wp-blog-header.php

Każdy z tych elementów ma inną funkcję i inny profil ryzyka.

---

3. wp-admin/ – panel administracyjny

wp-admin zawiera mechanizmy administracyjne WordPressa.

To jeden z najbardziej interesujących celów dla atakującego.

Atakujący może próbować:

• brute-force,
• credential stuffing,
• phishingu,
• wykorzystania skradzionych sesji,
• wykorzystania podatności pluginów,
• eskalacji uprawnień,
• przejęcia konta administratora.

Dlatego administrator powinien rozważyć:

• silne hasła,
• 2FA,
• ograniczenie dostępu do panelu,
• monitoring logowania,
• ochronę WAF,
• ograniczenie liczby prób logowania,
• usunięcie nieużywanych kont.

---

4. wp-includes/ – rdzeń aplikacji

wp-includes zawiera dużą część logiki Core WordPressa.

To katalog, którego nie powinno się traktować jak zwykłego katalogu uploadowego.

Oficjalna dokumentacja WordPressa opisuje możliwość dodatkowego ograniczenia dostępu HTTP do części skryptów znajdujących się w wp-includes. (WordPress Developer Resources)

Najważniejsza zasada:

Nie modyfikuj plików Core bez konkretnego powodu.

Jeżeli WordPress Core wymaga ręcznej modyfikacji, powinno to być sygnałem ostrzegawczym z punktu widzenia utrzymania i aktualizacji systemu.

---

5. wp-content/ – najbardziej interesujący obszar

Z perspektywy security jest to jeden z najważniejszych katalogów całej instalacji.

Znajdziemy tutaj:

wp-content/
├── plugins/
├── themes/
├── uploads/
└── cache/

To tutaj trafiają:

• pluginy,
• motywy,
• multimedia,
• pliki generowane przez aplikację,
• cache,
• dane dodatkowych komponentów.

Dlaczego jest to ważne?

Ponieważ wp-content jest obszarem, w którym aplikacja oraz użytkownik mają znacznie większą możliwość zapisu danych.

Jeżeli atakujący uzyska możliwość uploadu złośliwego pliku, modyfikacji pluginu albo zapisu kodu PHP, konsekwencje mogą być bardzo poważne.

---

6. wp-content/plugins/

Pluginy są jednym z największych elementów ryzyka w WordPressie.

Nie oznacza to, że pluginy są „niebezpieczne”.

Problem polega na tym, że każdy dodatkowy komponent:

zwiększa powierzchnię ataku.

Plugin może posiadać:

• własne endpointy,
• REST API,
• AJAX,
• formularze,
• uploadery,
• integracje z zewnętrznymi API,
• własne mechanizmy autoryzacji,
• kod wykonujący operacje na bazie danych.

Dlatego bezpieczniejsza instalacja powinna zawierać tylko pluginy rzeczywiście potrzebne.

WordPress zaleca aktualizowanie pluginów oraz usuwanie tych, które nie są używane. (WordPress Developer Resources)

---

7. wp-content/themes/

Motyw również może zawierać kod PHP.

Dlatego nie należy traktować motywu wyłącznie jako warstwy wizualnej.

Motyw może wykonywać:

• zapytania do bazy,
• operacje na formularzach,
• obsługę AJAX,
• integracje z API,
• operacje na plikach,
• własne funkcje PHP.

Szczególnie ryzykowne są:

• stare motywy,
• pirackie motywy,
• „nulled themes”,
• motywy pobrane z nieznanych źródeł.

---

8. wp-content/uploads/ – krytyczny katalog

To jeden z katalogów, które security engineer powinien sprawdzić w pierwszej kolejności.

Znajdują się tutaj pliki przesyłane przez użytkowników lub generowane przez WordPress.

Przykładowo:

wp-content/uploads/
├── 2026/
│   ├── 08/
│   │   ├── obraz.jpg
│   │   ├── dokument.pdf
│   │   └── ...

Ryzyko pojawia się wtedy, gdy aplikacja lub źle skonfigurowany serwer pozwoli na wykonanie kodu znajdującego się w katalogu uploadów.

Dlatego należy zweryfikować:

• jakie rozszerzenia można przesyłać,
• czy PHP może być wykonywane w uploads,
• jakie są prawa zapisu,
• czy istnieją nieznane pliki .php,
• czy pluginy nie tworzą wykonywalnych plików w tym katalogu.

---

9. wp-config.php – jeden z najważniejszych plików

wp-config.php zawiera między innymi dane potrzebne do połączenia z bazą danych.

Przykładowo:

define( 'DB_NAME', 'database' );
define( 'DB_USER', 'user' );
define( 'DB_PASSWORD', '********' );
define( 'DB_HOST', 'localhost' );

Przejęcie tego pliku może oznaczać przejęcie danych dostępowych do bazy.

Oficjalna dokumentacja WordPressa wskazuje wp-config.php jako jeden z najważniejszych plików konfiguracyjnych instalacji. (WordPress Developer Resources)

Warto również rozważyć:

define( 'DISALLOW_FILE_EDIT', true );

Wyłącza to możliwość edycji plików pluginów i motywów z poziomu panelu WordPressa. WordPress wskazuje tę funkcję jako dodatkową warstwę ochrony. (WordPress Developer Resources)

---

10. Uprawnienia plików – pierwszy test hardeningu

Typowa konfiguracja:

Element	Typowe ustawienie
Katalogi	755
Pliki	644
wp-config.php	bardziej restrykcyjne
Pliki Core	bez zapisu dla procesu WWW, jeśli architektura na to pozwala
wp-content	zapis kontrolowany
uploads	zapis wymagany przez aplikację
plugins	brak niepotrzebnego zapisu
themes	brak niepotrzebnego zapisu

WordPress wskazuje 755 dla katalogów i 644 dla plików jako przykładowy schemat, jednocześnie podkreślając, że właściwe uprawnienia zależą od konfiguracji serwera. (WordPress Developer Resources)

Czego unikać?

777

dla całej instalacji.

777 oznacza możliwość odczytu, zapisu i wykonania przez właściciela, grupę i pozostałych użytkowników.

Z punktu widzenia security:

777 = bardzo zły punkt wyjścia.

---

11. Porównanie poziomów zabezpieczeń

Obszar	Niska ochrona	Średnia	Wysoka
WordPress Core	stara wersja	aktualna	aktualna + kontrola zmian
Pluginy	wiele nieużywanych	aktualizowane	minimalny zestaw + audyt
Motyw	nieznane źródło	aktualny	własny / zaufany
Hasła	proste	silne	silne + MFA/2FA
/wp-admin	publiczny	rate limiting	MFA + dodatkowa kontrola
HTTPS	brak	TLS	TLS + HSTS
wp-config.php	644	ograniczony	restrykcyjny + ochrona HTTP
Uploads	brak kontroli	podstawowa	kontrola typów + blokada wykonania PHP
Plugin editor	aktywny	aktywny	wyłączony
WAF	brak	plugin	WAF przed aplikacją
Backup	sporadyczny	regularny	automatyczny + test restore
Monitoring	brak	logi	monitoring + file integrity
Baza danych	szerokie uprawnienia	ograniczone	minimalne wymagane
SSH/FTP	FTP	SFTP	SSH/SFTP + klucze
Aktualizacje	ręczne	regularne	kontrolowany proces patch management

---

12. Ocena bezpieczeństwa – model punktowy

Dla administratora można zastosować prosty model audytowy:

Kontrola	Punkty
Aktualny WordPress	10
Aktualny PHP	10
Aktualne pluginy	10
Aktualny motyw	5
2FA administratorów	10
HTTPS	5
Bezpieczne prawa plików	10
Ochrona wp-config.php	10
Ochrona uploads	10
WAF / firewall	5
Backup + test odtworzenia	5
Monitoring	5
Łącznie	100

Interpretacja

Wynik	Ocena
90–100	bardzo dobry poziom
75–89	dobry
60–74	umiarkowany
40–59	podwyższone ryzyko
0–39	krytycznie słabe zabezpieczenia

To jest model praktyczny, a nie oficjalna klasyfikacja WordPressa.

---

13. Co sprawdziłbym jako informatyk ds. bezpieczeństwa?

Podczas audytu WordPress 7.1 kolejność kontroli powinna wyglądać mniej więcej tak:

Warstwa 1 – infrastruktura

• wersja systemu operacyjnego,
• wersja PHP,
• Apache/Nginx,
• konfiguracja TLS,
• firewall,
• SSH,
• dostęp do panelu hostingu.

Warstwa 2 – WordPress Core

• wersja Core,
• integralność plików,
• aktualizacje,
• konfiguracja wp-config.php,
• REST API,
• XML-RPC,
• cron.

Warstwa 3 – pluginy

• liczba pluginów,
• nieużywane pluginy,
• źródło pluginów,
• daty ostatnich aktualizacji,
• znane podatności,
• uprawnienia pluginów.

Warstwa 4 – motyw

• źródło,
• aktualizacje,
• kod PHP,
• JavaScript,
• zewnętrzne biblioteki.

Warstwa 5 – konta

• administratorzy,
• stare konta,
• role,
• MFA,
• sesje,
• hasła,
• aplikacyjne tokeny dostępowe.

Warstwa 6 – system plików

• 644,
• 755,
• 777,
• właściciel plików,
• grupy,
• pliki PHP w uploads,
• nieznane pliki,
• modyfikacje Core.

Warstwa 7 – monitoring

• logi HTTP,
• logi PHP,
• logi WordPressa,
• zmiany plików,
• nietypowe logowania,
• nietypowe requesty,
• błędy 403/404/500.

---

14. WordPress 7.1 – gdzie naprawdę znajduje się ryzyko?

Największym błędem jest myślenie:

„Mam najnowszego WordPressa, więc moja strona jest bezpieczna.”

Nie.

Bezpieczeństwo wygląda bardziej jak równanie:

Security = Core × PHP × Plugins × Theme × Server × Configuration × Credentials × Monitoring × Backup

Jeżeli jeden z kluczowych elementów jest bardzo słaby, cały poziom bezpieczeństwa może gwałtownie spaść.

Przykład:

WordPress 7.1 + aktualny PHP + bezpieczny serwer + 2FA

może być bardzo dobrze zabezpieczonym środowiskiem.

Ale:

WordPress 7.1 + stary plugin z podatnością + administrator bez 2FA

nadal może oznaczać realne ryzyko przejęcia strony.

---

15. Najważniejsze zasady hardeningu WordPress 7.1

Minimum

1. Aktualny WordPress.
2. Aktualny PHP.
3. Aktualne pluginy.
4. Aktualny motyw.
5. Usunięcie nieużywanych pluginów.
6. Usunięcie nieużywanych motywów.
7. Silne hasła.
8. 2FA dla administratorów.
9. HTTPS.
10. Bezpieczne uprawnienia plików.

Poziom zaawansowany

11. WAF.
12. Rate limiting.
13. Monitoring integralności plików.
14. Centralizacja logów.
15. Ochrona wp-config.php.
16. Blokowanie wykonywania PHP w uploads.
17. Ograniczenie możliwości edycji pluginów i motywów z panelu.
18. SFTP/SSH zamiast nieszyfrowanego FTP.
19. Backup poza serwerem.
20. Regularny test odtworzenia backupu.

WordPress oficjalnie rekomenduje m.in. SFTP, odpowiednie uprawnienia plików, ochronę wp-config.php, wyłączenie edytora plików oraz regularne aktualizowanie pluginów. (WordPress Developer Resources)

---

16. Wnioski

WordPress 7.1 nie powinien być oceniany wyłącznie jako aplikacja CMS.

Z punktu widzenia cyberbezpieczeństwa jest to cały ekosystem:

                INTERNET
                    │
                    ▼
               [ WAF / CDN ]
                    │
                    ▼
             [ Web Server ]
                    │
                    ▼
                [ PHP ]
                    │
                    ▼
             [ WordPress 7.1 ]
              /      |      \
             /       |       \
       Plugins     Themes    REST/API
          │           │         │
          └──────┬────┴─────────┘
                 ▼
             [ DATABASE ]
                 │
                 ▼
              [ BACKUP ]

Najważniejsza zasada brzmi:

Aktualny WordPress to dopiero początek bezpieczeństwa, a nie jego koniec.

Największe znaczenie ma odpowiednie zabezpieczenie całego łańcucha: infrastruktury, systemu plików, Core, pluginów, motywu, kont administracyjnych, bazy danych oraz warstwy sieciowej.

Dla administratora WordPress 7.1 powinien być więc punktem wyjścia do hardeningu i audytu, a nie argumentem do rezygnacji z dodatkowych zabezpieczeń.

---

Checklista audytu WordPress 7.1

• WordPress 7.1 lub nowszy dostępny security release
• Aktualny PHP
• Aktualne pluginy
• Aktualny motyw
• Usunięte nieużywane pluginy
• Usunięte nieużywane motywy
• 2FA dla administratorów
• HTTPS
• Bezpieczne prawa plików
• Brak 777
• Zabezpieczony wp-config.php
• Sprawdzone wp-content/uploads
• Brak wykonywania PHP w uploadach
• Wyłączony edytor plików
• WAF / firewall
• Rate limiting
• Backup poza serwerem
• Przetestowane odtworzenie backupu
• Monitoring logów
• Monitoring integralności plików
• Przegląd kont administratorów
• Przegląd ekspozycji REST API
• Przegląd XML-RPC
• Kontrola konfiguracji serwera

StopHacker.pl | Cyberbezpieczeństwo bez uproszczeń

Cybersecurity – bezpieczeństwo zaczyna się od świadomości

Cybersecurity to nie jeden plugin, firewall czy aktualizacja WordPressa. To proces ciągłej ochrony, kontroli i reagowania na zagrożenia.

Każdy system może stać się celem ataku. Różnica polega na tym, czy atakujący znajdzie środowisko pozbawione kontroli, czy system przygotowany na próbę naruszenia jego bezpieczeństwa.

Dlatego w Hacker Stop patrzymy na bezpieczeństwo szerzej:

identyfikacja → analiza → hardening → monitoring → reakcja → odzyskiwanie.

Bezpieczeństwo cyfrowe zaczyna się od poznania własnej infrastruktury. Dopiero wtedy można skutecznie ograniczać powierzchnię ataku i budować odporność systemu.

Nie pytaj, czy zostaniesz zaatakowany. Sprawdź, czy Twój system będzie na to przygotowany.

Hacker Stop — zatrzymaj zagrożenie, zanim zatrzyma ono Ciebie.

WordPress 7.1, cybersecurity, cyberbezpieczeństwo, WordPress Security, bezpieczeństwo WordPress, hardening, security audit, audyt bezpieczeństwa, bezpieczeństwo stron WWW, ochrona WordPress, WordPress hardening, PHP security, wp-config.php, wp-content, wp-admin, pluginy WordPress, wtyczki WordPress, ochrona serwera, WAF, firewall, 2FA, MFA, HTTPS, SSL/TLS, ochrona plików, uprawnienia plików, backup, monitoring, web security, IT security, Hacker Stop