17 lipca 2026 roku zespół bezpieczeństwa WordPressa opublikował wydanie 7.0.2 – i nie była to zwykła, rutynowa aktualizacja. Załatano dwie podatności (jedną krytyczną, jedną o wysokim priorytecie), które połączone w łańcuch pozwalały atakującemu wykonać własny kod na serwerze bez logowania – bez hasła, bez konta, bez żadnej podatnej wtyczki. Wystarczyła czysta, domyślna instalacja WordPressa i jedno anonimowe żądanie z Internetu.

Kilka dni po publikacji luki trafił do nas klient, którego serwer padł ofiarą dokładnie takiego ataku. To, co zastaliśmy, było podręcznikowym przykładem tego, jak jedna nieaktualna strona plus źle skonfigurowany serwer zamieniają lokalny incydent w infekcję wszystkich domen na hostingu. W tym artykule opisujemy ten przypadek krok po kroku – i wyjaśniamy, czym jest open_basedir, dlaczego współdzielenie katalogów to proszenie się o kłopoty oraz dlaczego usuwanie wirusów w takiej konfiguracji przypomina walkę z hydrą.

Co się stało? WordPress 7.0.2 w pigułce

Zanim przejdziemy do case study – krótko o samej luce, bo dotyczy ona praktycznie każdego, kto ma stronę na WordPressie:

• Data wydania poprawki: 17 lipca 2026
• Charakter podatności: ułatwiona iniekcja SQL oraz błąd w obsłudze zbiorczych żądań REST API, które połączone razem prowadziły do zdalnego wykonania kodu (RCE) bez uwierzytelnienia
• Wersje podatne: WordPress od 6.8.0 do 7.0.1
• Wersje bezpieczne: 7.0.2, 6.9.5, 6.8.6
• Skala zagrożenia: na tyle poważna, że WordPress.org włączył wymuszone automatyczne aktualizacje dla podatnych instalacji

To rzadka sytuacja – zdecydowana większość problemów bezpieczeństwa WordPressa dotyczy wtyczek, a nie samego rdzenia. Tym razem podatny był sam WordPress. Dlatego jeśli po zalogowaniu do kokpitu w zakładce Kokpit → Aktualizacje widzisz wersję inną niż 7.0.2 (lub 6.9.5 / 6.8.6 dla starszych gałęzi) – zaktualizuj stronę natychmiast. To dwie minuty pracy, które mogą oszczędzić tygodni sprzątania.

Case study: jedna luka, kilkanaście zainfekowanych domen

Do naszego działu wsparcia technicznego zgłosił się nowy klient z klasycznym zestawem objawów: strona przekierowuje na podejrzane witryny, Google oznaczył domenę jako niebezpieczną, poczta z serwera ląduje w spamie, a hosting wysłał ostrzeżenie o nadużyciach. Problem? Klient miał na jednym serwerze kilkanaście domen – strony firmowe, landing page, projekty testowe.

Nasza analiza logów wykazała, że punktem wejścia była jedna, dawno nieaktualizowana instalacja WordPressa – strona-wizytówka, o której wszyscy zapomnieli. Atakujący wykorzystał lukę, wgrał tzw. webshell (skrypt dający mu zdalną kontrolę) i… tu zaczyna się właściwa część tej historii.

Bo sama infekcja jednej strony to problem przykry, ale opanowalny. Prawdziwa katastrofa wynikała z konfiguracji serwera.

Czym jest open_basedir i dlaczego jego brak to otwarte drzwi

open_basedir to dyrektywa PHP, która ogranicza skryptom dostęp do plików wyłącznie w obrębie wskazanego katalogu. W praktyce: skrypt działający w katalogu domeny A nie może czytać ani zapisywać plików w katalogu domeny B, nawet jeśli obie leżą na tym samym serwerze.

Na serwerze naszego klienta open_basedir nie był ustawiony w ogóle. Efekt? Skrypt hakerski wgrany przez lukę w jednej stronie mógł swobodnie „spacerować” po całym systemie plików w zasięgu użytkownika – listować katalogi pozostałych domen, czytać pliki wp-config.php z hasłami do baz danych i dopisywać złośliwy kod do plików każdej kolejnej strony.

To dokładnie się wydarzyło. W ciągu kilku godzin od pierwszej infekcji automat atakującego:

• odczytał dane dostępowe do baz danych wszystkich instalacji WordPress i PrestaShop na serwerze,
• dopisał złośliwe przekierowania do plików index.php i .htaccess każdej domeny,
• rozsiał dziesiątki kopii webshelli w losowych katalogach – wp-includes, wp-content/uploads, katalogach motywów i wtyczek,
• utworzył ukryte zadania cron, które przywracały infekcję po każdej próbie czyszczenia.

Jedna luka. Kilkanaście zainfekowanych domen. I to nie dlatego, że wszystkie były podatne – tylko dlatego, że nic nie oddzielało ich od siebie.

Współdzielenie katalogów – jeden użytkownik, wiele domen

Drugim grzechem konfiguracji było to, że wszystkie domeny działały na jednym koncie użytkownika systemowego, ze wspólnymi uprawnieniami do plików. To niestety częsty scenariusz: tanie VPS-y konfigurowane „na szybko”, stare panele hostingowe albo sytuacja, w której kolejne strony dokładano latami do jednego konta, bo tak było wygodniej.

Taka architektura oznacza, że z punktu widzenia systemu każdy skrypt PHP każdej domeny ma identyczne prawa do plików wszystkich pozostałych domen. Nie ma znaczenia, że dziesięć stron jest zaktualizowanych i zabezpieczonych wzorowo – wystarczy jedna zaniedbana, by atakujący dostał klucze do całości. W branży bezpieczeństwa mówi się o tym „lateral movement” – ruch boczny. Bez separacji katalogów i użytkowników ten ruch nie napotyka żadnego oporu.

Prawidłowa konfiguracja wygląda tak:

• osobny użytkownik systemowy dla każdej domeny (lub przynajmniej dla każdego klienta/projektu),
• open_basedir ograniczony do katalogu danej strony plus niezbędne katalogi tymczasowe,
• PHP działające w trybie izolowanym (np. PHP-FPM z osobną pulą per domena),
• uprawnienia plików, które nie pozwalają na zapis tam, gdzie zapis nie jest potrzebny.

Dlaczego usuwanie wirusów w takiej konfiguracji jest tak trudne

Tu dochodzimy do sedna problemu, z którym mierzy się każdy, kto próbował „wyczyścić” zainfekowany serwer bez separacji domen. Usuwanie złośliwego kodu w takim środowisku to walka z hydrą – odcinasz jedną głowę, odrastają dwie:

1. Reinfekcja krzyżowa. Czyścisz domenę A, ale webshell ukryty w domenie B po godzinie ponownie dopisuje złośliwy kod do domeny A. Dopóki nie znajdziesz i nie usuniesz wszystkich kopii na wszystkich domenach jednocześnie, sprzątanie jest syzyfową pracą.
2. Nie wiadomo, co jest „czyste”. Skoro atakujący miał dostęp do wszystkiego, żadnemu plikowi nie można ufać. Trzeba weryfikować sumy kontrolne rdzenia WordPressa, każdą wtyczkę, każdy motyw – na każdej domenie osobno.
3. Skompromitowane dane dostępowe. Hasła do wszystkich baz danych, kluczy API i kont FTP należy uznać za wykradzione. Wszystkie – nie tylko te z zaatakowanej strony.
4. Mechanizmy przetrwania. Zadania cron, spreparowane wpisy w bazie danych, „uśpione” backdoory czekające tygodniami na ponowną aktywację. Automatyczne skanery antywirusowe hostingu zwykle znajdują tylko część z nich.

Dlatego koszt usunięcia infekcji z serwera bez separacji jest wielokrotnie wyższy niż z serwera poprawnie skonfigurowanego – i dlatego tak wiele „wyczyszczonych” stron wraca do punktu wyjścia po tygodniu.

