OAuth2 Proxyに認証回避の脆弱性、修正版なし

認証プロキシ「OAuth2 Proxy」に、未認証の攻撃者が認証を回避して保護対象のパスへアクセスできる脆弱性（CVE-2026-76835）が公表されました。CVSS v4.0の基本値は9.3（緊急）。リクエストに付けたX-Forwarded-Uriヘッダを詐称するだけで、OAuth2 Proxyの「認証を省略してよいパス」の判定を欺けます。対象は7.15.2〜7.15.4で、2026年8月25日時点で修正版は提供されていません。設定による緩和が当面の唯一の防御です。

この記事でわかること

  • そもそもOAuth2 Proxyとは何で、自社のどこで動いている可能性があるか
  • CVE-2026-76835で何が起きるのか（なぜヘッダ1つで認証が飛ぶのか）
  • 「既定設定のままだと危ない」の中身と、逆に該当しない条件
  • 4月に修正されたはずの脆弱性の“不完全な修正”だという経緯
  • 修正版が出るまでに打てる緩和策と、該当判定の具体的な手順

OAuth2 Proxyとは何者か

OAuth2 Proxyとは、Webアプリケーションの手前に置いて「ログインしていない人を通さない」役割を担うリバースプロキシ型の認証ゲートウェイ（OSS）です。GoogleアカウントやMicrosoft Entra ID、GitHubなどのOAuth2／OIDCプロバイダに認証を委ね、認証済みの利用者だけを背後のアプリへ通します。

使われる場面は「それ自体にはまともなログイン機能が無い社内ツールに、後付けでSSOを被せたいとき」です。監視ダッシュボード、社内向けの管理画面、開発チームの内製ツールなどが典型で、導入するのはインフラ担当や開発チーム——つまり情シスの資産管理台帳には載りにくい部類です。

そして重要なのは、OAuth2 Proxyは「自分で選んで入れた」とは限らない点です。Kubernetesの公式ingress-nginxのドキュメントでは、外部OAuth認証の実装例としてKubernetes DashboardをOAuth2 Proxyで保護する構成が案内されています。またKubeflowは1.9でそれまでのoidc-authserviceをOAuth2 Proxyに置き換え、標準マニフェスト（common/oauth2-proxy/）として同梱しています。Helmチャートやリファレンス構成をそのまま適用した結果、誰も意識しないままクラスタ内で動いているケースが珍しくありません。「うちはOAuth2 Proxyなんて使っていない」と即断せず、後述の確認手順で該当有無を判定してください。

何が起きたのか

OAuth2 Proxyには、認証をかけずに素通しするパスを指定する--skip-auth-route（旧--skip-auth-regex）という設定があります。ヘルスチェック用のエンドポイントや、公開してよい静的ファイルを除外するために使われる、ごく一般的な機能です。

問題は、リバースプロキシモード（--reverse-proxy）で動作しているとき、この「認証を省略してよいか」の判定に、クライアントから送られてきたX-Forwarded-Uriヘッダの値を使ってしまうことにあります。攻撃者は次のようにするだけで済みます。

  • 実際のリクエスト先は、認証が必要な保護対象のパス（例：管理画面）
  • そこにX-Forwarded-Uri: /（許可リストに載っているパス）というヘッダを自分で付けて送る

するとOAuth2 Proxyはヘッダに書かれた偽のパスを見て「これは認証不要だ」と判断し、実際のリクエスト（保護対象のパス）はそのまま背後のアプリへ転送されます。ログインもトークンも要りません。CWE分類は「なりすましによる認証回避（CWE-290）」で、CVSS v4.0は9.3、CVSS v3.1では9.1と評価されています。NVDへの登録は2026年8月24日です。

なぜ「既定設定のままだと危ない」のか？

どのIPからの転送ヘッダを信じるかの設定が、初期値では「全部信じる」になっているからです。OAuth2 Proxyには信頼するプロキシのIPを指定する--trusted-proxy-ip（設定キー：trusted_proxy_ips）がありますが、未設定の場合は後方互換性のため0.0.0.0/0と::/0、つまり全送信元が信頼されます。公式ドキュメントも「未設定だとOAuth2 Proxyに直接到達できるクライアントが転送ヘッダを詐称できる可能性がある」と警告し、起動時にも警告ログを出します。裏を返せば、この警告ログが出ているかどうかが、そのまま該当判定の材料になります。

影響を受ける条件と、受けない条件

今回は「バージョンが該当すれば即アウト」ではなく、3つの条件が揃ったときに成立します。ここを取り違えると、無用な緊急対応にも、逆に見落としにもつながります。

項目 内容
対象バージョン 7.15.2 〜 7.15.4
条件1 --reverse-proxy が有効（リバースプロキシモードで運用）
条件2 skip_auth_routes / skip_auth_regex による認証スキップ設定がある
条件3 --trusted-proxy-ip が未設定（＝既定の全許可）
修正版 未提供（最新は2026年8月20日公開の7.15.4）
深刻度 CVSS v4.0：9.3／CVSS v3.1：9.1（CWE-290）

