Biuletyn bezpieczeństwa Bookly
Jeśli otrzymali Państwo ode mnie wiadomość kierującą na tę stronę, to dlatego, że Państwa
witryna najprawdopodobniej korzysta z wersji Bookly (wtyczki WordPressa do rezerwacji
wizyt bookly-responsive-appointment-booking-tool) mieszczącej się w zakresie objętym znaną
luką bezpieczeństwa. Ta strona wyjaśnia, na czym polega problem, jak sprawdzić swoją wersję,
jak zaktualizować i jaki jeden krok warto wykonać po aktualizacji.
Chodzi o CVE-2026-13395, nieuwierzytelnione wstrzyknięcie SQL w publicznym procesie rezerwacji wtyczki. Dotyczy wersji od 11.3 do 27.7 i zostało naprawione w 27.8, wydanej 10 lipca 2026 r. Jeśli używają Państwo wersji podatnej, proszę zaktualizować Bookly do 27.8 lub nowszej (27.9 jest wersją bieżącą i również zawiera poprawkę). Nie ma żadnych przesłanek, by ten problem był wykorzystywany przeciwko jakiejkolwiek witrynie ani żadnych publicznych doniesień o wykorzystaniu gdziekolwiek; ta strona to informacja zapobiegawcza, a nie raport z incydentu.
W odróżnieniu od niektórych innych moich powiadomień, to nie zależy od konfiguracji witryny. Żadne ustawienie nie musi być włączone, aby luka była osiągalna: objęta nią ścieżka żądania jest dostępna dla niezalogowanych odwiedzających w zwykłej instalacji. Jeśli Państwa wersja Bookly mieści się w podatnym zakresie, aktualizację warto wykonać szybko.
To luka we wtyczce, a nie w rdzeniu WordPressa. W pełni zaktualizowany WordPress nie chroni, jeśli sama wtyczka Bookly jest w podatnej wersji.
Czy ta wiadomość jest wiarygodna?
Tak. To zgłoszenie w duchu odpowiedzialnego ujawniania, w dobrej wierze, od niezależnego badacza bezpieczeństwa. Nie proszę o pieniądze, hasła ani dostęp do witryny i nie próbowałem się do niej włamać, niczego do niej wysłać ani niczego wykorzystać.
Obejrzałem wyłącznie publicznie dostępne pliki, które Państwa witryna udostępnia każdemu odwiedzającemu (tak samo jak publiczna jest strona główna), i odnotowałem numer wersji publikowany przez wtyczkę Bookly. W szczególności nie wysłałem niczego do formularza rezerwacji ani do ścieżki żądania, której dotyczy problem, a to sprawdzenie nie dotyka Państwa danych, panelu administracyjnego ani żadnej prywatnej części witryny (więcej w sekcji Co zrobiłem, a czego nie).
Jeśli chcą Państwo zweryfikować, kim jestem, dane kontaktowe znajdują się na dole tej strony oraz na stronie O mnie.
Dlaczego to ważne
Bookly to jedna z najpopularniejszych wtyczek do rezerwacji wizyt dla WordPressa: w oficjalnym katalogu od 2014 r., działająca na dziesiątkach tysięcy witryn. Publikuje na publicznej części witryny formularz rezerwacji, dzięki któremu odwiedzający wybierają usługę, pracownika i termin bez zakładania konta.
W podatnych wersjach jedna z wartości odsyłanych przez ten formularz, identyfikator wybranego pracownika, jest zapisywana dokładnie w takiej postaci, w jakiej przychodzi, bez sprawdzenia, a później wstawiana wprost do zapytania do bazy danych zamiast być przekazana jako parametr. Ktoś, kto wyśle spreparowaną wartość zamiast zwykłego identyfikatora, może więc zmienić sens tego zapytania. Praktyczny skutek: osoba bez konta i bez logowania mogłaby odczytać z bazy danych witryny dane, których zapytanie nigdy nie miało zwracać, w tym skróty (hasze) haseł kont WordPressa.
Dwie rzeczy trzeba powiedzieć wprost, w obie strony.
Po pierwsze, dla zachowania proporcji: to problem odczytu danych, a nie przejęcia serwera ani konta administratora. Sam w sobie nie pozwala uruchomić kodu na serwerze ani zalogować się do panelu. Skrót hasła to nie hasło; trzeba go najpierw złamać, by stał się dostępem. I nie ma dowodów wykorzystania: instytucja, która przydzieliła CVE, nie opublikowała oceny istotności, luka nie figuruje w katalogu KEV amerykańskiej CISA, jej wskaźnik prawdopodobieństwa wykorzystania (EPSS) nie został przypisany, a mnie nie są znane żadne doniesienia o wykorzystaniu.
Po drugie, bez umniejszania: ani logowanie, ani token nonce, ani żadne ustawienie wtyczki nie stoi między anonimowym odwiedzającym a tą ścieżką. Jest ona osiągalna w domyślnej instalacji darmowej wtyczki. Dlatego zalecenie brzmi: zaktualizować szybko, a nie odkładać do następnego okna serwisowego.
Jeśli mój e-mail powoływał się na ten problem, oznacza to, że wersja zgłaszana przez Państwa witrynę mieści się w podatnym zakresie. Nie sprawdzałem, czy akurat Państwa witryna jest podatna na wykorzystanie; zaobserwowałem wyłącznie wersję.
Czy mnie to dotyczy?
Wszystko sprowadza się do jednego pytania: jakiej wersji Bookly Państwo używają? Nie trzeba wierzyć mi na słowo; są dwa sposoby sprawdzenia.
W panelu administracyjnym WordPressa (źródło rozstrzygające):
- Proszę zalogować się do kokpitu WordPressa (zwykle
Państwadomena.pl/wp-admin). - Przejść do Wtyczki, a następnie Zainstalowane wtyczki.
- Odnaleźć Bookly, pozycję, której katalog to
bookly-responsive-appointment-booking-tool, i odczytać wersję pod nazwą.
Z publicznego manifestu (bez logowania): proszę otworzyć w przeglądarce
Państwadomena.pl/wp-content/plugins/bookly-responsive-appointment-booking-tool/readme.txt.
Wiersz Stable tag: blisko początku to wersja zgłaszana przez instalację; to ten sam
publiczny plik, który odczytałem.
Następnie proszę zastosować tę regułę, pamiętając, że wersje porównuje się liczbowo, a nie alfabetycznie:
- Od 11.3 do 27.7: podatna. Proszę zaktualizować teraz.
- 27.8 lub nowsza: już naprawiona. Dotyczy to również 27.9, która zachowuje poprawkę.
- Starsza niż 11.3: nieobjęta tym problemem. Niebezpieczna konstrukcja zapytania w tych wydaniach nie istniała: identyfikatory pracowników przechodziły przez parametryzowany konstruktor zapytań wtyczki. Tak stare wydanie ma wiele innych powodów do aktualizacji, ale to powiadomienie nie jest jednym z nich.
- Proszę nie czytać numerów wersji jak tekstu. Bookly ma dwucyfrowy numer główny, więc
porządek tekstowy myli dwukrotnie:
3.3wygląda na większe niż27.8, choć jest znacznie starsze, a27.10wygląda na mniejsze niż27.7, choć jest nowsze. Proszę porównywać liczba po liczbie.
Uwaga o dodatkach do Bookly. Płatne rozszerzenia Bookly (Pro oraz różne pakiety
bookly-addon-*) instalują się jako osobne wtyczki z własnymi numerami wersji, a adresy
ich plików mogą nieść wersję wtyczki głównej zamiast własnej. Dla tego powiadomienia liczy się
wersja głównej wtyczki Bookly, ustalona jednym z dwóch powyższych sposobów, a nie numer
odczytany z plików dodatku.
Jeśli z zewnątrz nie widać żadnych plików Bookly. Bookly ma ustawienie decydujące o tym, czy jego skrypty i style ładują się na każdej stronie, czy tylko na tych z formularzem rezerwacji. Jeśli wybrana jest druga opcja, z zewnątrz widać znacznie mniej wtyczki. To ustawienie wpływa wyłącznie na to, co odwiedzający może zobaczyć; nie ma znaczenia dla tego, czy luka jest obecna i osiągalna. Proszę sprawdzić wersję w panelu.
Jak zaktualizować
Najbezpieczniej jest zaktualizować przez samego WordPressa, po wcześniejszej kopii zapasowej:
- Proszę wykonać kopię zapasową (pliki i baza danych) przed wprowadzeniem zmian. Większość firm hostingowych oferuje kopie jednym kliknięciem, można też użyć wtyczki do kopii zapasowych.
- W panelu WordPressa proszę przejść do Kokpit, a następnie Aktualizacje, albo do Wtyczki i Zainstalowane wtyczki. Jeśli widnieje aktualizacja Bookly, proszę zainstalować ją stamtąd.
- Kto woli wiersz poleceń, WP-CLI robi to samo:
wp plugin update bookly-responsive-appointment-booking-tool. - Jeśli aktualizacja się nie pojawia, najnowsze wydanie można pobrać bezpośrednio ze strony wtyczki w katalogu WordPress.org, Bookly, i zaktualizować przez Wtyczki, Dodaj wtyczkę, Wyślij wtyczkę na serwer.
- Po aktualizacji proszę potwierdzić nowy numer wersji (27.8 lub nowszy) powyższymi krokami i sprawdzić, czy formularz rezerwacji oraz istniejące wizyty działają normalnie.
Jeśli korzystają Państwo z płatnych dodatków Bookly, proszę zaktualizować je razem z wtyczką główną; ich wydania są zwykle powiązane.
Przy okazji warto potwierdzić, że rdzeń WordPressa i pozostałe wtyczki są aktualne, bo ta sama zasada dotyczy wszystkich.
Po aktualizacji
Przejście na 27.8 lub nowszą zamyka problem, a ponieważ nic nie wskazuje, by luka była gdziekolwiek wykorzystana, nie jest to sytuacja awaryjna: nie trzeba traktować witryny jako naruszonej ani wyłączać jej.
Jeden krok warto jednak faktycznie wykonać i wynika on wprost z tego, co ta luka mogła osiągnąć. Ponieważ skróty haseł WordPressa znajdowały się wśród danych, które zapytanie mogło zwrócić, a wcześniej przechwycony skrót pozostaje przydatny atakującemu również po aktualizacji, rozsądnym zabezpieczeniem jest zresetowanie haseł kont administratorów po wgraniu aktualizacji. Dwa mniejsze kroki dobrze to uzupełniają:
- Proszę przejrzeć konta administratorów i redaktorów pod kątem takich, których Państwo nie rozpoznają, tak jak zwykle przegląda się dostęp do witryny.
- Proszę wygenerować na nowo klucze i „sole” WordPressa w
wp-config.php(nowe wartości są o jedno kliknięcie w oficjalnym generatorze; ich wymiana jednorazowo wylogowuje wszystkich użytkowników).
Proszę potraktować to jako zwykłą higienę bezpieczeństwa, a nie reagowanie na incydent.
Co zrobiłem, a czego nie
Dla pełnej przejrzystości co do sprawdzenia stojącego za moim e-mailem: odczytałem wyłącznie
publiczne pliki, które Państwa witryna i tak udostępnia każdemu odwiedzającemu, konkretnie
publiczny readme.txt wtyczki Bookly oraz stronę główną. Nie uzyskałem dostępu do panelu
administracyjnego WordPressa, do bazy danych ani do żadnej prywatnej części witryny.
W szczególności nigdy nie wysłałem niczego do formularza rezerwacji ani do ścieżki żądania, której dotyczy problem; nic nie zostało przesłane, przetestowane ani wykorzystane. Tutaj waży to więcej niż na większości tych stron: luka jest nieuwierzytelnionym żądaniem do tej ścieżki, więc „nie dotknąłem jej” stanowi całą różnicę między ujawnieniem a włamaniem.
To obserwacja oparta na wersji: Państwa witryna zgłasza wersję z podatnego zakresu. Witryna w tym zakresie może już być chroniona w inny sposób, na przykład zaporą aplikacji webowych lub poprawką zaaplikowaną wstecznie. To powiadomienie nie twierdzi, że Państwa witryna była podatna na wykorzystanie w chwili sprawdzenia.
Nie mam webmastera / utknąłem
Jeśli nie zajmują się Państwo witryną osobiście, proszę przekazać tę stronę osobie, która to robi (deweloperowi, agencji lub firmie hostingowej). Powyższe kroki rozpozna od razu.
Jeśli utrzymują Państwo witrynę samodzielnie i utknęli, chętnie bezpłatnie wskażę właściwy kierunek. Proszę napisać, korzystając z danych kontaktowych poniżej.
Kontakt
Evan Harris, badacz bezpieczeństwa
- E-mail: security@mail.mcpsec.dev
- X: @Evan__Harris
- GitHub: eharris128
- LinkedIn: Evan Harris
Kontaktuję się w takich sprawach wyłącznie po to, by pomóc operatorom zabezpieczyć ich witryny. Jeśli wolą Państwo nie otrzymywać kolejnych wiadomości, proszę dać znać; uszanuję to.
Źródła
Oficjalne komunikaty i śledzenie
Producent / wtyczka