phpMyAdmin 5.2.3 の 2FA 回避報告｜影響する構成と確認手順

はじめに

2026 年 9 月、セキュリティ研究者の Abraxas Labs が、phpMyAdmin 5.2.3 の WebAuthn 二要素認証（2FA）で、セキュリティキーの署名が検証されない実装があるという研究を公開しました。正しい MySQL のユーザー名とパスワードを持つ攻撃者が、特定の構成ではセキュリティキーを持たずに 2FA を通過できる可能性があるという報告です。

ただし、問題があるのは外部ライブラリが見つからない場合に使われる代替実装です。phpMyAdmin 公式の配布アーカイブを確認したところ、必要なライブラリは同梱されていました。cPanel と Plesk も、自社が提供する phpMyAdmin は影響を受けないと説明しています。「phpMyAdmin 5.2.3 を使っているか」ではなく、どの実装が使われる構成かで影響を判断する必要があります。

結論として、影響を受けるのは、WebAuthn 2FA を使用しており、実行時に代替実装の CustomServer が選択される構成です。公式配布アーカイブには必要なライブラリが同梱されているため、通常のオートロード構成では CustomServer は使われないと考えられます。ログイン画面へ外部から到達できるかどうかは、影響の有無ではなく、攻撃の受けやすさと対応の優先度を判断するために確認します。

phpMyAdmin 5.2.3 の 2FA 回避とは

今回の報告は、phpMyAdmin が外部ライブラリの代わりに使う独自の WebAuthn 実装（CustomServer）で、認証応答の暗号署名を検証していないというものです。phpMyAdmin 5.2.3 全体の問題ではなく、パスワード認証そのものを回避する問題でもありません。

報告と公式情報の時系列

研究者による最初の公開は 9 月 20 日であり、SNS で話題になった日付とは異なります。研究者は CVSS v3.1 で 8.1（High）と評価していますが、このスコアは研究者による評価であり、phpMyAdmin 公式の評価ではありません。研究の詳細は Abraxas Labs の研究記事で公開されています。

2 つの WebAuthn 実装と署名検証の欠落

phpMyAdmin 5.2.3 の WebAuthn プラグインは、Webauthn\Server クラスを読み込める場合は外部ライブラリ web-auth/webauthn-lib を使う WebauthnLibServer、読み込めない場合は独自実装の CustomServer を選択します。

private function createServer(): Server
{
    return class_exists(WebauthnServer::class) ? new WebauthnLibServer($this->twofactor) : new CustomServer();
}

CustomServer の認証処理（parseAndValidateAssertionResponse()）を公式ソースで確認すると、次の構造的な検証は行われています。

• 認証情報の ID が登録済みのものか
• クライアントデータの種別が webauthn.get か
• チャレンジがセッションの値と一致するか
• オリジンのホスト名と rpIdHash が一致するか
• ユーザー存在（User Present）フラグが立っているか

しかし、登録時に保存した公開鍵で認証応答の署名を検証する処理はありません。署名フィールドは存在と形式だけが確認され、内容は検証に使われていません。WebAuthn の安全性は、セキュリティキーの秘密鍵で作成された署名を公開鍵で検証することで成り立つため、この処理が欠けると、構造上の条件を満たした偽の応答が受け入れられる可能性があります。

なお、WebAuthn 実装を追加した phpMyAdmin のプルリクエストでも、開発者は独自サーバーについて一部の検証が未完成であると説明していました。

影響条件と攻撃成立条件

研究者の報告と公式コードに基づき、脆弱な状態にあるかを決める条件と、実際に攻撃が成立するために必要な条件を分けて整理します。

インターネットから到達できないことは、脆弱な実装が存在しないことを意味しません。社内ネットワークからの攻撃や、将来の公開範囲の変更に備え、技術的な影響条件に該当する場合は構成の見直しを計画することを推奨します。

研究者自身も、MySQL のパスワードがない状態ではログイン画面にとどまることを確認したと記載しています。パスワードなしでデータベースへ侵入できる問題ではなく、パスワード漏えい時の防御である 2FA が機能しない可能性がある問題です。

また、phpMyAdmin の 2FA には複数の方式があります。今回の対象は WebAuthn（画面上の名称は「Hardware Security Key (WebAuthn/FIDO2)」）であり、認証アプリによる TOTP や、従来の FIDO U2F プラグインは別の実装です。

2FA を回避された場合の影響

2FA を回避してログインできた場合、攻撃者は入手した MySQL アカウントの権限の範囲で、データの閲覧・エクスポート、変更・削除、権限に応じたユーザー管理などを行える可能性があります。操作できる範囲はアカウントに付与された権限によって異なり、すべてのデータベースを操作できるとは限りません。