Jak rozwiązaliśmy problem – krok po kroku

W opisywanym przypadku nasz zespół przeprowadził pełną procedurę naprawczą:

1. Odcięcie i diagnoza. Zablokowaliśmy ruch do zainfekowanych stron, zabezpieczyliśmy kopię materiału do analizy i na podstawie logów serwera ustaliliśmy wektor ataku oraz dokładną oś czasu infekcji.
2. Czyszczenie wszystkich domen równolegle. Porównaliśmy pliki każdej instalacji z oryginalnymi sumami kontrolnymi, usunęliśmy webshelle, złośliwe wpisy w .htaccess, zainfekowane pliki rdzenia oraz spreparowane zadania cron. Przeskanowaliśmy również bazy danych pod kątem wstrzykniętego kodu i fałszywych kont administratorów.
3. Aktualizacje. Wszystkie instalacje WordPressa zostały podniesione do wersji 7.0.2, wtyczki i motywy zaktualizowane, a nieużywane – usunięte. Porzucone strony testowe zostały za zgodą klienta całkowicie wyłączone.
4. Wymiana wszystkich danych dostępowych. Nowe hasła do baz danych, paneli administracyjnych, kont FTP/SFTP oraz nowe klucze i sole bezpieczeństwa WordPressa.
5. Separacja i utwardzenie serwera. Każda domena otrzymała osobnego użytkownika systemowego i własną pulę PHP-FPM z restrykcyjnym open_basedir. Wyłączyliśmy niebezpieczne funkcje PHP, wdrożyliśmy firewall aplikacyjny (WAF), monitoring integralności plików oraz automatyczne aktualizacje bezpieczeństwa.
6. Odzyskanie reputacji. Zgłosiliśmy oczyszczone strony do ponownej weryfikacji w Google Search Console, zdjęliśmy ostrzeżenia „strona może być niebezpieczna” i przywróciliśmy prawidłowe dostarczanie poczty.

Efekt: wszystkie strony wróciły do działania, a od zakończenia prac monitoring nie wykrył ani jednej próby reinfekcji. Co równie ważne – nawet gdyby w przyszłości któraś ze stron została skompromitowana, infekcja zostanie zamknięta w obrębie jednej domeny, a nie całego serwera.

Jak sprawdzić, czy Twój serwer jest podatny? Szybka checklista

Zanim zamkniesz ten artykuł, poświęć pięć minut na weryfikację:

1. Wersja WordPressa – Kokpit → Aktualizacje. Wszystko poniżej 7.0.2 (lub 6.9.5 / 6.8.6) wymaga natychmiastowej aktualizacji. Nie polegaj ślepo na auto-aktualizacjach – potrafią po cichu zawieść przy problemach z uprawnieniami plików.
2. open_basedir – utwórz plik z funkcją phpinfo() i sprawdź, czy dyrektywa jest ustawiona i wskazuje wyłącznie katalog Twojej strony. Wartość „no value” to czerwona lampka.
3. Liczba domen na jednym koncie – jeśli na jednym użytkowniku hostingu działa kilka niezależnych stron, każda z nich jest tak bezpieczna, jak najsłabsza z nich.
4. Zapomniane instalacje – stare wersje testowe, kopie w podkatalogach typu /old/, /backup/, /test/ to ulubione cele automatów skanujących sieć.
5. Kopie zapasowe – przechowywane poza serwerem, testowane, z historią co najmniej kilku tygodni wstecz. Backup na tym samym serwerze, który padł ofiarą ataku, bywa bezużyteczny.

Najczęstsze pytania (FAQ)

Czy aktualizacja do WordPress 7.0.2 może zepsuć moją stronę?

Wydania bezpieczeństwa zawierają wyłącznie poprawki, bez zmian funkcjonalnych, więc ryzyko jest minimalne. Mimo to przed aktualizacją warto wykonać kopię zapasową – a jeśli strona korzysta z wielu wtyczek lub modyfikacji, przetestować aktualizację na kopii roboczej.

Mam włączone automatyczne aktualizacje. Czy jestem bezpieczny?

