Nie każda usterka wpisana do katalogu potwierdzonych ataków robi coś sama z siebie. CVE-2026-63030 jest tego przykładem: dotyczy rdzenia WordPressa, polega na pomyleniu trasy w zbiorczym punkcie końcowym interfejsu REST API i sama nie prowadzi do wykonania kodu. Ten wpis wyjaśnia, czym jest ten punkt końcowy i na czym polega pomylenie trasy, dlaczego klasa CWE-436 opisuje wyjątkowo podstępną rodzinę błędów, skąd wzięły się dwie oceny różniące się o 2,3 punktu w jednym rekordzie i dlaczego agencja dała na tę usterkę trzy dni, a na tę, z którą się ją łączy, czternaście.
Zbiorczy punkt końcowy i pomylenie trasy
REST API WordPressa to zestaw adresów, pod które aplikacja przyjmuje żądania i zwraca dane w postaci nadającej się do przetworzenia przez program. Każdy taki adres to trasa, a do każdej trasy przypięte są sprawdzenia: kto pyta, czy wolno mu to zrobić i jakie parametry są dopuszczalne.
Zbiorczy punkt końcowy, po angielsku batch, to trasa specjalna. Przyjmuje w jednym żądaniu listę wielu żądań naraz i wykonuje je po kolei, po to, żeby aplikacja działająca w przeglądarce nie musiała wysyłać dwudziestu osobnych zapytań. Wewnątrz jednego żądania siedzi więc opis kilku innych, a serwer musi każde z nich rozłożyć, dopasować do właściwej trasy i uruchomić właściwe sprawdzenia.
Pomylenie tras, po angielsku route confusion, polega na tym, że ten krok dopasowania idzie inaczej, niż zakładała warstwa sprawdzająca uprawnienia. Żądanie zostaje przypisane do jednej trasy przy sprawdzaniu, a wykonane jako inna. Efekt jest taki, że kontrola przepuszcza coś, czego nie zamierzała przepuścić, mimo że sama działa poprawnie w swoim rozumieniu sytuacji.
Nie potwierdzono, na czym dokładnie to pomylenie polega ani jak omija kontrolę uprawnień. Zaawansowany opis techniczny leży w poradniku, który nie przeszedł weryfikacji źródeł, więc dostępne materiały podają wyłącznie skutek.
CWE-436, czyli dwie warstwy czytają to samo inaczej
Przypisana klasa słabości to CWE-436, czyli konflikt interpretacji. To rodzina błędów rzadsza w zestawieniach niż wstrzyknięcia czy przepełnienia bufora, za to szczególnie kłopotliwa w diagnozie.
Konflikt interpretacji zachodzi wtedy, gdy dwie warstwy przetwarzające to samo żądanie rozumieją je inaczej. Żadna z nich nie jest sama w sobie napisana źle. Filtr czyta adres i stwierdza, że mowa o zasobie A, do którego pytający ma prawo. Warstwa wykonawcza czyta ten sam adres i sięga po zasób B, do którego prawa nie ma. Błąd nie siedzi więc w żadnym z tych dwóch kawałków kodu, tylko w przestrzeni między nimi, i dlatego przegląd każdego z osobna niczego nie wykaże.
Ta sama klasa opisuje między innymi przemyt żądań przez serwery pośredniczące, czyli sytuacje, w których zapora widzi jedno, a serwer aplikacyjny drugie. Wspólny mianownik jest zawsze ten: zabezpieczenie działa dokładnie tak, jak zaprojektowano, tylko na innym obrazie rzeczywistości niż ten, który wykonuje pracę.
Katalog agencji CISA prowadzi wpis pod nazwą WordPress Core Interpretation Conflict Vulnerability, czyli nazywa problem po klasie, a nie po skutku. To rzadkie i dobrze oddaje charakter sprawy.
9,8 czy 7,5, czyli co dokładnie się ocenia
Rekord w bazie amerykańskiej niesie dwie oceny w skali CVSS 3.1 i różnią się one o 2,3 punktu.
WPScan, występujący tu jako jednostka nadająca numer, wystawił 9,8 punktu przy wektorze CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, czyli z wysokim wpływem na poufność, integralność i dostępność naraz. Program ADP prowadzony przez agencję CISA wystawił 7,5 punktu przy wektorze CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N, czyli ograniczył wpływ wyłącznie do poufności. Baza amerykańska nie wystawiła własnej oceny podstawowej, więc obie liczby są ocenami wtórnymi stojącymi obok siebie.
Warunki wstępne obie strony opisują identycznie: sieć, niska złożoność, zero uprawnień, zero interakcji. Cała różnica siedzi w skutkach i najbardziej prawdopodobne wyjaśnienie jest takie, że jedna ocena opisuje sam błąd, a druga cały łańcuch. Ocena krytyczna odpowiada sytuacji, w której pomylenie tras zostaje użyte razem z partnerem i kończy się wykonaniem kodu, czyli pełnym wpływem na wszystkie trzy właściwości. Ocena niższa odpowiada temu, co ta usterka robi sama: otwiera dostęp, ale niczego nie zmienia ani nie zatrzymuje. Rozbieżności nie wyjaśniono w żadnym ze źródeł, więc jest to odczytanie prawdopodobne, a nie potwierdzone.
Tomasz Kaczmarek
Mogę Ci jakoś pomóc?
Ocena SSVC wykonana przez koordynatora z agencji CISA klasyfikuje eksploatację jako aktywną, automatyzowalność jako możliwą, a wpływ techniczny jako całkowity, czyli staje po stronie wyższej liczby.
Łańcuch z drugą luką i podział ról
Opis w bazie amerykańskiej stawia sprawę wprost: sama ta usterka nie daje wykonania kodu, dopiero połączona z CVE-2026-60137 prowadzi do wstrzyknięcia SQL i zdalnego wykonania kodu. Partnerem jest wstrzyknięcie SQL przez parametr author__not_in w klasie WP_Query, czyli w tej części rdzenia, która buduje zapytania po wpisy.
Katalog agencji potwierdza możliwość złączenia obu i wskazuje skutek: zdalne wykonanie kodu na domyślnych instalacjach WordPressa przez nieuwierzytelnionego napastnika.
Podział ról jest w tym łańcuchu wyraźny. Partner, czyli wstrzyknięcie SQL, potrzebuje warunku: wtyczka albo motyw musi przekazać do podatnego parametru dane pochodzące z niezaufanego wejścia. Pomylenie tras dostarcza natomiast ścieżki, którą napastnik dociera do miejsca, gdzie ten parametr da się podać. Dlatego opis mówi o domyślnych instalacjach, mimo że partner sam z siebie ma warunek dodatkowy: to ta luka usuwa warunek, bo prowadzi przez kod będący częścią rdzenia, a nie wtyczki.
Nie potwierdzono jednak, czy do wykorzystania łańcucha obecność konkretnej wtyczki jest naprawdę zbędna, ani które wtyczki lub motywy w praktyce dostarczają niezaufane dane wymagane przez partnera. To dwa pytania, na które żadne dostępne źródło nie odpowiada, a od nich zależy realny zasięg całej sprawy.
Dwie gałęzie i granica, poniżej której problem nie sięga
Objęte problemem są gałąź 6.9 przed wersją 6.9.5 oraz gałąź 7.0 przed 7.0.2. Konfiguracja maszynowa w bazie amerykańskiej wyznacza dokładnie te dwa przedziały, a baza europejska prowadzona przez ENISA podaje jako wersje naprawione 6.9.5 dla gałęzi starszej i 7.0.2 dla bieżącej.
Godna uwagi jest granica dolna, bo zachowuje się inaczej niż przy partnerze z łańcucha. Wstrzyknięcie SQL obejmuje trzy gałęzie, sięgając wstecz do 6.8, a pomylenie tras zaczyna się dopiero od 6.9. Wydania starsze niż 6.9 nie są podatne, ponieważ podatny kod wprowadzono później, co odnotowuje mechanizm śledzenia bezpieczeństwa w Debianie dla wydań bullseye, bookworm i trixie. To informacja o średniej pewności, ale spójna z resztą danych.
Wniosek praktyczny jest nieoczywisty i wart odnotowania. Instalacja stojąca na gałęzi 6.8 jest podatna na wstrzyknięcie SQL, ale nie ma ogniwa otwierającego, więc łańcuch prowadzący do wykonania kodu jej nie dotyczy. Instalacja na 6.9 albo 7.0 ma oba ogniwa naraz. Starsza gałąź nie jest przez to bezpieczna, ale profil ryzyka ma inny, a to zmienia kolejność prac przy większej liczbie stron do obsłużenia.
Dat wydania wersji 6.9.5 i 7.0.2 nie potwierdzono u producenta, bo jego serwis nie przeszedł weryfikacji źródeł. Nie potwierdzono również żadnego obejścia, w szczególności tego, czy wyłączenie zbiorczego punktu końcowego REST API skutecznie rozbraja problem. To pierwsze, co przychodzi do głowy, i właśnie dlatego warto zaznaczyć, że nie ma na to potwierdzenia.
Trzy dni, spadający wskaźnik i lista niewiadomych
Rekord opublikowano w bazie amerykańskiej 17 lipca 2026, ostatnia modyfikacja to 22 lipca 2026, a stan analizy to Analyzed. Do katalogu potwierdzonych ataków usterka trafiła 21 lipca 2026, czyli cztery dni po publikacji rekordu, komunikatem o dodaniu czterech pozycji, w którym znalazły się obie luki tego łańcucha.
Terminy naprawy dostały różne i różnica jest tu najciekawszym szczegółem całej sprawy. Ta usterka ma termin 24 lipca 2026, czyli trzy dni. Partner, czyli wstrzyknięcie SQL, ma 4 sierpnia 2026, czyli czternaście. Agencja uznała więc ogniwo otwierające drogę za pilniejsze niż ogniwo dające skutek, choć to drugie brzmi groźniej w opisie. Logika jest operacyjna: zamknięcie wejścia rozbraja cały łańcuch, nawet jeśli druga luka pozostanie na miejscu.
Wskaźnik EPSS, szacujący prawdopodobieństwo próby wykorzystania w ciągu trzydziestu dni, wynosi 0,95605 przy percentylu 0,99867 w pomiarze z 23 sierpnia 2026. Warto zestawić to z wartością dla partnera, która wynosi 0,73100, czyli wyraźnie niżej. Model przewidujący ataki wskazuje więc na to samo ogniwo, co agencja przy wyznaczaniu terminów.
Tomasz Kaczmarek
Mogę Ci jakoś pomóc?
Sam szereg czasowy pokazuje przy tym ruch w dół: 26 lipca 2026 wskaźnik wynosił 0,98051, a do 23 sierpnia zsunął się do 0,95605. Wpis do katalogu potwierdzonych ataków nie podniósł oceny, tylko lekko ją obniżył. To dobra ilustracja tego, że model liczy obserwowaną aktywność, a nie status administracyjny, i że po pierwszej fali prób aktywność zwykle opada.
Pole opisujące użycie w kampaniach szyfrujących dane dla okupu ma wartość mówiącą o braku ustaleń, i to samo dotyczy obu ogniw łańcucha. Nie potwierdzono, jaki aktor ani jaka kampania z tego korzysta, mimo że ocena SSVC opisuje eksploatację jako aktywną. Baza europejska prowadzi sprawę pod numerem EUVD-2026-45280, z przypisaniem po stronie WPScan i datą początku wykorzystania ustawioną na 21 lipca 2026, czyli przepisaną z katalogu amerykańskiego.