podatność wykorzystywana bez uwierzytelnienia

Podatność wykorzystywana bez uwierzytelnienia to podatność, którą atakujący może wykorzystać, nie mając konta w systemie i nie logując się. W skali CVSS odpowiada jej wartość „None” metryki Privileges Required: atakujący przed atakiem nie ma żadnych uprawnień ani dostępu do ustawień i plików podatnego systemu ^[1]. Taka luka jest groźniejsza od błędów wymagających konta, bo krąg możliwych napastników obejmuje każdego, kto może wysłać żądanie do serwera. W opisach podatności pojawia się zwykle jako określenie „bez uwierzytelnienia” albo „nieuwierzytelniony atakujący”.

Jak działa

Uwierzytelnianie odpowiada na pytanie, kim jest użytkownik, a autoryzacja na pytanie, co wolno mu zrobić. Luka bez uwierzytelnienia pojawia się, gdy funkcja, która powinna wymagać potwierdzonej tożsamości, jest dostępna dla każdego. MITRE opisuje ten błąd jako CWE-306: produkt nie wykonuje uwierzytelnienia dla funkcji, która wymaga potwierdzonej tożsamości użytkownika albo zużywa dużo zasobów ^[2]. Skutek MITRE ujmuje krótko: odsłonięcie krytycznej funkcji daje atakującemu poziom uprawnień tej funkcji ^[2].

Nie każda luka bez uwierzytelnienia wynika z braku logowania w kodzie. Często funkcja jest celowo publiczna, na przykład wyszukiwarka czy formularz kontaktowy, a błąd tkwi w tym, co robi z danymi. Wtedy klasa błędu jest inna, na przykład SQL injection albo path traversal, ale warunek wykorzystania pozostaje ten sam: wystarczy żądanie HTTP.

Schemat poniżej pokazuje typowy przebieg ataku na publiczny punkt końcowy.

RYS. 1Atak bez uwierzytelnienia

Poziomy wymaganych uprawnień

Specyfikacja CVSS 3.1 dzieli wymagane uprawnienia na trzy poziomy ^[1]. Od poziomu zależy, jak wielu ludzi może lukę wykorzystać.

Metryka Attack Vector o wartości Network opisuje z kolei lukę, którą da się wykorzystać zdalnie, przez sieć ^[1]. Połączenie obu wartości, dostępu sieciowego i braku wymaganych uprawnień, oznacza lukę dostępną dla każdego w internecie.

W WordPressie

Strona WordPress ma kilka miejsc, w których kod wtyczek i motywów obsługuje żądania anonimowych gości. To one są głównym źródłem luk bez uwierzytelnienia; zob. podatność we wtyczce.

Akcje AJAX. Hak wp_ajax_nopriv_{$action} uruchamia akcje AJAX dla użytkowników niezalogowanych ^[4]. Jeśli wtyczka podepnie pod niego funkcję zapisującą ustawienia albo pliki i nie sprawdzi uprawnień, dowolna osoba może ją wywołać. Nonce nie zastępuje tu kontroli uprawnień, bo nie potwierdza tożsamości użytkownika.

REST API. Każdy własny punkt końcowy REST ma funkcję permission_callback, która sprawdza, czy użytkownik może wykonać daną akcję ^[5]. Dla punktów publicznych dokumentacja dopuszcza __return_true, a od wersji 5.5 WordPress ostrzega, gdy tego argumentu brakuje ^[5]. Dokumentacja zaleca sprawdzanie current_user_can() zamiast samego faktu zalogowania ^[5]. Pomyłka w tym miejscu daje niezabezpieczony endpoint REST API.

Rdzeń. Luki bez uwierzytelnienia zdarzają się także w samym WordPressie. Przykład z 2026 roku opisuje ostatnia sekcja.

Zagrożenia i skutki

Brak bariery logowania sprawia, że lukę można wykorzystywać masowo. Wystarczy lista adresów stron z podatną wersją i automat, który wysyła żądania; skanowanie internetu pod kątem konkretnej luki nie wymaga żadnych danych o ofiarach. Skutek zależy od klasy błędu. MITRE wymienia dla CWE-306 odczyt i zmianę danych oraz wykonanie dowolnego kodu ^[2].

• Zdalne wykonanie kodu (RCE) i instalacja webshella.
• Utworzenie nieautoryzowanego konta administratora.
• Wgranie dowolnego pliku (arbitrary file upload) albo jego usunięcie.
• Odczyt danych z bazy, w tym danych klientów sklepu.

W zestawieniu CWE Top 25 za 2025 rok słabość CWE-306 zajęła 21. miejsce, a pokrewny brak autoryzacji, CWE-862, miejsce 4. ^[3].

Jak się bronić

MITRE zaleca podział aplikacji na strefy: anonimową, zwykłą, uprzywilejowaną i administracyjną, z jednym, scentralizowanym mechanizmem uwierzytelniania ^[2]. Zaleca też, by kontrole wykonywane po stronie klienta powtarzać na serwerze i korzystać ze sprawdzonych bibliotek zamiast własnych rozwiązań ^[2].

Dla właściciela strony najważniejsza jest szybka łatka (patch). Luki bez uwierzytelnienia są pierwsze na liście do aktualizacji, bo okno między publikacją poprawki a pierwszymi atakami bywa krótkie. Do czasu aktualizacji ryzyko może zmniejszyć WAF z regułą blokującą znany wzorzec ataku, czyli wirtualne patchowanie (virtual patching). Pomaga też ograniczanie powierzchni ataku: usuwanie nieużywanych wtyczek zmniejsza liczbę publicznych punktów końcowych.

Historia i przykłady

22 września 2026 roku WordPress wydał wersję 7.1.2 z poprawką luki CVE-2026-87902 ^[6]. Według komunikatu nieuwierzytelniony atakujący mógł w pewnych warunkach doprowadzić do dołączenia czytelnego lokalnego pliku PHP spoza katalogów aktywnego motywu, co mogło skończyć się zdalnym wykonaniem kodu ^[6]. Podatne były wersje od 4.7 do 7.1.1, a poprawkę przeniesiono do wszystkich gałęzi otrzymujących poprawki bezpieczeństwa ^[6]. Help Net Security podkreślił, że atakujący nie potrzebował konta na stronie ani działania kogokolwiek, kto je ma; lukę oceniono na 9,2 w CVSS 4.0 ^[7]. Dwa dni po wydaniu poprawki serwis donosił o aktywnym wykorzystywaniu luki i o publicznie dostępnych narzędziach do skanowania ^[7]. 25 września 2026 roku CISA dodała CVE-2026-87902 do katalogu KEV ^[8].