Prawdopodobnie tak, ale zweryfikuj to. Automatyczne aktualizacje potrafią zawieść po cichu – przez konflikt wtyczki, problem z uprawnieniami plików czy wyłączony cron. Zajrzyj do kokpitu i sprawdź numer wersji na własne oczy.

Moja strona działa normalnie. Czy to znaczy, że nie została zhakowana?

Niestety nie. Nowoczesne infekcje często działają niezauważalnie – wysyłają spam, kopią kryptowaluty albo pokazują złośliwe treści wyłącznie robotom Google. Brak widocznych objawów nie jest dowodem czystości; jest nim dopiero skan integralności plików.

Czy wystarczy usunąć zainfekowane pliki?

Nie – to najczęstszy błąd. Bez ustalenia wektora ataku, wymiany haseł, aktualizacji i zabezpieczenia serwera infekcja wraca zwykle w ciągu kilku dni.

Podsumowanie

Historia tego klienta pokazuje trzy rzeczy naraz. Po pierwsze: aktualizacje bezpieczeństwa nie są opcjonalne – luka załatana w WordPress 7.0.2 pozwalała przejąć stronę jednym anonimowym żądaniem. Po drugie: konfiguracja serwera decyduje o skali szkód – brak open_basedir i współdzielenie katalogów zamieniły infekcję jednej zapomnianej strony w kompromitację kilkunastu domen. Po trzecie: usuwanie wirusów bez separacji domen to walka z hydrą – i dlatego prewencja jest zawsze tańsza niż sprzątanie.

Jeśli podejrzewasz, że Twoja strona mogła zostać zainfekowana, nie masz pewności, czy Twój serwer jest poprawnie odseparowany, albo po prostu chcesz spać spokojnie – napisz do nas. Przeprowadzimy audyt bezpieczeństwa, wyczyścimy zainfekowane strony i zabezpieczymy serwer tak, by następna głośna luka była dla Ciebie tylko newsem, a nie kryzysem. Zajmujemy się tym na co dzień w ramach wsparcia technicznego i hostingu zoptymalizowanego pod WordPress i PrestaShop.

Artykuł Krytyczna luka w WordPressie – dlaczego aktualizacja do 7.0.2 to konieczność. Przykładowe case study – na co zwrócić uwagę. pochodzi z serwisu Strony Internetowe Olsztyn, Strony www - Virtualmedia Sklepy Internetowe, Profesjonalne, Indywidualne.

Czym rozni sie chatbot AI od zwyklego czatu?

Tradycyjny czat na zywo to okno, w ktorym pojawia sie konsultant – albo i nie, jesli jest poza godzinami pracy. Chatbot regułowy to z kolei drzewo decyzji: jesli klient wpisze konkretne slowo, bot odpowiada zaprogramowana odpowiedzia. Skuteczne, ale sztywne i drogie w utrzymaniu.

Chatbot AI dziala zupelnie inaczej. Jest wytrenowany na tresci Twojej strony – opisach produktow, FAQ, regulaminach, blog postach – i rozumie pytania zadawane naturalnym jezykiem. Klient moze napisac „kiedy dostane paczke jesli zamowie dzis wieczorem?” zamiast szukac zakładki „Czas dostawy”. Bot zrozumie kontekst i odpowie precyzyjnie.

Co chatbot AI daje stronie internetowej i sklepowi?

Odpowiedzi 24/7 bez zatrudniania ludzi

Sklep e-commerce nigdy nie spi, ale Twoj zespol – tak. Chatbot AI przejmuje pierwsza linie obslugi klienta o kazdej porze: odpowiada na pytania o dostepnosc produktu, warunki zwrotu, czas realizacji zamowienia czy zasady gwarancji. Badania pokazuja, ze dobrze wytrenowany chatbot jest w stanie samodzielnie rozwiazac okolo 80% powtarzajacych sie pytan – bez angazu czlowieka.

Wiecej leadow z tego samego ruchu

Uzytkownik trafia na strone, przeglada oferte i wychodzi bez sladu. Chatbot zmienia te scenariusz: aktywnie angaguje, pyta o potrzeby, zbiera adres e-mail, umawia konsultacje. Firmy korzystajace z chatbotow AI raportuja nawet trzykrotnie wiekszy wskaznik pozyskania leadow w porownaniu do samych formularzy kontaktowych.

Mniej porzuconych koszykow w e-commerce

Klient dodal produkt do koszyka, ale sie zatrzymal. Moze ma pytanie o rozmiarowke, moze wacha sie co do sposobu platnosci, moze nie rozumie polityki zwrotow. Chatbot AI wychwytuje te momenty i aktywnie pomaga finalizowac zakup – w odpowiednim momencie, bez nachalnosci.

Realne odciazenie zespolu supportu

Zamiast odpowiadac na te same pytania po raz setny, Twoj zespol zajmuje sie sprawami wymagajacymi prawdziwej uwagi: skomplikowanymi reklamacjami, klientami VIP, rozwojem oferty. Bot obsługuje rutyne, ludzie – relacje.

AIGoChat – chatbot AI, ktory uczy sie z Twojej strony

Na rynku jest wiele narzedzi do budowania chatbotow. Spolecznosc programistow i agencji internetowych rekomenduje AIGoChat – i nie bez powodu. To platforma, ktora stawia na radykalna prostote przy jednoczesnie zaawansowanych mozliwosciach AI.

Idea AIGoChat jest prosta: podajesz adres URL swojej strony, system sam ja przeczytuje i tworzy baze wiedzy. Chatbot wytrenowany w ten sposob zna Twoje produkty, zasady dzialania firmy, FAQ i wszystko, co masz opublikowane online. Nie musisz programowac regul ani reczenie wprowadzac odpowiedzi.

Jak to dziala w praktyce?

1. Tworzysz chatbota – wybierasz nazwe, model AI (GPT-4o, Claude Anthropic lub inne) i kolory zgodne z Twoja marka. Trwa to okolo 2 minut.
2. Dodajesz wiedze – wpisujesz URL swojej strony, a AIGoChat automatycznie indeksuje caly content: strony, opisy produktow, blog, FAQ. Mozesz tez doladowac pliki PDF, dokumenty Word czy reczne wpisy Q&A.
3. Konfigrujesz zachowanie – ustawiasz powitanie, proponowane pytania, filtr tresc i powiadomienia. W razie potrzeby agent moze przejac rozmowe na zywo.
4. Osadzasz na stronie – jeden wiersz kodu JavaScript i chatbot jest gotowy do pracy. Na WordPressie, PrestaShopie, WooCommerce, Shopify – wszedsie.

Funkcje, ktore wyrozniaja AIGoChat

• Inteligentny crawler – automatycznie przeszukuje cala strone, produkty, bloga i FAQ, budujac spjona baze wiedzy bez zadnego recznego wprowadzania danych.
• Obsługa wielu zrodeł – strona, pliki PDF, dokumenty Word, reczne Q&A, dodatkowe URL-e. Mozna laczyc dowolna liczbe zrodeł wiedzy.
• Modele AI klasy enterprise – wsparcie dla OpenAI GPT-4o, Anthropic Claude, Llama i innych. Jezeli masz wlasny klucz API – mozesz go podpiac i kontrolowac koszty.
• Pełna personalizacja wizualna – kolory, logo, awatar, pozycja widgetu, wiadomosc powitalna. Bot wyglada jak integralna czesc Twojej strony, nie jak obcy element.
• Human takeover – agent moze przejac dowolna rozmowe bezposrednio z dashboardu. AI wraca automatycznie, gdy agent konczy rozmowe.
• Voice calling – klient moze zamienic chat w polaczenie glosowe bezposrednio z okna czatu. Agent odbiera w dashboardzie, bez udostepniania numeru telefonu.
• AI Personas – mozesz stworzyc kilka osobowosci bota z roznymi imionami i stylami komunikacji. Przydatne przy obsludze rynkow w roznych jezykach.
• Analityka i raporty – widzisz, o co pytaja klienci najczesciej, gdzie bot nie zna odpowiedzi, jaki jest wskaznik satysfakcji. Codzienny digest na e-mail.
• Moderacja tresci – wbudowany filtr niestosownych tresci chroni rozmowy przed naduzyciami.

