Średni Odebrany

CVE-2026-82704

opublikowano: 01.11.2026, 23:17

modyfikacja: 01.11.2026, 23:17

Ocena CVSS

6.9

Średni · v4.0

Oficjalne źródła

wektor: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/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.

Brak autoryzacji w Apache Wicket.

org.apache.wicket.core.request.handler.ListenerRequestHandler wywołuje IRequestListener tylko wtedy, gdy org.apache.wicket.Component#canCallListener() na to pozwala, a tą metodą jest isEnabledInHierarchy() && isVisibleInHierarchy(). Połowa widoczności odczytuje flagę, która przenosi wynik IAuthorizationStrategy#isActionAuthorized() dla akcji Component.RENDER i ta flaga jest zapisywana tylko w jednym miejscu, Component#configure(), podczas fazy renderowania. Adres URL odbiornika zbudowany przez podklasę org.apache.wicket.core.request.mapper.AbstractBookmarkableMapper zawiera identyfikator strony i ścieżkę komponentu w jednym parametrze, a identyfikator strony może być pusty. Gdy tak jest, tworzona jest nowa instancja strony, PageProvider#wasExpired() ma wartość false, ponieważ nie podano identyfikatora, a PageAndComponentProvider#getComponent() znajduje komponent bezpośrednio w nowej instancji, więc ani przebieg renderowania, ani Component#configure() nie są uruchamiane przed wywołaniem detektora. Dlatego flaga nadal zachowuje domyślny konstruktor, komponent liczy się jako widoczny i wykonywany jest słuchacz komponentu, dla którego strategia autoryzacji odmówiła RENDER. To samo żądanie pomija również Component#onConfigure(), więc widoczność i włączanie zestawów aplikacji również nie są stosowane.

Można to osiągnąć na dwa sposoby i żaden nie wymaga niczego poza prośbą. Na stronie stanowej obiekt wywołujący pomija identyfikator strony w adresie URL odbiornika, który w innym przypadku miałby go przenosić. Na stronie, którą Wicket uważa za bezstanową, nie trzeba w ogóle nic zmieniać: Wicket sam zapisuje adresy URL słuchaczy bez identyfikatora strony dla takich stron, a komponent, dla którego strategia odmawia RENDER, jest traktowany jako bezstanowy i dlatego nie utrzymuje stanu strony, więc odmowa RENDER może sama wygenerować formularz bez identyfikatora strony. Druga trasa nigdy nie została odrzucona. Decyzja ENABLE IAuthorizationStrategy jest konsultowana przy każdym wywołaniu i nadal jest odrzucana, podobnie jak żądanie dostarczające rzeczywisty identyfikator instancji strony, która została już wyrenderowana; komponent, którego aplikacja wyłączona w Component#onConfigure() nie jest chroniony przez żaden z nich, ponieważ to wywołanie zwrotne nie zostało uruchomione.

Na aplikację wpływa to, gdy wstrzymuje pojedynczy komponent przed obiektem wywołującym, albo przez odmowę akcji RENDER za pomocą IAuthorizationStrategy, w tym za pomocą funkcji MetaDataRoleAuthorizationStrategy i AuthorizeAction ról wicket-auth, albo przez ustawienie widoczności komponentu lub flagi włączonej w Component#onConfigure(), własna dokumentacja wywołania zwrotnego Wicket kieruje aplikacje do używania obu. Stronę zawierającą taki komponent należy zbudować z adresu URL, który można dodać do zakładek lub zamontować, co wymaga, aby konstruktor publiczny nie przyjmował żadnych argumentów lub argument PageParameters. Zachowania przechodzą przez tę samą bramkę, więc zachowanie AJAX dołączone do takiego komponentu jest równie widoczne. Niezależnie od tego, czy jakikolwiek komponent jest wstrzymany, czy nie, słuchacz na stronie, którą Wicket uważa za stanową, jest wywoływany w instancji, którą skonstruowało samo żądanie, więc działa na modelach zbudowanych na podstawie parametrów strony dostarczonych przez osobę wywołującą, a nie na stanie ostatnio wyrenderowanym przez aplikację. Autoryzacja instancji pozostaje niezmieniona: Funkcja IAuthorizationStrategy#isInstantiationAuthorized() jest nadal sprawdzana podczas tworzenia nowej instancji strony, zatem ochrona umieszczona na stronie, a nie na pojedynczym komponencie, nadal obowiązuje.

