ソースコードをレビューする際、私はOpenClawがHTTPリクエストをどのように処理するかに注目しました。具体的には、サーバーサイドのフェッチ呼び出しを担当するfetchWithSsrFGuard()関数です。
何かおかしな点に気づきました。
リクエストがクロスオリジンリダイレクト（サーバーが別のドメインを指す3xxレスポンスを送信する場合）に従ったとき、OpenClawは新しい宛先にリクエストを転送する前に機密ヘッダーを除去するはずでした。実際には除去されていましたが、ハードコードされた狭い拒否リストに対してのみでした：
Authorization, Proxy-Authorization, Cookie, Cookie2
問題は？ そのリストは不完全です。
X-Api-Key、Private-Token、または開発者が一般的に使用するその他のベアラースタイルのヘッダーなどのカスタム認証ヘッダーは、どれも除去されませんでした。それらはリダイレクト先にそのまま転送されました。
つまり、攻撃者がリダイレクトの宛先を制御または操作できる場合、本来渡されるべきではなかった機密の認証情報を受け取る可能性があります。
アプリケーションがOpenClawを使用して、カスタムのX-Api-Keyヘッダーで内部APIを呼び出すと想像してください。悪意のあるサーバーが攻撃者が制御するURLへのリダイレクトで応答します。OpenClawはリダイレクトに従い、APIキーもそのまま転送します。
ゲームオーバーです。あなたの認証情報は他人の手に渡ってしまいます。
CVSS 3.1スコア: 9.3（クリティカル）
メンテナーは拒否リスト方式を安全なヘッダーの許可リストに置き換えました。既知の悪質なヘッダーをブロックしようとする代わりに、新しいロジックはクロスオリジンリダイレクト時に既知の安全なヘッダー（コンテンツネゴシエーションやキャッシュバリデーターなど）のみを通過させます。それ以外はすべてデフォルトで除去されます。
これは正しいアプローチです。拒否リストベースのセキュリティは脆弱であり、許可リストベースのセキュリティは堅牢です。
参考情報
46715371b0612a6f9114dffd1466941ac476cef5<= 2026.3.2>= 2026.3.7直ちに>= 2026.3.7へ更新してください。
カスタム認証ヘッダー（X-Api-KeyやPrivate-Tokenなど）を使用していて、古いバージョンを使用していた場合は、それらの認証情報が侵害された可能性があるものとして扱い、ローテーションしてください。