参考: Abraxas Labs（GitHub PoC リポジトリ）
“That is the database (SQL, users, export), not a PHP shell on the host.”
（影響はデータベース（SQL、ユーザー、エクスポート）であり、ホスト上の PHP シェルではない。）
https://github.com/abraxas/phpmyadmin-webauthn

研究記事のタイトルには「RCE」という語が含まれますが、研究者は「データに対する操作」という意味で使っており、OS コマンドの実行や PHP シェルの取得は実証範囲外としています。研究者が実証したのは 2FA の回避と phpMyAdmin へのログインまでです。

影響する構成と影響しない構成

影響の分かれ目は、実行時に WebauthnLibServer と CustomServer のどちらが選択されるかです。研究者は標準配布物が影響すると主張していますが、公式配布アーカイブの内容とは一致しませんでした。

研究者のラボ構成と公式配布アーカイブの違い

研究者は、5.2.3 の標準 tarball には web-auth/webauthn-lib が含まれず、CustomServer が使われると主張しています。一方で、ライブラリを導入した環境は今回の問題に該当しないとも明記しています。

参考: Abraxas Labs
“If you actually installed web-auth/webauthn-lib, you are on WebauthnLibServer and not this bug.”
（web-auth/webauthn-lib を実際に導入していれば WebauthnLibServer が使われ、この問題には該当しない。）
https://abraxaslabs.tech/research/PMA-5.2.3-WebAuthn-2FA

研究者が公開しているラボ環境の Dockerfile は、依存関係を導入した後に vendor/web-auth を手動で削除し、Webauthn\Server クラスが存在する場合はビルドを失敗させる構成です。つまり、ライブラリを意図的に取り除いた状態で検証しています。

これに対し、phpMyAdmin 公式サイトから取得した 5.2.3 の配布アーカイブ（phpMyAdmin-5.2.3-all-languages.tar.gz と .zip。いずれも公式公開の SHA-256 と一致）の内容を確認したところ、次の状態でした。

• vendor/autoload.php と vendor/composer/autoload_psr4.php が含まれ、Webauthn\ 名前空間が登録されている
• vendor/web-auth/webauthn-lib/src/Server.php が含まれ、Webauthn\Server クラスが定義されている
• 同梱の composer.lock で、web-auth/webauthn-lib v3.3.12 が本番用の packages に記録されている

公式リポジトリ RELEASE_5_2_3 タグのリリース用スクリプトも、このライブラリを導入し、見つからない場合はビルドを中断する処理になっています。

参考: phpMyAdmin 公式リポジトリ scripts/create-release.sh（RELEASE_5_2_3）
“Webauthn-lib should be installed, detection failed !”
（Webauthn-lib がインストールされているべきだが、検出に失敗した。）
https://github.com/phpmyadmin/phpmyadmin/blob/RELEASE_5_2_3/scripts/create-release.sh

公式配布アーカイブには必要なライブラリが同梱されており、通常のオートロード構成であれば、脆弱な代替実装の CustomServer は使用されないと考えられます。なお、この判断はアーカイブの内容確認に基づくものであり、Web サーバー上でクラスの読み込みやログイン処理を実行して確かめたものではありません。

構成別の影響判定表

cPanel と Plesk の見解は、それぞれ cPanel のサポート記事と Plesk のサポート記事で確認できます。いずれも各社が標準で提供する phpMyAdmin についての説明であり、利用者が独自に導入した phpMyAdmin や、構成を変更した環境まで一律に対象外となるわけではありません。

また、5.2.3 のコードでは、WebAuthn は外部ライブラリの有無にかかわらず 2FA の選択肢として表示されます。ライブラリが欠けた環境でもユーザーが WebAuthn を登録できるため、管理者が把握していない利用がないかも確認が必要です。

研究者が検証したのは 5.2.3 のみです。5.2.3 以外のバージョンへの影響は、本記事の時点で研究者・公式のいずれからも示されていません。

phpMyAdmin の影響確認手順

以下は、phpMyAdmin 5.2.3 の公式ソースコード（RELEASE_5_2_3 タグ）の実装に基づく、読み取り専用の確認手順です。本記事の手順は実機での動作検証を行ったものではありません。パスや PHP の実行環境は自環境に合わせて読み替えてください。例では phpMyAdmin の設置パスを /var/www/phpmyadmin としています。

grep -ril phpmyadmin /etc/apache2 /etc/httpd /etc/nginx 2>/dev/null

dpkg -L phpmyadmin | grep Version.php

rpm -ql phpMyAdmin | grep Version.php

grep "VERSION = " /var/www/phpmyadmin/libraries/classes/Version.php

grep -n "autoloadFile" /var/www/phpmyadmin/libraries/vendor_config.php

ls -l /var/www/phpmyadmin/vendor/web-auth/webauthn-lib/src/Server.php

