CVE-2026-82898 in Wicket
Riassunto
di VulDB • 01/11/2026
Ordine errato dei controlli di sicurezza in Apache Wicket.
L'oggetto `org.apache.wicket.protocol.http.ResourceIsolationRequestCycleListener` ottiene la pagina target della richiesta prima di consultare le relative policy di isolamento delle risorse, poiché tali policy ricevono tale pagina come parametro. L'ottenimento della pagina ne provoca l'istanziazione e l'istanziazione di una pagina esegue la strategia di autorizzazione configurata `org.apache.wicket.authorization.IAuthorizationStrategy`. Un'applicazione che rifiuta un visitatore non autenticato lanciando `org.apache.wicket.RestartResponseAtInterceptPageException` pertanto genera tale eccezione all'interno dell'ascoltatore (listener) di isolamento, prima che qualsiasi policy venga eseguita. Poiché questa eccezione sostituisce il gestore della richiesta, le policy non vengono mai consultate e una richiesta proveniente da un'altra origine non viene rifiutata.
Il costruttore dell'eccezione memorizza l'URL della richiesta interrotta, in modo che `Component#continueToOriginalDestination()` possa riprenderla una volta che il visitatore ha effettuato l'accesso. L'URL memorizzato è quello che le policy avrebbero dovuto rifiutare. Al momento del login, Wicket reindirizza verso tale URL e questo redirect è same-origin (della stessa origine), quindi le policy lo consentono e l'ascoltatore viene eseguito nella sessione autenticata di recente. Viene memorizzata l'intera URL, inclusa la stringa di query; pertanto, un normale `org.apache.wicket.markup.html.form.Form` riprende con i valori dei campi contenuti nella stringa di query della richiesta originale e il metodo `Form#onSubmit()` viene eseguito con valori scelti da un'altra origine. Non è necessario un POST del modulo per questo scenario: una semplice navigazione a livello superiore (top-level) trasporta tali dati.
Un'applicazione è interessata se registra `ResourceIsolationRequestCycleListener`, che è opzionale e non registrata di default, e se rifiuta l'accesso non autorizzato utilizzando `RestartResponseAtInterceptPageException` seguito da `continueToOriginalDestination()`. Non sono coinvolti override dell'applicazione su questo percorso: la documentazione di `IAuthorizationStrategy#isInstantiationAuthorized()` indica che tale eccezione può essere lanciata, `org.apache.wicket.authroles.authentication.AuthenticatedWebApplication` la lancia e `org.apache.wicket.authroles.authentication.panel.UsernamePasswordPanel` prosegue verso la destinazione originale; inoltre, `SimplePageAuthorizationStrategy` in wicket-core installa lo stesso pattern. Un visitatore già autenticato non è interessato, poiché non avviene alcuna intercettazione. I parametri del corpo della richiesta memorizzati insieme all'URL interrotto non vengono applicati al modulo ripreso: la ripresa avviene tramite redirect, quindi la richiesta ripresa è un GET e i componenti del modulo leggono i propri valori dalla stringa di query durante una operazione GET.
Come soluzione alternativa (workaround), rifiutare l'accesso non autorizzato utilizzando `org.apache.wicket.RestartResponseException`, che non memorizza la destinazione originale; in questo modo, ai visitatori non viene restituita automaticamente la pagina richiesta dopo il login.
Questo problema interessa Apache Wicket: dalle versioni 9.1.0 alla 9.24.0 e dalla versione 10.0.0 alla 10.11.0.
Le release precedenti alla 9.1.0, ovvero tutte le release della serie 8.x e la 9.0.0, non sono interessate, poiché l'isolamento delle risorse oggetto di questo problema è stato introdotto nella versione 9.1.0. Non sono nemmeno protette da tale vulnerabilità. La loro unica difesa contro attacchi cross-origin (tra origini diverse) è `org.apache.wicket.protocol.http.CsrfPreventionRequestCycleListener`, che determina l'origine della richiesta leggendo l'intestazione Origin e, in caso di assenza, ricorrendo all'intestazione Referer. Nessuna delle due intestazioni deve necessariamente essere presente: un browser non invia il campo Origin per le semplici operazioni GET effettuate tramite link e il documento sull'altra origine decide autonomamente, attraverso la propria policy del referrer, se inviare o meno l'header Referer all'applicazione. Di conseguenza, tale meccanismo non ha mai garantito lo stesso livello di protezione offerto dalle policy basate su Fetch Metadata; sulle release precedenti alla 9.1.0, una chiamata a un listener proveniente da un'altra origine non viene rifiutata in modo affidabile fin dall'inizio. Chi utilizza una release precedente alla 9.1.0 e desidera questa protezione dovrebbe effettuare l'upgrade alle versioni della serie 9.x o 10.x e registrare `ResourceIsolationRequestCycleListener`.
Si consiglia agli utenti di eseguire l'aggiornamento alle versioni 9.25.0 o 10.12.0, che risolvono il problema.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.