CVE-2026-82898 in Wicket
要約
〜によって VulDB • 2026年11月02日
Apache Wicketにおけるセキュリティチェックの順序の不具合。
org.apache.wicket.protocol.http.ResourceIsolationRequestCycleListenerは、リソース分離ポリシーを参照する前に、リクエストが対象とするページを取得します。これは、そのポリシーにページが渡されるためです。ページの取得によりインスタンス化が行われ、ページのインスタンス化によって構成された org.apache.wicket.authorization.IAuthorizationStrategy が実行されます。認証されていない訪問者を拒否するために org.apache.wicket.RestartResponseAtInterceptPageException をスローするアプリケーションの場合、この例外は分離リスナー内から、いかなるポリシーも実行される前にスローされます。その例外がリクエストハンドラを置き換えるため、ポリシーは一切参照されず、別のオリジンからのリクエストが拒否されません。
例外のコンストラクタには、中断されたリクエストのURLが格納されており、これにより Component#continueToOriginalDestination() を使用して訪問者がサインインした後にその処理を再開できます。格納されるURLは、ポリシーによって拒否されていたものです。サインイン時にWicketはそのURLにリダイレクトし、そのリダイレクトは同一オリジンであるため、ポリシーはそれを許可し、リスナーは新しく認証されたセッション内で実行されます。完全なURL（クエリ文字列を含む）が格納されるため、通常の org.apache.wicket.markup.html.form.Form が再開され、Form#onSubmit() は元のリクエストのクエリ文字列に含まれていたフィールド値で実行されます。これにはフォームPOSTは必要なく、プレーンなトップレベルナビゲーションでもこれらの値が伝播します。
この問題の影響を受けるアプリケーションは、ResourceIsolationRequestCycleListenerを登録しており（これはオプトインでありデフォルトでは登録されず）、RestartResponseAtInterceptPageException に続いて continueToOriginalDestination() を使用して不正アクセスを拒否するものです。そのパスにはアプリケーションのオーバーライドは関与しません：IAuthorizationStrategy#isInstantiationAuthorized() はこの例外のスローについて文書化しており、org.apache.wicket.authroles.authentication.AuthenticatedWebApplication がこれをスローし、org.apache.wicket.authroles.authentication.panel.UsernamePasswordPanel が元の宛先へ移動します。また、wicket-core の org.apache.wicket.authorization.strategies.page.SimplePageAuthorizationStrategy も同様のパターンをインストールしています。すでにサインインしている訪問者は影響を受けません（インターセプションが発生しないため）。中断されたURLと一緒に格納されるリクエストボディのパラメータは再開されたフォームには適用されません：再開はリダイレクトであるため、再開されたリクエストはGETになり、フォームコンポーネントはGET時にクエリ文字列から値を読み取ります。
回避策として、元の宛先を保存しない org.apache.wicket.RestartResponseException を使用して不正アクセスを拒否してください。これにより、訪問者はサインイン後に要求したページに戻されなくなります。
この問題は Apache Wicket に影響します：9.1.0 から 9.24.0 および 10.0.0 から 10.11.0 のバージョンです。
9.1.0 より前のリリース（8.x リリースすべておよび 9.0.0）は、この問題に関連するリソース分離が 9.1.0 で導入されたため影響を受けません。また、保護もされていません。それらの唯一のクロスオリジン対策は org.apache.wicket.protocol.http.CsrfPreventionRequestCycleListener であり、これは Origin ヘッダーを読み取って Referer ヘッダーにフォールバックすることでリクエストの発信元を判別します。これらのヘッダーが送信される必要はありません：ブラウザはリンクが使用するプレーンな GET では Origin を送信せず、別のオリジンのドキュメントはその自身の referrer ポリシーを通じて Referer がアプリケーションに到達するかどうかを決定します。したがって、そのメカニズムは Fetch Metadata に基づくポリシーが提供する保証を常に提供したことはなく、9.1.0 より前のリリースでは他のオリジンからのリスナー呼び出しはそもそも確実に拒否されませんでした。この保護を望む 9.1.0 より前のリリースのユーザーは、9.x または 10.x にアップグレードし、ResourceIsolationRequestCycleListener を登録する必要があります。
ユーザーには、本問題を修正するバージョン 9.25.0 および 10.12.0 へのアップグレードを推奨します。
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.