Integracje – AIGoChat dziala z tym, czego uzywasz

AIGoChat integruje sie bez zadnego kodowania z najpopularniejszymi platformami:

• WordPress i WooCommerce – jeden skrypt w nagłowku i chatbot dziala na calym serwisie, zna wszystkie produkty i wpisy blogowe.
• PrestaShop – idealny dla sklepow na tej platformie: odpowiada na pytania o produkty, dostepnosc, wysylke i statusy zamowien.
• Shopify, Magento, BigCommerce – pelne wsparcie dla platform e-commerce.
• Webflow, Wix, Squarespace – rowniez serwisy budowane na kreatorach.
• HubSpot, Zapier – integracje z CRM i narzedziem automatyzacji do przekazywania leadow do dalszego followupu.

Cennik – zacznij za darmo

AIGoChat oferuje darmowy plan bez karty kredytowej – idealny do testow i malych stron. Plany platne zaczynaja sie od 29 USD miesiecznie za Starter (10 000 wiadomosci/miesiac, 500 stron crawlingu), przez 79 USD za Professional (30 000 wiadomosci, 3 chatboty, GPT-4o i Claude z wlasnym API), az do 199 USD za Business z 10 chatbotami i 150 000 wiadomosciami.

Kazdy platny plan zawiera 7-dniowy trial i gwarancje zwrotu przez 30 dni – mozesz wyprobowac bez ryzyka.

„AIGoChat przetworzylo nasza obsluge klienta z dnia na dzien. Przeszlismy z 200 e-maili supportowych dziennie do zaledwie 40. Wskaznik CSAT wzrosl z 3.8 do 4.7 – klienci kochaja natychmiastowe odpowiedzi.” – Sarah Johnson, E-commerce Director

Dla kogo chatbot AI jest absolutnym must-have?

• Sklepy e-commerce – odpowiedzi na pytania o produkty, dostepnosc, wysylke i zwroty przez cala dobe. Mniej porzuconych koszykow, wiecej sfinalizowanych zakupow.
• Agencje i firmy uslugowe – kwalifikacja leadow, umawianie konsultacji, odpowiedzi na pytania o oferte poza godzinami pracy.
• Deweloperzy i nieruchomosci – chatbot odpowiada na pytania o dostepnosc mieszkan, standard wykonczenia, ceny i warunki zakupu, zbiera dane kontaktowe zainteresowanych.
• Firmy SaaS i B2B – obsluga dokumentacji technicznej, onboarding uzytkownikow, kwalifikacja pytan przed przekazaniem do handlowca.
• Gabinety, kliniki, uslugi lokalne – umawianie wizyt, odpowiedzi na pytania o oferte, godziny otwarcia i cennik.

Jak wdrozyc chatbot AI na swojej stronie?

Wdrozenie AIGoChat na stronie wykonanej przez Virtualmedia trwa dosłownie kilka minut. Mozemy rowniez skonfigurowac i wytrenowac chatbota w ramach wspolpracy – zadbamy o to, zeby bot znal Twoja oferte, mowil jezykiem Twojej marki i byl poprawnie zintegrowany z reszta strony.

Jesli chcesz wyprobowac AIGoChat samodzielnie – wejdz na aigochat.com i zacznij za darmo. Bez karty kredytowej, bez kodowania, bez limitu czasu na darmowym planie.

Masz pytania o wdrozenie na swojej stronie lub sklepie? Napisz do nas – chyba, ze Twoj nowy chatbot AI juz Ci odpowie.

Artykuł Inteligentny chatbot AI dla strony internetowej i sklepu – czy warto i jak wybrac? pochodzi z serwisu Strony Internetowe Olsztyn, Strony www - Virtualmedia Sklepy Internetowe, Profesjonalne, Indywidualne.