CVE-2026-82840
WysokieCVSS 7.2Streszczenie
Podatność typu session fixation w Apache Wicket dotyczy klasy AuthenticatedWebSession i metody signIn(String, String). Identyfikator sesji jest odnawiany tylko przy pierwszym logowaniu, a nie przy ponownej autoryzacji już zalogowanej sesji, mimo że metoda zwraca true w obu przypadkach. Wykorzystanie wymaga umieszczenia przez atakującego wybranego identyfikatora sesji w przeglądarce ofiary, np. przez kontrolę hosta w tej samej domenie rejestrowanej lub konfigurację kontenera przenoszącego identyfikator sesji w URL.
Ocena ryzyka
Atakujący może przejąć sesję ofiary, jeśli zdoła wcześniej narzucić jej identyfikator sesji, a aplikacja pozwala zalogowanej sesji na ponowną autoryzację (np. formularz logowania dostępny po zalogowaniu, zmiana konta, ponowne uwierzytelnienie przed wrażliwą operacją). Prowadzi to do nieautoryzowanego dostępu do konta ofiary.
Rekomendacja
Zaktualizuj Apache Wicket do wersji 8.20.0, 9.25.0 lub 10.12.0. Jako obejście wywołuj Session#changeSessionId() na końcu implementacji authenticate(String, String) przy każdym udanym uwierzytelnieniu.
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)
Session fixation in Apache Wicket. org.apache.wicket.authroles.authentication.AuthenticatedWebSession is the authentication base class of Wicket's role-based security module, and its signIn(String, String) method is the entry point through which an application authenticates a session. Renewing the container session id at that point is the standard defence against an attacker who has fixed a session id in a victim's browser, and Wicket provides that renewal as org.apache.wicket.Session#changeSessionId(), whose documentation directs callers to invoke it on login for exactly that reason. AuthenticatedWebSession#signIn(String, String) calls it inside a guard that succeeds only on the first transition of the session's signed-in flag. The session id is therefore renewed when a session first signs in, and is not renewed when a session that is already signed in authenticates again. signIn(String, String) returns true either way, so neither the caller nor the application can tell that the renewal did not happen. An application is affected where it authenticates through AuthenticatedWebSession, which AuthenticatedWebApplication requires and which the shipped UsernamePasswordPanel uses, and where a session that is already signed in can authenticate again: a step-up prompt before a sensitive action, an account switch, or simply a sign-in form that stays reachable once the user is signed in. Nothing in the module hides that form from a signed-in session. Reaching the defect also requires an attacker to place a session id of their choosing in the victim's browser. JSESSIONID is set by the servlet container rather than by Wicket, so that needs a position Wicket does not grant, such as control of a host under the same registrable domain or a container configured to carry the session id in the URL, and the planted session has to be one the attacker has already signed in on, because a session that is not yet signed in does have its id renewed by the victim's authentication. An authentication attempt that fails signs the session out and closes the window. Applications that renew the session id in their own code after a successful authentication are not affected. As a workaround, renew the session id from the application's own code on every successful authentication, by calling Session#changeSessionId() at the end of the authenticate(String, String) implementation. This issue affects Apache Wicket: from 8.18.0 through 8.19.0, from 9.23.0 through 9.24.0, from 10.9.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.
Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS