CVE-2026-82558
NiskieCVSS 2.3Streszczenie
Apache Wicket nie sprawdza autoryzacji przed wywołaniem callbacków onMessage() w WebSocketBehavior. Komunikat wysłany przez klienta jest dostarczany do każdego WebSocketBehavior na stronie, nawet jeśli komponent, do którego jest przypisany, jest ukryty, wyłączony lub zabroniony przez IAuthorizationStrategy — w przeciwieństwie do zachowań Ajax, gdzie taka weryfikacja jest wykonywana.
Ocena ryzyka
Klient może wywołać logikę onMessage() komponentu, do którego nie ma uprawnień (np. ukrytego lub ograniczonego rolą), co może prowadzić do nieautoryzowanych działań w aplikacji. Problem dotyczy wyłącznie własnej sesji i strony klienta — nie umożliwia dostępu do sesji innych użytkowników.
Rekomendacja
Zaktualizuj Apache Wicket do wersji 8.20.0, 9.25.0 lub 10.12.0, które naprawiają podatność. Do czasu aktualizacji unikaj przypinania WebSocketBehavior z nadpisanym onMessage() do komponentów ukrywanych, wyłączanych lub ograniczanych przez IAuthorizationStrategy.
Inne podatności w Apache Wicket
Zobacz wszystkie- CVE-2026-95863Wysokie
Apache Wicket generuje kod JavaScript odwołujący się do renderowanych elementów, umieszczając w literałach tekstowych w pojedynczych cudzysłowach wartości markup id oraz nazwy pól formularza bez odpowiedniego escapowania. Wartość zawierająca apostrof lub backslash może przerwać literał, a następnie wstrzyknąć kod wykonywany w kontekście aplikacji przy załadowaniu strony. Problem dotyczy wicket-core oraz wicket-extensions w wersjach 8.0.0–8.19.0, 9.0.0–9.24.0 i 10.0.0–10.11.0.
- CVE-2026-87718Niskie
Apache Wicket w wersjach 10.10.0, 10.11.0 i 9.24.0 nie ustawia nagłówków Content-Security-Policy na stronach, których procedura obsługi żądania renderowania jest opakowana w więcej niż jeden IRequestHandlerDelegate. Framework odpakowuje tylko jeden poziom delegata przy podejmowaniu decyzji o renderowaniu strony, więc przy głębszym łańcuchu (np. delegujący mapper żądań aplikacji w połączeniu z CryptoMapper) strona jest serwowana bez nagłówka CSP, mimo że CSP jest włączone i nie jest zgłaszany żaden błąd ani ostrzeżenie. Ochrona oparta na nonce dla skryptów i stylów inline oraz inne skonfigurowane dyrektywy CSP są tracone dla tych stron, narażając je na wstrzyknięcie treści, któremu polityka miała zapobiegać. Aplikacje na standardowym Wicket, które same nie opakowują procedur obsługi żądań, nie są dotknięte. Wersje przed 10.10.0 i 9.24.0 obsługiwały zagnieżdżone delegaty poprawnie.
- CVE-2026-84231Wysokie
Podatność typu cross-site scripting (XSS) w Apache Wicket wynika z niewłaściwej neutralizacji danych wejściowych podczas generowania stron. Komponent ExternalLink, powiązany z elementem innym niż a, link lub area, wstawia URL z modelu do literału JavaScript w atrybucie onclick bez odpowiedniego escapowania, co pozwala na wykonanie złośliwego skryptu w kontekście aplikacji.
- CVE-2026-84177Średnie
W Apache Wicket występuje błąd kolejności sprawdzeń: ścieżka pliku jest walidowana przez PackageResourceGuard zanim framework dołączy do niej atrybuty style, variation i locale. W rezultacie otwierany plik może być innym plikiem niż zatwierdzony przez guard, co pozwala na odczytanie szablonów HTML komponentów, których nazwy klas zawierają podkreślenie (np. Report_v2).
- CVE-2026-84172Średnie
W Apache Wicket mechanizm PackageResourceGuard błędnie zezwala na serwowanie szablonów znaczników komponentów jako zasobów pakietowych, gdy wicket-core jest ładowany przez class loader, który nie widzi klas aplikacji. W takiej konfiguracji sprawdzenie obecności pliku klasy obok szablonu kończy się niepowodzeniem, a żądanie URL zasobu pakietowego zwraca szablon komponentu ze statusem 200. Ujawnieniu podlegają treści szablonów tworzone przez deweloperów, takie jak struktura komponentów, komentarze, skrypty inline i nazwy endpointów.
- CVE-2026-84170Wysokie
Podatność w Apache Wicket dotyczy zasobu AbstractFileUploadResource (serwerowa strona uploadu bez formularza z FileUploadToResourceField). Limity rozmiaru żądania, pojedynczego pliku i liczby części są pobierane z parametrów żądania (maxSize, fileMaxSize, fileCountMax) zamiast z konfiguracji aplikacji, więc klient może je dowolnie zawyżyć lub pominąć. Zasób nie ma adnotacji autoryzacyjnej, więc domyślnie żądanie nie wymaga uwierzytelnienia.
- CVE-2026-83594Wysokie
Podatność w Apache Wicket dotyczy komponentu FileUploadToResourceField, którego callback Ajax odczytuje parametr filesInfo bez powiązania go z rzeczywistym uploadem. Metoda UploadInfo#get() alokuje tablicę bajtów na podstawie rozmiaru podanego przez klienta, co pozwala na wyczerpanie sterty JVM pojedynczym żądaniem, a wartości ujemne powodują wyjątek NegativeArraySizeException.
- CVE-2026-83559Wysokie
Podatność w Apache Wicket dotyczy metody JavaScriptUtils#escapeQuotes(), która nie escapuje znaku backslash przed cudzysłowami. Wartość zawierająca backslash bezpośrednio przed cudzysłowem powoduje, że cudzysłów nie jest escapowany i zamyka literał JavaScript, umożliwiając wstrzyknięcie kodu JavaScript. Problem występuje, gdy aplikacja używa tej metody do osadzenia danych kontrolowanych przez atakującego w literale JavaScript, m.in. przez komponent AjaxEditableLabel.
- CVE-2026-83539Wysokie
Podatność typu cross-site scripting (XSS) w komponentach SmartLinkLabel i SmartLinkMultiLineLabel biblioteki Apache Wicket. Komponenty te zamieniają znalezione w tekście adresy URL w hiperłącza, akceptując dowolny schemat URL — w tym schematy wykonujące skrypt, takie jak javascript:. Eskapowanie wartości modelu nie chroni, ponieważ payload trafia do atrybutu href, a nie do tekstu elementu.
- CVE-2026-82956Wysokie
Podatność typu cross-site scripting (XSS) w Apache Wicket dotyczy zachowania AjaxNewWindowNotifyingBehavior, które zapisuje w stanie strony wartość window.name przesłaną przez klienta. Wartość ta jest później wstawiana bez escapowania do literału JavaScript w preconditions wywołania Ajax, co pozwala na wykonanie dowolnego skryptu w kontekście aplikacji przy każdym renderowaniu strony. Podatność występuje tylko w aplikacjach, które jawnie dodały to zachowanie do komponentu.
Oryginalny opis (angielski, źródło NVD)
Missing authorization in Apache Wicket. org.apache.wicket.protocol.ws.api.WebSocketBehavior, through which Wicket's native WebSocket support hands a message sent by the client to the application, calls its onMessage() callbacks without checking whether the client may invoke the component the behavior is attached to. Wicket opens a single WebSocket connection per page, and a message received on it is delivered to every WebSocketBehavior of that page. For an Ajax behavior Wicket makes this check before invoking it, through Behavior#canCallListener(Component), which refuses a component that is not visible or not enabled, including one for which the IAuthorizationStrategy denies the RENDER or ENABLE action. A WebSocketBehavior attached to such a component, or to a child of one, therefore receives the client's text and binary messages, together with a WebSocketRequestHandler that writes back to that client, where an Ajax behavior on the same component would be refused. An application is affected where it attaches a WebSocketBehavior that overrides onMessage() to a component that it hides, disables, or restricts through its IAuthorizationStrategy, for example with MetaDataRoleAuthorizationStrategy or the AuthorizeAction annotation. The client needs a session of their own and a page of their own that contains such a component: messages are delivered only to pages in the page store of the client's own session, so this gives no access to another user's session, page or connection. Messages pushed by the server are not affected. 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. Older, unsupported releases from 6.0.0 onwards are also affected. Users are recommended to upgrade to version 8.20.0, 9.25.0 or 10.12.0, which fix the issue.
Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS