Niski Odebrany

CVE-2026-82898

opublikowano: 01.11.2026, 23:17

modyfikacja: 01.11.2026, 23:17

Ocena CVSS

2.1

Niski · v4.0

Oficjalne źródła

wektor: CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:A/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

>_ Opis

Tłumaczenie automatyczne – może zawierać nieścisłości.

Nieprawidłowa kolejność kontroli bezpieczeństwa w Apache Wicket.

org.apache.wicket.protocol.http.ResourceIsolationRequestCycleListener uzyskuje stronę, do której kierowane jest żądanie, zanim zapozna się ze swoimi zasadami izolacji zasobów, ponieważ te zasady są przekazywane tej stronie. Uzyskanie strony powoduje jej utworzenie, a utworzenie instancji strony uruchamia skonfigurowaną metodę org.apache.wicket.authorization.IAuthorizationStrategy. Aplikacja, która odrzuca nieuwierzytelnionego gościa, zgłaszając wyjątek org.apache.wicket.RestartResponseAtInterceptPageException, wyrzuca go zatem z wnętrza odbiornika izolacji, zanim jakakolwiek polityka zostanie uruchomiona. Wyjątek ten zastępuje osobę zajmującą się obsługą wniosków, zatem nigdy nie konsultuje się zasad i wniosek, który pochodzi z innego źródła, nie jest odrzucany.

Konstruktor wyjątku przechowuje adres URL żądania, które przerwał, dzięki czemu Component#continueToOriginalDestination() może je wznowić po zalogowaniu się odwiedzającego. Zapisany adres URL to ten, który zostałby odrzucony przez zasady. Po zalogowaniu się Wicket przekierowuje do niego, a przekierowanie to ma to samo pochodzenie, więc zasady na to pozwalają, a słuchacz działa w nowo uwierzytelnionej sesji. Cały adres URL jest przechowywany wraz z ciągiem zapytania, więc zwykły org.apache.wicket.markup.html.form.Form jest wznawiany z wartościami pól, które oryginalne żądanie zawierało w ciągu zapytania, a Form#onSubmit() działa z wartościami wybranymi przez inne źródło. Formularz POST nie jest do tego potrzebny; przenosi je zwykła nawigacja najwyższego poziomu.

Na aplikację wpływa to, gdy rejestruje ResourceIsolationRequestCycleListener, który jest opcjonalny i domyślnie nie jest zarejestrowany, oraz gdy odmawia nieautoryzowanego dostępu za pomocą wyjątku RestartResponseAtInterceptPageException, po którym następujecontinuToOriginalDestination(). Na tej ścieżce nie jest stosowane żadne zastąpienie aplikacji: dokumenty IAuthorizationStrategy#isInstantiationAuthorized() zgłaszają ten wyjątek, org.apache.wicket.authroles.authentication.AuthenticatedWebApplication zgłasza go, a org.apache.wicket.authroles.authentication.panel.UsernamePasswordPanel kontynuuje podróż do pierwotnego miejsca docelowego oraz org.apache.wicket.authorization.strategies.page.SimplePageAuthorizationStrategy w wicket-core instaluje ten sam wzorzec. Nie ma to wpływu na gościa, który jest już zalogowany, ponieważ nie następuje przechwycenie. Parametry treści żądania przechowywane wraz z przechwyconym adresem URL nie są stosowane do wznowionego formularza: wznowienie jest przekierowaniem, więc wznowione żądanie to GET, a komponenty formularza odczytują swoje wartości z ciągu zapytania w GET.

Aby obejść ten problem, odmów nieautoryzowanego dostępu za pomocą wyjątku org.apache.wicket.RestartResponseException, który nie przechowuje pierwotnego miejsca docelowego; odwiedzający nie wracają wówczas na stronę, o którą prosili po zalogowaniu.

Ten problem dotyczy Apache Wicket: od 9.1.0 do 9.24.0, od 10.0.0 do 10.11.0.

Nie ma to wpływu na wydania wcześniejsze niż 9.1.0, czyli każde wydanie 8.x i 9.0.0, ponieważ izolacja zasobów, której dotyczy ten problem, została wprowadzona w wersji 9.1.0. Nie są też objęte ochroną. Ich jedyną obroną między źródłami jest org.apache.wicket.protocol.http.CsrfPreventionRequestCycleListener, która sprawdza, skąd pochodzi żądanie, czytając nagłówek Origin i wracając do nagłówka Referer. Żaden nagłówek nie musi dotrzeć: przeglądarka nie wysyła Origin na zwykłym GET, z którego korzysta łącze, a dokument z drugiego źródła decyduje, poprzez swoją własną politykę dotyczącą stron odsyłających, czy osoba odsyłająca w ogóle dotrze do aplikacji. Dlatego też mechanizm ten nigdy nie zapewniał gwarancji, jaką zapewnia polityka oparta na pobieraniu metadanych, a w przypadku tych wersji wywołanie odbiornika z innego źródła nie jest przede wszystkim niezawodnie odrzucane. Każdy, kto korzysta z wersji wcześniejszej niż 9.1.0 i chce tej ochrony, powinien dokonać aktualizacji do wersji 9.x lub 10.x i zarejestrować ResourceIsolationRequestCycleListener.

Użytkownikom zaleca się aktualizację do wersji 9.25.0 lub 10.12.0, która rozwiązuje problem.

Incorrect order of security checks in Apache Wicket.

org.apache.wicket.protocol.http.ResourceIsolationRequestCycleListener obtains the page a request targets before it consults its resource isolation policies, because those policies are passed that page. Obtaining the page instantiates it, and instantiating a page runs the configured org.apache.wicket.authorization.IAuthorizationStrategy. An application that refuses an unauthenticated visitor by throwing org.apache.wicket.RestartResponseAtInterceptPageException therefore throws it from inside the isolation listener, before any policy has run. That exception replaces the request handler, so the policies are never consulted and a request that came from another origin is not refused.

The exception's constructor stores the URL of the request it interrupted, so that Component#continueToOriginalDestination() can resume it once the visitor has signed in. The stored URL is the one the policies would have refused. On sign in Wicket redirects to it, and that redirect is same-origin, so the policies allow it and the listener runs in the newly authenticated session. The whole URL is stored, its query string included, so an ordinary org.apache.wicket.markup.html.form.Form is resumed with the field values the original request carried in its query string and Form#onSubmit() runs with values another origin chose. A form POST is not needed for this; a plain top-level navigation carries them.

An application is affected where it registers ResourceIsolationRequestCycleListener, which is opt-in and is not registered by default, and where it refuses unauthorized access with RestartResponseAtInterceptPageException followed by continueToOriginalDestination(). No application override is involved on that path: IAuthorizationStrategy#isInstantiationAuthorized() documents throwing that exception, org.apache.wicket.authroles.authentication.AuthenticatedWebApplication throws it and org.apache.wicket.authroles.authentication.panel.UsernamePasswordPanel continues to the original destination, and org.apache.wicket.authorization.strategies.page.SimplePageAuthorizationStrategy in wicket-core installs the same pattern. A visitor who is already signed in is not affected, because no interception occurs. Request-body parameters stored alongside the intercepted URL are not applied to the resumed form: the resumption is a redirect, so the resumed request is a GET, and form components read their values from the query string on a GET.

As a workaround, refuse unauthorized access with org.apache.wicket.RestartResponseException instead, which does not store the original destination; visitors are then not returned to the page they asked for after signing in.

This issue affects Apache Wicket: from 9.1.0 through 9.24.0, from 10.0.0 through 10.11.0.

Releases before 9.1.0, which is every 8.x release and 9.0.0, are not affected, because the resource isolation this issue concerns was introduced in 9.1.0. They are not protected either. Their only cross-origin defence is org.apache.wicket.protocol.http.CsrfPreventionRequestCycleListener, which works out where a request came from by reading its Origin header and falling back to its Referer header. Neither header need arrive: a browser does not send Origin on the plain GET a link uses, and the document on the other origin decides through its own referrer policy whether a Referer reaches the application at all. That mechanism therefore never made the guarantee the Fetch Metadata based policy makes, and on those releases a listener invocation from another origin is not reliably refused in the first place. Anyone on a release before 9.1.0 who wants this protection should upgrade to 9.x or 10.x and register ResourceIsolationRequestCycleListener.

Users are recommended to upgrade to version 9.25.0 or 10.12.0, which fix the issue.

>_ Słabości (CWE)

CWE-696

>_ Referencje

https://lists.apache.org/thread.html/bm4mlwsgftxfg345zvdqj0skg1mktpyp

Dane podatności pochodzą z oficjalnych źródeł (CVE® List / NVD). Opisy po polsku są tłumaczone automatycznie i mogą zawierać nieścisłości – na stronie rekordu można wyświetlić wersję angielską.

This product uses the NVD API but is not endorsed or certified by the NVD.

CVE Usage: MITRE hereby grants you a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute Common Vulnerabilities and Exposures (CVE®). Any copy you make for such purposes is authorized provided that you reproduce MITRE's copyright designation and this license in any such copy. ALL DOCUMENTS AND THE INFORMATION CONTAINED THEREIN PROVIDED BY MITRE ARE PROVIDED ON AN "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND.

NVD Terms of Use / CVE® Terms of Use / nvd.nist.gov / cve.org

<< baza_cve