CVE-2026-42509

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.

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.

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.

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).

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.

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.

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.

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.

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.

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.