CVE-2026-82898 in Wicket
Zusammenfassung
von VulDB • 01.11.2026
Falsche Reihenfolge der Sicherheitsprüfungen in Apache Wicket.
org.apache.wicket.protocol.http.ResourceIsolationRequestCycleListener ruft die Seite ab, auf die eine Anfrage zielt, bevor es seine Ressourcenisolationsrichtlinien konsultiert, da diese Richtlinien dieser Seite übergeben werden. Das Abrufen der Seite instanziiert sie, und das Instanziieren einer Seite führt die konfigurierte org.apache.wicket.authorization.IAuthorizationStrategy aus. Eine Anwendung, die einen nicht authentifizierten Besucher ablehnt, indem sie org.apache.wicket.RestartResponseAtInterceptPageException wirft, gibt diese Ausnahme daher innerhalb des Isolations-Listeners aus, bevor eine Richtlinie ausgeführt wurde. Diese Exception ersetzt den Anfragehandler, sodass die Richtlinien niemals konsultiert werden und eine Anfrage von einer anderen Herkunft nicht abgelehnt wird.
Der Konstruktor der Exception speichert die URL der angehaltenen Anfrage, damit Component#continueToOriginalDestination() diese fortsetzen kann, sobald sich der Besucher angemeldet hat. Die gespeicherte URL ist jene, die die Richtlinien hätten ablehnen sollen. Bei der Anmeldung leitet Wicket zu dieser URL weiter, und diese Weiterleitung ist same-origin (gleiche Herkunft), sodass die Richtlinien sie zulassen und der Listener in der neu authentifizierten Sitzung ausgeführt wird. Die gesamte URL wird gespeichert, einschließlich ihres Query-Strings, sodass ein normales org.apache.wicket.markup.html.form.Form mit den Feldwerten fortgesetzt wird, die die ursprüngliche Anfrage in ihrem Query-String trug, und Form#onSubmit() wird mit Werten ausgeführt, die eine andere Herkunft gewählt hat. Für diesen Vorgang ist kein Formular-POST (Formularabsendung) erforderlich; eine einfache Navigation auf oberster Ebene überträgt diese Werte ebenfalls.
Eine Anwendung ist betroffen, wenn sie ResourceIsolationRequestCycleListener registriert, was optional ist und standardmäßig nicht registriert wird, und wenn sie den unbefugten Zugriff mit RestartResponseAtInterceptPageException in Kombination mit continueToOriginalDestination() ablehnt. Keine Anwendungsüberschreibung (Override) ist auf diesem Pfad beteiligt: IAuthorizationStrategy#isInstantiationAuthorized() dokumentiert das Werfen dieser Exception, org.apache.wicket.authroles.authentication.AuthenticatedWebApplication wirft sie und org.apache.wicket.authroles.authentication.panel.UsernamePasswordPanel geht zum ursprünglichen Ziel weiter, und org.apache.wicket.authorization.strategies.page.SimplePageAuthorizationStrategy in wicket-core installiert dasselbe Muster. Ein Besucher, der bereits angemeldet ist, ist nicht betroffen, da keine Unterbrechung (Interception) stattfindet. Anfragekörperparameter, die zusammen mit der unterbrochenen URL gespeichert werden, werden auf das fortgesetzte Formular angewendet: Die Fortsetzung erfolgt als Weiterleitung, sodass die fortgesetzte Anfrage ein GET ist und Formularelemente ihre Werte bei einem GET aus dem Query-String lesen.
Als Workaround sollte der unbefugte Zugriff mit org.apache.wicket.RestartResponseException abgelehnt werden, welche das ursprüngliche Ziel nicht speichert; Besucher werden nach der Anmeldung dann nicht zur angeforderten Seite zurückgeleitet.
Dieses Problem betrifft Apache Wicket: von 9.1.0 bis 9.24.0 und von 10.0.0 bis 10.11.0.
Releases vor 9.1.0, also alle 8.x-Releases sowie 9.0.0, sind nicht betroffen, da die Ressourcenisolation, um die es hier geht, in Version 9.1.0 eingeführt wurde. Sie sind ebenfalls nicht geschützt. Ihre einzige Abwehr gegen Cross-Origin-Anfragen ist org.apache.wicket.protocol.http.CsrfPreventionRequestCycleListener, das ermittelt, von wo eine Anfrage stammt, indem sie den Origin-Header ausliest und auf den Referer-Header zurückgreift. Kein Header muss zwingend ankommen: Ein Browser sendet keinen Origin-Header bei einem einfachen GET über einen Link, und das Dokument der anderen Herkunft entscheidet durch seine eigene Referrer-Richtlinie darüber, ob ein Referer die Anwendung überhaupt erreicht. Dieser Mechanismus gewährte daher nie dieselbe Garantie wie eine Fetch-Metadata-basierte Richtlinie, und auf diesen Releases wird ein Listener-Aufruf von einer anderen Herkunft nicht zuverlässig abgelehnt. Jeder Benutzer eines Releases vor 9.1.0, der diesen Schutz wünscht, sollte auf 9.x oder 10.x upgraden und ResourceIsolationRequestCycleListener registrieren.
Benutzern wird empfohlen, auf Version 9.25.0 oder 10.12.0 zu aktualisieren, die das Problem beheben.
If you want to get best quality of vulnerability data, you may have to visit VulDB.