Nazwa wtyczki	Dobrze zrobione
Rodzaj podatności	Lokalne włączenie plików
Numer CVE	CVE-2026-28118
Pilność	Wysoki
Data publikacji CVE	2026-02-28
Adres URL źródła	CVE-2026-28118

Pilne: Włączenie lokalnych plików w motywie Welldone (<= 2.4) — Co właściciele stron WordPress muszą zrobić teraz

Została ujawniona luka o wysokim stopniu zagrożenia w zakresie włączenia lokalnych plików (LFI), która dotyczy motywu WordPress Welldone (wersje <= 2.4). Śledzona jako CVE-2026-28118 i przypisana do podstawowego wyniku CVSS 8.1, ta słabość pozwala nieautoryzowanym atakującym na włączenie lokalnych plików na podatnej stronie i ujawnienie ich zawartości atakującemu. Ponieważ informacje przechowywane w lokalnych plikach (dane logowania do bazy danych, klucze API, szczegóły konfiguracji) mogą prowadzić do pełnego kompromitacji, natychmiastowe działania naprawcze są wymagane dla każdej strony korzystającej z dotkniętego motywu.

Piszę jako część zespołu bezpieczeństwa WP‑Firewall z praktycznymi, bezpośrednimi wskazówkami: dlaczego to jest niebezpieczne, jak to działa na poziomie technicznym, jak wykrywać próby wykorzystania oraz priorytetową listę kontrolną natychmiastowych i średnioterminowych działań, które możesz podjąć, aby chronić swoją stronę WordPress. Jeśli zarządzasz wieloma stronami lub klientami hostingu zarządzanego, podziel się tym postem z zespołami — poniższe kroki są uporządkowane według pilności i łatwości wdrożenia.

Podsumowanie ujawnienia

• Dotknięte oprogramowanie: motyw WordPress Welldone
• Wersje podatne: <= 2.4
• Typ luki w zabezpieczeniach: Włączenie lokalnych plików (LFI)
• CVE: CVE-2026-28118
• CVSS: 8.1 (Wysoka)
• Wymagane uprawnienia: Brak (nieautoryzowany)
• Wpływ: Dowolne odczytywanie lokalnych plików; możliwe ujawnienie danych logowania i wrażliwych plików; może prowadzić do pełnego przejęcia w zależności od konfiguracji serwera
• Zgłoszone przez: Tran Nguyen Bao Khanh (zgłoszone 19 sierpnia 2025; ujawnienie publiczne 26 lutego 2026)

Dlaczego LFI jest tak niebezpieczne dla stron WordPress

Włączenie lokalnych plików występuje, gdy aplikacja buduje ścieżkę do lokalnego pliku, używając danych wejściowych dostarczonych przez użytkownika, bez odpowiedniej walidacji lub sanitizacji, a następnie włącza lub odczytuje tę ścieżkę. W PHP funkcje takie jak include(), require(), include_once(), I require_once() są powszechnymi miejscami, w których pojawiają się takie błędy — szczególnie w motywach i wtyczkach, które ładują części szablonów lub zewnętrzne pliki na podstawie parametrów URL.

Dla stron WordPress konsekwencje są szczególnie poważne:

• wp-config.php często zawiera dane logowania do bazy danych i sól; odczytanie go może dać atakującemu pełny dostęp do bazy danych.
• Inne pliki mogą zawierać klucze API, dane logowania SMTP lub dane poufne.
• Jeśli opakowania PHP (np., php://filter) lub lokalizacje przesyłania są dostępne, atakujący może eskalować z odczytu plików do wykonywania kodu (np. poprzez zlokalizowanie i pobranie zapisywalnego miejsca przesyłania, które później będzie używane do przechowywania tylnej furtki).
• Ponieważ luka jest dostępna bez uwierzytelnienia, masowe automatyczne skanowanie i próby wykorzystania są prawdopodobne — i oczekujemy, że oportunistyczni atakujący szybko zaatakują ujawnione instalacje.

Jak atakujący zazwyczaj wykorzystują LFI (na wysokim poziomie)

Atakujący odkrywa parametr, który jest używany w wywołaniu włączenia pliku (na przykład coś takiego jak include( $template_path . $_GET['page'] . '.php' ); ). Jeśli ten parametr nie jest walidowany, atakujący może wysyłać żądania, które odnoszą się do innych lokalnych plików za pomocą przejścia katalogowego (../../../../wp-config.php) lub za pomocą opakowań strumieni PHP (php://filter, data://). Nawet gdy bezpośrednie dołączenie jest zablokowane, wiele łańcuchów LFI można przekształcić w zdalne wykonanie kodu (RCE) poprzez najpierw ujawnienie plików, dzienników lub dołączenie innych dostępnych zasobów.

Nie będziemy tutaj dzielić się działającymi ładunkami exploitów, ale ważne jest, aby obrońcy rozpoznawali wzorce i wskaźniki opisane w sekcji wykrywania poniżej.

Wskaźniki ataku i kompromitacji — na co zwracać uwagę

Monitoruj swoje dzienniki (dzienniki dostępu serwera WWW, dzienniki błędów PHP, dzienniki WordPress) w poszukiwaniu tych oznak:

1. Żądania zawierające wzorce przejścia katalogowego w ciągach zapytań:
   • Niezakodowane lub zakodowane "../" sekwencje (np., .., %2e%2e%2f)
   • Powtarzające się próby przejścia jak ../../../../
2. Żądania odnoszące się do wrażliwych nazw plików:
   • wp-config.php, wp-config.php.bak, .env, /etc/passwd, .htpasswditd.
3. Żądania używające wspólnych nazw parametrów LFI:
   • Parametry zapytania nazwane plik, strona, szablon, inc, ścieżka, moduł, lub inne
   • Nagłe wybuchy żądań do punktu końcowego motywu z różnymi ładunkami przejścia
4. Użycie wzorców opakowań strumieni PHP:
   • php://filter, expect://, data:// pojawiające się w parametrach zapytania
5. Abnormalne wpisy w logach lub nowe pliki PHP/JS w wp-content/przesyłanie, wp-content/themes//, lub innych katalogach, które można zapisywać:
   • Podejrzanie nazwane pliki
   • Ostatnio zmodyfikowane szablony lub pliki wtyczek, których nie zmieniałeś
6. Nagłe nietypowe zapytania do bazy danych, nieoczekiwana tworzenie użytkowników administratora lub zmiany w plikach rdzenia motywu/wtyczek.

Jeśli znajdziesz coś z powyższego, traktuj to jako wysoką priorytetowość i postępuj zgodnie z poniższymi krokami incydentu.

Natychmiastowe (w ciągu godzin) łagodzenie — działania triage i praktyczne

Jeśli masz jedną z dotkniętych wersji lub nie jesteś pewien, zastosuj jedno lub więcej z tych natychmiastowych łagodzeń. Są one uporządkowane według szybkości i wpływu:

1. Tymczasowo wyłącz podatny motyw:
   • Przełącz się na domyślny motyw (np. czysty, utrzymywany standardowy motyw). To najszybszy sposób na usunięcie powierzchni ataku, jeśli możesz sobie pozwolić na krótką zmianę wizualną.
   • Jeśli to nie jest możliwe, wprowadź stronę w tryb konserwacji, podczas gdy stosujesz inne łagodzenia.
2. Usuń lub poddaj kwarantannie podatny motyw z systemu plików:
   • Jeśli masz dostęp do serwera (SFTP/SSH), zmień nazwę lub usuń katalog podatnego motywu z wp-content/themes/. To zapobiega wykonywaniu kodu motywu.
   • Ważny: Zachowaj kopię (poza serwerem) do analizy, jeśli prowadzisz dochodzenie.
3. Zablokuj podejrzane żądania na serwerze WWW lub zaporze aplikacji webowej:
   • Zablokuj żądania z sekwencjami przechodzenia przez katalogi i próbami dostępu do plików rdzenia:
   • Przykład (nginx, uproszczony): odrzuć żądania z zakodowanymi .. sekwencjami lub php://:

   if ($request_uri ~* "(||\.\./|\.\.\\)") {
   

   • Notatka: Użyj ostrożnego testowania przed zastosowaniem reguł na całym serwerze, aby uniknąć łamania prawidłowych adresów URL; testuj na stronie testowej, gdy to możliwe.
   • Przykład (Apache .htaccess) — zabroń bezpośredniego dostępu do wp-config i zablokuj ciągi zapytań z podejrzanymi wzorcami:

   <Files "wp-config.php">
     Order allow,deny
     Deny from all
   </Files>
   
   # Block attempts to access common sensitive files
   <IfModule mod_rewrite.c>
     RewriteEngine On
     # Block requests containing ../ or php:// or data:// (basic)
     RewriteCond %{QUERY_STRING} (\.\.|php://|data://) [NC,OR]
     RewriteCond %{REQUEST_URI} (\.\.|php://|data://) [NC]
     RewriteRule ^.* - [F,L]
   </IfModule>
   

4. Wzmocnij uprawnienia do plików i własność (szybkie kontrole):
   • Zapewnić wp-config.php nie jest dostępny dla wszystkich. Zalecane uprawnienia:
     • wp-config.php → 400 lub 440 w zależności od konfiguracji serwera
     • Katalogi → 755
     • Pliki → 644 (z wyjątkiem wrażliwych plików konfiguracyjnych, które powinny być bardziej restrykcyjne)
   • Upewnij się, że pliki są własnością odpowiedniego użytkownika (użytkownik serwera WWW nie powinien być właścicielem plików, jeśli twój host wspiera bardziej bezpieczne oddzielenie).
5. Wyłącz niebezpieczne opakowania PHP i funkcje, gdzie to możliwe:
   • W Plik php.ini, upewnij się allow_url_fopen = Wyłączone I allow_url_include = Wyłączone. To zmniejsza ryzyko zdalnego włączenia pliku lub nadużycia opakowania strumieniowego.
   • Rozważ wyłączenie ryzykownych funkcji (tylko jeśli twoja aplikacja ich nie potrzebuje): exec, shell_exec, system, passthru, proc_open, popen. Przykład:

   disable_functions = exec,shell_exec,system,passthru,proc_open,popen
   

6. Zablokuj parametry dostarczane przez użytkownika używane do ładowania plików:
   • Jeśli zidentyfikujesz konkretne punkty końcowe motywu, które akceptują plik Lub szablon parametry, dodaj szybkie reguły blokujące po stronie serwera dla żądań zawierających te nazwy parametrów, aż motyw zostanie poprawiony.
7. Aktywuj WAF/wirtualną łatkę
   • Jeśli korzystasz z zarządzanego zapory aplikacji internetowej (WAF) lub wtyczki zabezpieczającej, która może wdrażać wirtualne łatki, włącz lub dodaj reguły, które:
     • Wykrywaj sekwencje przechodzenia przez katalogi
     • Wykryj php:// I data:// opakowania
     • Blokuj żądania próbujące uzyskać dostęp wp-config.php lub innych wrażliwych plików
   • Wirtualne łatanie zapobiega wykorzystaniu, nawet jeśli podstawowy kod pozostaje podatny, dając ci czas do momentu, gdy oficjalna łatka będzie dostępna.

Średnioterminowe (dni) usunięcie i weryfikacja

1. Zastąp lub zaktualizuj motyw
   • Sprawdź, czy dostępna jest oficjalna łatka lub nowa wersja motywu, która rozwiązuje CVE-2026-28118. Jeśli dostępna jest oficjalna poprawiona wersja, przetestuj ją dokładnie na etapie testowym, a następnie zaktualizuj produkcję.
   • Jeśli nie ma oficjalnej łatki, rozważ zastąpienie motywu utrzymywanym zamiennikiem lub niestandardowym motywem potomnym utrzymywanego motywu bazowego.
2. Przeprowadź audyt swojego systemu plików w poszukiwaniu webshelli i podejrzanych plików
   • Skanuj wp-content/przesyłanie, katalogów motywów i katalogów wtyczek w poszukiwaniu:
     • Plików z wykonywalnym PHP, gdzie nie powinno ich być
     • Plików z niedawno zmienionymi znacznikami czasu, których nie rozpoznajesz
     • Znanych wskaźników z twoich systemów wykrywania intruzów
3. Rotacja danych uwierzytelniających i sekretów
   • Zmień wszystkie hasła administratora WordPressa, hasła do bazy danych, klucze API i wszelkie inne dane uwierzytelniające, które mogą być przechowywane na serwerze lub ujawnione.
   • Jeśli przywracasz z kopii zapasowej, zmień dane uwierzytelniające po tym.
4. Przejrzyj logi serwera i aplikacji
   • Spójrz wstecz na logi z okresu przed i po dacie ujawnienia w poszukiwaniu podejrzanej aktywności wskazującej na udane wykorzystanie (na przykład kody odpowiedzi, które zawierają dane wyjściowe wrażliwych plików lub powtarzające się próby wykorzystania).
   • Eksportuj odpowiednie logi do bezpiecznej lokalizacji na potrzeby ewentualnej pracy kryminalistycznej.
5. Pełne skanowanie złośliwego oprogramowania witryny i sprawdzenie integralności
   • Przeprowadź pełne skanowanie złośliwego oprogramowania; wiele skanerów wykryje webshelli, tylne drzwi i zmodyfikowane pliki rdzenne.
   • Użyj narzędzi do integralności plików, aby porównać swoją bazę kodu z znanymi dobrymi źródłami.
6. Przywróć z czystych kopii zapasowych, jeśli kompromitacja została potwierdzona
   • Jeśli znajdziesz dowody na kompromitację, których nie możesz w pełni usunąć, przywróć z kopii zapasowej wykonanej przed najwcześniejszymi oznakami kompromitacji. Upewnij się, że wykonasz inne kroki naprawcze (sztywne uprawnienia, rotacja poświadczeń) po przywróceniu.

Długoterminowa prewencja i wzmocnienie (tygodnie / w toku)

1. Zasada najmniejszych uprawnień
   • Upewnij się, że użytkownicy plików i bazy danych mają tylko te uprawnienia, których potrzebują.
   • Unikaj uruchamiania procesów serwera WWW jako tego samego użytkownika, który może modyfikować pliki.
2. Izoluj środowiska
   • Utrzymuj izolowane środowiska stagingowe i produkcyjne.
   • Używaj różnych poświadczeń dla różnych środowisk.
3. Ciągłe monitorowanie i powiadamianie
   • Centralizuj logi (dostęp, błąd, PHP) i dodaj alerty dla:
     • Prób przejścia przez katalogi
     • Żądań odnoszących się wp-config.php i innych wrażliwych plików
     • Niezwykłych wzrostów w odpowiedziach 4xx/5xx
4. Regularne skanowanie luk w zabezpieczeniach
   • Wykonuj automatyczne skany i regularne zaplanowane ręczne przeglądy kodu motywów i wtyczek.
   • Subskrybuj źródła informacji o lukach w zabezpieczeniach i skonfiguruj swoje procedury zarządzania łatkami, aby były responsywne.
5. Regularne kopie zapasowe i testowane przywracanie
   • Utrzymuj kopie zapasowe w wersjach poza siedzibą i regularnie testuj procedury przywracania.
6. Wzmocnienie samego WordPressa
   • Utrzymuj zaktualizowane jądro WordPressa, wtyczki i motywy.
   • Usuń nieużywane wtyczki i motywy.
   • Wyłącz lub chroń edytory motywów i wtyczek.
   • Wprowadź nagłówki zabezpieczeń i HTTPS wszędzie.

Sugerowane zasady wykrywania i zapobiegania WAF (koncepcyjne)

Poniżej znajdują się wzorce obronne, które możesz dostosować do swojego zestawu reguł WAF lub serwera. Są to koncepcyjne podpisy regex i powinny być testowane przed wdrożeniem, aby uniknąć fałszywych pozytywów.

• Blokuj żądania z próbami przejścia przez katalogi (podstawowe):
  • Wyrażenie regularne: (\.\./|\.\.\\||)
• Blokuj opakowania php://, data://, expect://:
  • Wyrażenie regularne: (php://|data://|expect://|zip://|phar://)
• Blokuj próby odniesienia do wrażliwych plików w ciągach zapytań:
  • Wyrażenie regularne: (wp-config\.php|/etc/passwd|/proc/self/environ|\.env|\.htpasswd)
• Blokuj długie sekwencje zakodowanych znaków wskazujących na obfuskację:
  • Wyrażenie regularne: (%[0-9A-Fa-f]{2}){6,}

Przykładowa pseudo-reguła (niezależna od WAF):

• Jeśli ciąg zapytania żądania pasuje do któregokolwiek z:
  • (\.\./|\.\.\\||) LUB
  • (php://|data://|expect://) LUB
  • (wp-config\.php|/etc/passwd|\.env)

  → wtedy zablokuj żądanie (HTTP 403) i zarejestruj szczegóły do przeglądu.

Uwagi dotyczące fałszywych pozytywów: Wiele systemów CMS i legalnych bibliotek może zawierać tokeny przypominające ryzykowne wzory. Starannie testuj każdy wzór, ograniczaj zasady do prawdopodobnych punktów końcowych (pliki motywów, punkty końcowe dołączania) i stopniowo zaostrzaj zasięg.

Jeśli Twoja strona została skompromitowana — lista kontrolna reakcji na incydent

Jeśli potwierdzisz kompromitację, natychmiast wykonaj te kroki:

1. Wyłącz stronę (tryb konserwacji) lub izoluj hosta.
2. Zrób pełny zrzut strony i logów do analizy kryminalistycznej.
3. Zmień wszystkie hasła (użytkownicy admina, baza danych, FTP/SFTP, panel sterowania).
4. Rotuj wszystkie klucze i tokeny, które mogły być przechowywane na serwerze.
5. Skanuj i usuń złośliwe pliki oraz webshells. Jeśli nie masz pewności co do ręcznego czyszczenia, przywróć z czystej kopii zapasowej.
6. Zweryfikuj integralność bazy danych i usuń nieautoryzowanych użytkowników admina lub wstrzyknięcia treści.
7. Przeprowadź pełny audyt, aby zidentyfikować, jak napastnik uzyskał dostęp i jakie ruchy boczne mógł wykonać.
8. Odbuduj środowisko z znanych dobrych źródeł, jeśli to konieczne; nie polegaj na “tylko czyszczeniu”, jeśli tylne drzwi są skomplikowane.

Jak WP‑Firewall pomaga (co zarządzany WAF robi dla Ciebie)

Z perspektywy zarządzanej usługi bezpieczeństwa WordPress, wzmacniamy i chronimy strony, łącząc kilka warstw:

• Wirtualne łatanie (zasady WAF): Gdy pojawia się luka, taka jak LFI, możemy wdrożyć ukierunkowane zasady, które wykrywają i blokują wzorce eksploatacji na Twoich stronach, aż do momentu, gdy dostępna będzie łatka od dostawcy.
• Zarządzany firewall i inspekcja żądań: Analiza parametrów żądania w czasie rzeczywistym w celu zablokowania sekwencji przejść, użycia wrapperów PHP i innych sygnatur eksploatacji.
• Skanowanie złośliwego oprogramowania i automatyczne czyszczenie: Ciągłe skany w celu znalezienia złośliwych plików i automatyczne usuwanie wielu znanych webshelli i tylnych drzwi.
• Łagodzenie OWASP Top 10: Systemowe zabezpieczenia zaprojektowane w celu zmniejszenia ryzyka z najczęstszych klas zagrożeń (Wstrzyknięcie, Uszkodzona autoryzacja, LFI/RFI itp.).
• Monitorowanie, alerty i raportowanie: Monitorujemy anomalie w ruchu i wydajemy terminowe alerty, jeśli wykryjemy próby eksploatacji lub dowody kompromitacji.

Zalecamy strategię warstwową: połącz wirtualne łatanie i ochronę WAF z bezpieczną konfiguracją, szybkimi aktualizacjami i monitorowaniem. Wirtualne łatanie zapewnia natychmiastową ochronę, podczas gdy przeprowadzasz staranne testy wymagane do oficjalnych aktualizacji lub wymiany motywów.

Krótkie notatki techniczne dla programistów i administratorów systemów

Ta klasa luk prawie zawsze pochodzi z niebezpiecznego łączenia danych wejściowych użytkownika w ścieżki systemu plików. Twoja lista kontrolna dla bezpiecznych plików obejmuje:

• Nigdy nie używaj bezpośrednio danych wejściowych użytkownika do budowania nazw plików bez białej listy dozwolonych wartości.
• Używaj bezpiecznych mapowań (np. mapuj krótkie, znane klucze na dozwolone nazwy plików) zamiast akceptować pełne dane wejściowe ścieżki.
• Normalizuj i waliduj każdą ścieżkę przed przekazaniem do include/require.
• Jeśli zawartość użytkownika decyduje o wyborze szablonu, ogranicz wybory do zaufanego zestawu, który istnieje w Twoim kodzie.

Przykład bezpieczniejszego podejścia (pseudo-kod):

<?php;

Ten wzór mapuje dane wejściowe użytkownika na kontrolowaną listę i zapobiega dowolnemu włączaniu plików.

Nowy zasób dla właścicieli stron: Zacznij od natychmiastowej, darmowej ochrony

Chroń swoją stronę teraz z naszym podstawowym darmowym planem — zarządzany firewall, WAF, skanowanie złośliwego oprogramowania i ochrona przed zagrożeniami OWASP Top 10. Jest zaprojektowany, aby chronić strony natychmiast, podczas gdy planujesz wszelkie wymagane aktualizacje lub wymiany motywów.

Zabezpiecz swoją stronę już teraz — zacznij od WP‑Firewall Basic (darmowy)

• Co otrzymujesz natychmiast:
  • Zarządzany firewall i WAF z możliwością wirtualnych poprawek
  • Nielimitowana przepustowość dla ruchu zabezpieczającego
  • Skanowanie złośliwego oprogramowania w celu znalezienia podejrzanych plików i zmian
  • Ochrona przed zagrożeniami OWASP Top 10 (w tym wzorami LFI)
• Dlaczego to pomaga:
  • Otrzymujesz natychmiastowe blokowanie znanych wzorów eksploatacji dla nowo ujawnionych luk
  • Wirtualne poprawki zmniejszają okno ataku, podczas gdy testujesz oficjalne aktualizacje lub migrujesz
• Zacznij: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

(Oferujemy również płatne poziomy, jeśli potrzebujesz automatycznego usuwania złośliwego oprogramowania, kontroli blokowania IP, miesięcznych raportów lub zarządzanych usług zabezpieczeń.)

Praktyczne przykłady — szybkie zasady, które możesz wkleić i przetestować (podsumowanie)

• Chroń wp-config.php (umieść w Plik .htaccess):

<files wp-config.php>
  order allow,deny
  deny from all
</files>

• Reguła Nginx do blokowania prób z użyciem wrappera php:

if ($query_string ~* "php://|data://||(\.\./)") {

• Utwardzanie PHP ini:

allow_url_fopen = Off

Ważny: Przetestuj te zasady na stagingu, aby upewnić się, że nie blokują one legalnego ruchu dla twojego konkretnego zachowania motywu lub wtyczki.

Ostateczne zalecenia — co zrobić w ciągu następnych 24–72 godzin

1. Inwentaryzacja: Zidentyfikuj wszelkie strony działające na motywie Welldone ≤ 2.4.
2. Zastosuj co najmniej jedną natychmiastową łagodzenie:
   • Wyłącz/zmień nazwę folderu motywu, lub
   • Zablokuj wzorce eksploatacji na poziomie serwera/WAF, i
   • Zablokuj dostęp do wp-config.php.
3. Włącz ciągłe skanowanie i monitorowanie.
4. Jeśli możesz, zapisz się na zarządzany plan ochrony (dostępny darmowy poziom), aby uzyskać natychmiastowe zastosowanie wirtualnych poprawek, podczas gdy planujesz trwałe rozwiązanie.
5. Komunikuj się z interesariuszami, jeśli hostujesz strony klientów — przejrzystość i szybkie łagodzenie są ważne.

Jeśli potrzebujesz pomocy technicznej

Jeśli prowadzisz wiele instalacji WordPressa lub zarządzasz stronami klientów i chcesz pomocy w triage lub stosowaniu łagodzeń, nasz zespół operacji bezpieczeństwa może pomóc w analizie logów, wdrażaniu wirtualnych poprawek w całej flocie oraz wspierać w odpowiedzi na incydenty i sprzątaniu. Oferujemy również szczegółowe wskazówki dotyczące bezpiecznych aktualizacji i wymiany podatnych motywów.

Wniosek

Ta podatność Welldone LFI (CVE-2026-28118) jest poważną, nieautoryzowaną podatnością, która może ujawniać lokalne pliki i prowadzić do ujawnienia poświadczeń oraz pełnego kompromitacji. Najszybsza droga do bezpieczeństwa to usunięcie lub kwarantanna podatnego motywu oraz wdrożenie zasad wirtualnych poprawek na obrzeżach, podczas gdy planujesz kontrolowaną aktualizację lub wymianę. Wzmocnienie serwera (wyłączenie ryzykownych wrapperów, naprawa uprawnień, ograniczenie dostępu do plików) oraz monitorowanie logów pod kątem powyższych wskaźników znacznie zmniejszy narażenie.

Jeśli chcesz natychmiastowej ochrony bez skomplikowanych zmian na serwerze, wypróbuj nasz darmowy plan podstawowej ochrony, który zapewnia zarządzane zasady zapory, ochrony WAF i skanowanie złośliwego oprogramowania, aby zablokować wzorce eksploatacji, takie jak te używane w atakach LFI. Zacznij zabezpieczać swoją stronę teraz: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

— Zespół Bezpieczeństwa WP‑Firewall

Odniesienia i uwagi

• Podatność śledzona jako CVE-2026-28118 (Lokalne włączenie pliku w motywie Welldone, zgłoszone 19 sierpnia 2025; opublikowane 26 lutego 2026).
• Niniejsze ostrzeżenie ma na celu pomoc obrońcom. Nie publikujemy tutaj kodu eksploatacji. Jeśli jesteś administratorem, który podejrzewa naruszenie i potrzebujesz bezpośredniej pomocy, zgłoś to swoim zespołom reagowania na bezpieczeństwo lub skontaktuj się z zaufanym dostawcą bezpieczeństwa WordPress.