php -r 'require "/var/www/phpmyadmin/vendor/autoload.php"; var_dump(class_exists("Webauthn\\Server"));'

SELECT username FROM phpmyadmin.pma__userconfig WHERE config_data LIKE '%"backend":"WebAuthn"%';

本記事では、PoC の攻撃リクエストを本番環境へ送信する確認方法は扱いません。研究者もループバック環境のラボでのみ実行するよう求めています。

修正版の状況と暫定対策

2026 年 10 月 29 日時点で、今回の問題を修正した安定版は公開されていません。確認手順で影響する構成と判断した場合は、修正版を待つ間、攻撃の前提条件を崩す対策を優先します。

2026 年 10 月 29 日時点の修正状況

公式ダウンロードページには 5.2 系と 6.0 系の日次スナップショットが掲載されていますが、これらは開発版です。今回の問題の修正を含むと公式に示されたものではないため、修正版として扱わないでください。最新情報は phpMyAdmin のセキュリティページで確認できます。

影響する構成だった場合の暫定対策

1. インターネットへの公開を避ける

ログイン画面に到達できなければ、外部からの攻撃は成立しません。外部公開している phpMyAdmin は、公開を停止するか公開範囲を限定することを最優先で推奨します。

2. VPN や IP アドレス制限で管理経路を限定する

Web サーバー、ファイアウォール、リバースプロキシーで、VPN 経由や特定の管理用 IP アドレスからのアクセスに限定します。phpMyAdmin 自体にも、MySQL ユーザーと接続元を組み合わせて制限する $cfg['Servers'][$i]['AllowDeny'] や、root でのログインを禁止する $cfg['Servers'][$i]['AllowRoot'] の設定があります（5.2.3 の既定設定ファイル）

3. MySQL アカウントのパスワードと権限を見直す

今回の問題はパスワードの入手が前提です。使い回しや漏えいの可能性があるパスワードは変更し、phpMyAdmin で使うアカウントには業務に必要な最小限の権限だけを付与します。

4. CustomServer が選択されない構成へ切り替える

ライブラリが同梱された公式配布アーカイブへの置き換えや、web-auth/webauthn-lib の追加導入を検討します。いずれも依存関係や PHP のバージョンとの互換性に影響するため、本番環境へ直接適用せず、検証環境で動作を確認してから反映してください。切り替えまでの間に 2FA の方式を変更する場合も、WebAuthn を単に無効化するだけでは認証強度が下がるため、TOTP への切り替えや上記のアクセス制限と組み合わせて実施します。

5. 公式の修正版とアドバイザリを確認する

phpMyAdmin のセキュリティページ、利用している OS パッケージや管理ツールの配布元の情報を継続して確認し、修正版が公開された時点で適用計画を立てます。

運用上の注意点

影響の有無にかかわらず、確認作業にあわせて次の点に注意してください。

対象外の構成でも公開範囲の見直しは有効

公式配布アーカイブや TOTP を使っている環境は今回の問題の対象外です。ただし、phpMyAdmin のログイン画面をインターネットに公開している場合、パスワード推測など別の攻撃を受ける余地は残ります。今回の確認を機に、管理画面の公開範囲そのものを見直すことをおすすめします。

不審なログインがないかを確認する

影響する構成で外部公開していた場合は、Web サーバーのアクセスログで想定外の接続元から phpMyAdmin へのアクセスがないか、MySQL 側で不審なアカウントや権限変更がないかを確認します。不正アクセスが疑われる場合の初動は、『不正アクセスの確認と対応についての記事』も参考にしてください。

PHP 本体の脆弱性とは別件

2026 年 10 月には PHP 本体のリモートコード実行の脆弱性も公表されていますが、今回の phpMyAdmin の認証実装の問題とは別の問題です。PHP 本体の更新で今回の問題が解消されるわけではないため、両方を個別に確認してください。PHP 側の内容は『PHP の脆弱性についての記事』で解説しています。

まとめ

phpMyAdmin 5.2.3 の WebAuthn 2FA 回避報告は、ライブラリが欠けた場合に使われる代替実装 CustomServer の署名検証不備です。公式配布アーカイブにはライブラリが同梱されているため、影響はバージョンではなく、実行時に選択される実装と WebAuthn 2FA の利用状況で判断します。

• 問題はライブラリ欠落時の代替実装に限られます。
• 研究者のラボはライブラリを手動削除した構成です。
• 公式配布アーカイブには必要なライブラリが同梱されています。
• cPanel と Plesk は標準提供の phpMyAdmin を対象外としています。
• 攻撃には有効な MySQL の認証情報と画面への到達が必要です。
• 外部公開の有無は影響ではなく対応の優先度を左右します。
• CVE 番号、公式アドバイザリ、修正版は 10 月 29 日時点で未公開です。

以上、最後までお読みいただきありがとうございました。