認証スキップの設定を一切していない環境では、この経路での回避は成立しません。とはいえヘルスチェック用パスの除外は定番の設定であり、「うちは条件2に当てはまらない」と言い切れる組織はそれほど多くないはずです。

4月に直したはずの脆弱性の“やり直し”である

実はこの問題、今回が初めてではありません。2026年4月14日に同じX-Forwarded-Uriヘッダ詐称による認証回避（GHSA-7×63-xv5r-3p2x／CVE-2026-40575）が公表され、7.15.2で修正されています。そのときに導入されたのが、まさに--trusted-proxy-ipという新フラグでした。

しかし「新しい防御機構を用意したが、初期値は従来どおり全部信頼のまま」だったため、設定を追加していない大多数の環境では実質的に何も変わっていませんでした。今回のCVE-2026-76835は、その不完全な修正を指摘し直したものです。「4月にバージョンを上げたから対応済み」と記録している組織ほど危ないという、いやな構図になっています。

修正状況（2026年8月25日時点）

報告は2026年8月17日にIssue #3506として起票され、既定値を「どのIPも信頼しない」へ変える修正案（PR #3509）が提出されています。ただし執筆時点でこのPRは未マージで、レビューではUnixソケット経由のリバースプロキシ構成が壊れる点やテスト不足が指摘されています。リリース済みの最新版は7.15.4（2026年8月20日）で、これは今回の修正を含みません。

つまり今は「更新して終わり」にできない状態です。当面は設定側で塞ぐしかありません。

今すぐ打てる緩和策は？

--trusted-proxy-ipに自組織のリバースプロキシのIP／CIDRだけを明示するのが最も直接的です。加えて、以下も併せて検討してください。

  • 前段のロードバランサやリバースプロキシで、クライアント由来のX-Forwarded-Uriを削除または上書きする（自分で正しい値を入れ直す）
  • 認証スキップの設定（skip_auth_routes等）を棚卸しし、本当に必要なものだけに絞る
  • OAuth2 Proxyへクライアントが直接到達できないようネットワーク側で経路を制限する
  • 修正版のリリースを追えるよう、GitHubリポジトリのリリース通知を購読しておく

自社が該当するか、どう確かめるか？

まず「動いているか」、次に「どのフラグで動いているか」を見ます。Kubernetes環境なら、Deployment等のマニフェストからコンテナイメージと起動引数を確認するのが早道です。--reverse-proxy、--skip-auth-route／--skip-auth-regex、--trusted-proxy-ipの有無と、イメージタグのバージョンを突き合わせてください。設定ファイル（oauth2-proxy.cfg）や環境変数（OAUTH2_PROXY_*）で渡している場合もあります。前述のとおり、起動ログに信頼プロキシ未設定の警告が出ていれば条件3に該当します。

現場目線の課題

この手のOSSコンポーネントで毎回つらいのは、「知らせてくれるベンダーがいない」ことです。商用製品なら保守窓口から通知が来ますし、JVNにも載ります。しかしOAuth2 Proxyのような部品は、GitHubのAdvisoryを自分で見に行かない限り気づけません。今回のように国内で報じられる頃には修正版がまだ無いという順序になることもあります。

さらに厄介なのは、導入した本人がもう異動している、あるいは「Helmチャートに入っていたので何も設定していない」というケースです。既定値が安全側でない設計は、そういう現場を静かに撃ち抜きます。フラグを1つ足せば防げる問題を、そのフラグの存在を誰も知らないまま4か月放置していた——4月から今回までの経緯は、まさにそれを示しています。限られた人員では監視ダッシュボードの前段までは目が届かない、というのが正直なところではないでしょうか。

情シスはどうすべきか

個別の緩和策は上に書いたとおりですが、本質的な課題は「自社で動いているOSS部品を把握できているか」に尽きます。ここは自前でチェックリストを作り込むより、公的な手引きに沿って仕組み側を整えるほうが確実です。

あわせて、開発・インフラ担当への地道な働きかけも効きます。「リファレンス構成をそのまま入れたら、既定値がどうなっているか一度は読む」という習慣づけは、次に同種の問題が起きたときの被害を確実に減らします。

まとめ

  • OAuth2 Proxy 7.15.2〜7.15.4に認証回避の脆弱性（CVE-2026-76835、CVSS9.3）。X-Forwarded-Uriヘッダを詐称すると認証スキップ判定を欺け、保護対象のパスへ未認証でアクセスされます。
  • 2026年8月25日時点で修正版は未提供。成立条件は「リバースプロキシモード＋認証スキップ設定あり＋--trusted-proxy-ip未設定」の3点で、3つ目は既定値のままだと該当します。
  • 当面は設定で塞ぐ。--trusted-proxy-ipに自組織のプロキシIPを明示し、前段でX-Forwarded-Uriを上書き、認証スキップ設定を最小化してください。4月の7.15.2適用済みでも対策済みにはなりません。

関連記事

出典

タイトルとURLをコピーしました