Niski Odebrany

CVE-2026-82559

opublikowano: 01.11.2026, 23:17

modyfikacja: 01.11.2026, 23:17

Ocena CVSS

2.3

Niski · v4.0

Oficjalne źródła

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

Niewystarczający czas wygaśnięcia sesji w Apache Wicket.

org.apache.wicket.protocol.ws.WebSocketSettings#newWebSocketRequest() otacza żądanie aktualizacji protokołu WebSocket w pliku org.apache.wicket.protocol.ws.api.ServletRequestCopy, który jest przechowywany przez cały czas trwania połączenia i używany do tworzenia żądania dla każdej przychodzącej ramki. Kopiowanie żądania jest celowe i jest jako takie udokumentowane, ponieważ kontener przetwarza żądanie aktualizacji po zakończeniu uzgadniania. Sesja kontenera jest kopiowana wraz z nią do org.apache.wicket.protocol.ws.api.HttpSessionCopy przechowującego atrybuty sesji w stanie, w jakim znajdowały się w momencie otwierania połączenia. Ta druga kopia nie jest konieczna, ponieważ sesja, w przeciwieństwie do żądania, nie jest odrzucana po zakończeniu żądania. Każda ramka następnie rozwiązuje swoją sesję Wicket za pomocą funkcji ISessionStore#lookup(), która odczytuje ją z kopii, więc połączenie zostaje odłączone od aktywnej sesji kontenera tak długo, jak pozostaje ona otwarta.

Zakończenie sesji poprzez kontener nie powoduje zatem zakończenia połączenia. Po upływie limitu czasu bezczynności, wywołaniu HttpSession#invalidate() wykonanym z filtru lub struktury zabezpieczeń, wylogowaniu zarządzanym przez kontener lub zastąpieniu sesji, połączenie kontynuuje rozpoznawanie instancji org.apache.wicket.Session, która istniała w momencie otwarcia, wraz z atrybutami tej sesji oraz, w przypadku aplikacji zbudowanych na rolach typu wicket-auth, stanem zalogowania utrzymywanym w tej samej instancji, więc decyzja o autoryzacji podjęta wewnątrz Wywołanie zwrotne protokołu WebSocket jest wykonywane w odniesieniu do tożsamości, która została już unieważniona. Kopia jest także tym, przez co zapisuje połączenie: Session#invalidateNow() wywołana z wewnątrz wywołania zwrotnego WebSocket unieważnia kopię i pozostawia ważną sesję kontenera, a atrybuty sesji ustawione przez połączenie są zapisywane w kopii, a nie w sesji.

Aplikacja ma na to wpływ, gdy korzysta z natywnej obsługi protokołu WebSocket firmy Wicket na stronach lub współdzielonych zasobach wymagających sesji uwierzytelnionej i gdy sesje są kończone przez kontener, a nie przez Wicket. Session#invalidateNow() oraz AuthenticatedWebSession#invalidate() i #signOut(), które ją wywołują, pozostają skuteczne w przypadku zachowania WebSocketBehavior na stronie: czyszczą menedżera stron, a połączenie nie może już rozpoznać strony, dla której zostało otwarte. Zasób WebSocketResource nie jest w ten sposób ograniczony, ponieważ ramka z nazwą zasobu jest wyświetlana na stronie jednorazowej i nigdy nie konsultuje się z menedżerem strony, więc takie połączenie przetrwa również wylogowanie Wicketa. Niektóre kontenery same zamykają połączenia WebSocket, gdy sesja HTTP, w której zostały otwarte, zostanie zniszczona; w takim przypadku połączenie zostanie mimo to zakończone; jest to właściwość kontenera, a nie Wicket. Nie ma to wpływu na aplikacje, które nie korzystają z natywnej obsługi protokołu WebSocket.

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. Dotyczy to również starszych, nieobsługiwanych wersji od wersji 6.0.0 i nowszych. Użytkownikom zaleca się aktualizację do wersji 8.20.0, 9.25.0 lub 10.12.0, która rozwiązuje problem.

Insufficient session expiration in Apache Wicket.

org.apache.wicket.protocol.ws.WebSocketSettings#newWebSocketRequest() wraps the WebSocket upgrade request in an org.apache.wicket.protocol.ws.api.ServletRequestCopy, which is kept for the life of the connection and used to build the request for every frame that arrives on it. Copying the request is deliberate and is documented as such, because the container recycles the upgrade request once the handshake is over. The container session is copied along with it, into an org.apache.wicket.protocol.ws.api.HttpSessionCopy holding the session attributes as they stood when the connection was opened. That second copy is not necessary, because a session, unlike a request, is not discarded at the end of a request. Every frame afterwards resolves its Wicket session through ISessionStore#lookup(), which reads it out of the copy, so the connection is detached from the live container session for as long as it stays open.

Ending the session through the container therefore does not end the connection. After an idle timeout, an HttpSession#invalidate() call made from a filter or from a security framework, a container-managed logout, or a session replacement, the connection goes on resolving the org.apache.wicket.Session instance that existed when it was opened, together with that session's attributes and, for applications built on wicket-auth-roles, the signed-in state held on that same instance, so an authorization decision taken inside a WebSocket callback is taken against an identity that has already been revoked. The copy is also what the connection writes through: a Session#invalidateNow() issued from inside a WebSocket callback invalidates the copy and leaves the container session valid, and session attributes set over the connection are written to the copy rather than to the session.

An application is affected where it uses Wicket's native WebSocket support on pages or shared resources that require an authenticated session, and where sessions are ended by the container rather than by Wicket. Session#invalidateNow(), and AuthenticatedWebSession#invalidate() and #signOut() which call it, remain effective for a WebSocketBehavior on a page: they clear the page manager, and the connection can then no longer resolve the page it was opened for. A WebSocketResource is not limited in that way, because a frame naming a resource is served against a throwaway page and never consults the page manager, so such a connection outlives Wicket's own sign-out as well. Some containers close WebSocket connections themselves when the HTTP session they were opened under is destroyed, in which case the connection ends regardless; that is a property of the container rather than of Wicket. Applications that do not use the native WebSocket support 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.

>_ Słabości (CWE)

CWE-613

>_ Referencje

https://lists.apache.org/thread.html/5vkw9wz6gf135ccosj928zjs4hqy7bcv

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