Ten problem dotyczy Apache Wicket: od 8.0.0 do 8.19.0, od 9.0.0 do 9.24.0, od 10.0.0 do 10.11.0. Użytkownikom zaleca się aktualizację do wersji 8.20.0, 9.25.0 lub 10.12.0, która rozwiązuje problem.

Missing authorization in Apache Wicket.

org.apache.wicket.core.request.handler.ListenerRequestHandler invokes an IRequestListener only when org.apache.wicket.Component#canCallListener() allows it, and that method is isEnabledInHierarchy() && isVisibleInHierarchy(). The visibility half reads a flag that carries the outcome of IAuthorizationStrategy#isActionAuthorized() for the Component.RENDER action, and that flag is written in one place only, Component#configure(), during the render phase. A listener URL built by a subclass of org.apache.wicket.core.request.mapper.AbstractBookmarkableMapper carries the page identifier and the component path in a single parameter, and the page identifier may be empty. When it is, a new page instance is constructed, PageProvider#wasExpired() is false because no identifier was supplied, and PageAndComponentProvider#getComponent() finds the component directly on the new instance, so neither a render pass nor Component#configure() runs before the listener is invoked. The flag therefore still holds its constructor default, the component counts as visible, and the listener of a component the authorization strategy denied RENDER for is executed. The same request also skips Component#onConfigure(), so visibility and enablement an application sets there are not applied either.

There are two ways to reach this, and neither requires anything but a request. On a page that is stateful, the caller omits the page identifier from a listener URL that would otherwise carry it. On a page that Wicket considers stateless, nothing has to be altered at all: Wicket itself writes listener URLs without a page identifier for such pages, and a component the strategy denies RENDER for is treated as stateless and therefore does not keep the page stateful, so denying RENDER can itself produce the page-id-less form. The second route has never been refused. The ENABLE decision of IAuthorizationStrategy is consulted on every invocation and still refuses, as does a request that supplies the real identifier of a page instance that has already been rendered; a component the application disabled in Component#onConfigure() is protected by neither, because that callback has not run.

An application is affected where it withholds an individual component from the caller, either by denying the RENDER action through IAuthorizationStrategy, including through the MetaDataRoleAuthorizationStrategy and AuthorizeAction facilities of wicket-auth-roles, or by setting the component's visibility or enabled flag in Component#onConfigure(), the callback Wicket's own documentation directs applications to use for both. The page carrying such a component has to be constructible from a bookmarkable or mounted URL, which requires a public constructor taking either no arguments or a PageParameters argument. Behaviours pass through the same gate, so an AJAX behaviour attached to such a component is equally exposed. Separately, and whether or not any component is withheld, a listener on a page Wicket considers stateful is invoked on an instance the request itself constructed, so it acts on models built from page parameters the caller supplied rather than on the state the application last rendered. Instantiation authorization is unaffected: IAuthorizationStrategy#isInstantiationAuthorized() is still consulted when the new page instance is created, so a guard placed on the page rather than on the individual component continues to hold.

This issue affects Apache Wicket: from 8.0.0 through 8.19.0, from 9.0.0 through 9.24.0, from 10.0.0 through 10.11.0. Users are recommended to upgrade to version 8.20.0, 9.25.0 or 10.12.0, which fix the issue.

>_ Słabości (CWE)

CWE-862

>_ Referencje

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

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