2FAuthの脆弱性2件、認証なしで管理者に 8.0.0で修正
2FAuthのリバースプロキシ認証に、ヘッダーを偽装するだけで認証を回避できる脆弱性が2件あり、reverse-proxy-guardを使う環境が対象です。8.0.0へ更新し、アプリがプロキシ経由でしか届かない構成かも確認してください。
同じ発表の脆弱性 2 件
- CVE-2026-63438 重大 9.8
- CVE-2026-63439 重大 9.8
急ぎ度: 至急
2件ともCVSS v3は9.8で、認証なしでネットワークから悪用でき、修正版の8.0.0が出ていて、勧告に再現手順が載っているため、reverse-proxy-guardを使う環境では早く更新したほうがよいと考えます。
関係があるか
2FAuthを自前で運用し、AUTHENTICATION_GUARDにreverse-proxy-guardを指定している組織が対象です。プロキシを通らずにアプリへ直接届く構成だと、外部から悪用されるおそれがあります。
| 製品 | 影響を受ける版 | 修正版 |
|---|---|---|
| 2FAuth（Bubka） | 8.0.0より前の版（GitHubの勧告では7.0.1以前）。AUTHENTICATION_GUARD=reverse-proxy-guardを設定している場合 | 8.0.0 |
確かめ方
- 1設定ファイル（.env）やコンテナの環境変数で、AUTHENTICATION_GUARDがreverse-proxy-guardになっているかを見ます。別の値なら、この2件の前提を満たしません。
- 2稼働中の2FAuthの版が8.0.0より前かを、管理画面の表示かコンテナイメージのタグで確認します。
- 3プロキシを経由せず、アプリのホストやポートに直接つながるかを、社内や外部のネットワークから試します。つながるなら、そのまま悪用の入口になります。
何が起きたか
2FAuthは、二要素認証（2FA）のアカウントを管理し、ワンタイムコードを生成するWebアプリです。reverse-proxy-guardを有効にしていると、手前のプロキシが付けるユーザー名のヘッダーを、アプリがそのまま信用します。8.0.0より前の版は、そのリクエストが信頼するプロキシから来たかを確かめていませんでした。そのため、アプリに直接届く相手がヘッダーを偽造すれば、認証を通過できます。
同じ原因から、次の2件が公表されています。
- CVE-2026-63438: 知らないユーザー名のヘッダーを受け取るとアカウントを自動作成し、最初に作られたアカウントを管理者にします。ヘッダーのメールアドレスでアカウントのメールも書き換えます（CVSS v3は9.8）
- CVE-2026-63439: ヘッダーに既存ユーザーの名前を入れると、その人として認証されます。管理者も例外ではありません（CVSS v3は9.8）
修正版は8.0.0です。GitHubの勧告は、公開日が2026年7月1日と表示されています。CVEの公表は11月6日なので、すでに更新を済ませた環境もあるかもしれません。
攻撃の流れ
-
1
直接到達
プロキシを通らずに2FAuthへ届く経路を見つける。
-
2
ヘッダー偽造
プロキシが付けるはずのユーザー名のヘッダーを自分で付けて送る。
-
3
認証を通過
アプリが送信元を確かめずに信用し、アカウント作成か既存ユーザーへのなりすましが成立する。
-
4
秘密情報へ
保存された2FAの秘密情報や管理機能に触れられる。
どう悪用されるか
どちらも、認証は不要で、ネットワーク越しに仕掛けられ、利用者の操作も要りません。前提は2つあります。AUTHENTICATION_GUARDがreverse-proxy-guardであることと、攻撃者が信頼するプロキシを通らずにアプリへ直接届くことです。
CVE-2026-63438は、条件が少し違います。管理者アカウントを新たに作られるのは、ユーザーが1人もいない新規の環境です。すでに利用者がいる環境では、攻撃者が登録済みの名前を知っているか推測できる場合に、その人のメールアドレスを書き換えられます。CVE-2026-63439は、既存のユーザー名を指定すると、管理者を含む既存ユーザーとして認証されます。
被害として、保存された2FAの秘密情報の閲覧や持ち出しが考えられます。ユーザー管理などの管理機能も使われます。メールアドレスを書き換えられると、パスワード再設定を通じてアカウントを奪われるおそれがあります。
今すぐやること
-
1
reverse-proxy-guardを使っているか確認する
使っていなければ、この2件の前提を満たしません。使っているなら、以降の手順を進めます。
grep -n AUTHENTICATION_GUARD .env -
2
2FAuthを8.0.0に更新する
修正のコミットでは、リクエストが信頼するプロキシから来たかを確かめ、そうでなければ認証を拒否するようになりました。信頼するプロキシの設定が空だと認証が通らない仕様もテストに含まれています。更新後は、信頼するプロキシの設定を確認し、プロキシ経由でログインできるかを試します。
-
3
アプリへの直接到達を止める
ファイアウォールやコンテナのネットワーク設定で、2FAuthがプロキシからの通信しか受けないようにします。更新後も、この構成にしておくと安全です。
-
4
侵害の跡を調べる
心当たりのないユーザーや管理者がいないか、既存ユーザーのメールアドレスが書き換わっていないかを見ます。プロキシを通らない外部からのアクセスがログに残っていないかも調べます。
-
5
秘密情報の漏えいが疑われるときは再発行する
不審なアカウントやメールの書き換えが見つかったら、2FAuthに登録した各サービスの2FAを再設定し、秘密情報を作り直します。
すぐ更新できないとき
すぐに更新できないときは、2FAuthがプロキシからの通信しか受けないようにネットワークで制限します。プロキシ側では、クライアントが送ってきたユーザー名とメールのヘッダーを破棄し、認証済みの値で上書きする設定にします。どちらも更新までのつなぎです。
背景
2FAuthは、自分で運用するタイプの2FA管理アプリです。各サービスのワンタイムコードを作る秘密情報を保存するので、管理者権限や既存ユーザーの権限を奪われると、紐づくサービスのコードを第三者が作れる状態になります。
リバースプロキシ認証は、手前のプロキシやSSO基盤で本人確認を済ませ、結果をユーザー名のヘッダーでアプリに渡す方式です。アプリはヘッダーを信用する代わりに、送り主が信頼するプロキシかを確かめる必要があります。今回の脆弱性（CWE-287）は、この送信元の確認が抜けていたものです。プロキシの設定が正しくても、アプリに直接届く経路が残っていれば、そこから偽のヘッダーを送れてしまいます。
よくある質問
Q.8.0.0に更新したあとも、これまでのリバースプロキシ認証は使えますか。
この記事は、取得元の公開情報をもとに、人が監修しながらAIを活用して執筆しています。執筆と監修は佐々木 航が担い、公開したあとも人が内容を確認しています。誤りに気づいたときは直し、記事の末尾に訂正の行を残します。対応を決める前に、下の原文と参照先も確認してください。
原文の説明 取得元が公開している説明をそのまま載せています (多くは英語)。
2FAuth is a web app to manage Two-Factor Authentication (2FA) accounts and generate their security codes. Prior to 8.0.0, when AUTHENTICATION_GUARD=reverse-proxy-guard accepts authentication headers from a client that did not pass through a trusted proxy, RemoteUserProvider::retrieveById() creates an account for an unknown REMOTE_USER, promotes the first created account to administrator, and synchronizes the account email from the configured mail header. An unauthenticated remote client can therefore create an administrator on a fresh instance or impersonate and redirect email for a known account, exposing 2FA secrets and administrative functions. This issue is fixed in version 8.0.0.
出典: CVE.org (CVE Program・cvelistV5) NVD
参照URL
- web github.com
- web github.com
- web github.com
- web github.com
- web github.com