2026年10月下旬、「phpMyAdminに深刻な脆弱性。二要素認証を回避してデータベースにアクセスできる」という情報がSNSで広まりました。
「うちのサーバーも危ないのでは？」と不安になった方に向けて、この記事では 何が起きているのか、本当に影響があるのは誰か、何をすればいいのか を整理します。公開されている検証コードの解説に加えて、phpMyAdminのソースコードを実際に読んで確かめた内容をもとに書いています。
この記事は2026年10月29日時点の情報です。公式の修正版やセキュリティ勧告が出たら追記します。
先に結論
- 脆弱性そのものは本物です。 phpMyAdminのソースコードを確かめたところ、WebAuthn（セキュリティキー・パスキー）の二要素認証で、署名の検証が行われていませんでした
- ただし、影響を受けるのは次の3つがそろった環境だけです
- MySQLのユーザー名とパスワードが、すでに漏れている
- そのユーザーが、WebAuthnの二要素認証を設定している
- phpMyAdminに
web-auth/webauthn-libというライブラリが入っていない（公式の配布版の初期状態では入っていない） - パスワードを知らない攻撃者が、いきなり侵入できる脆弱性ではありません
- いちばん効く対策は、phpMyAdminをインターネットに公開しないことです
- XserverのphpMyAdminで確かめたところ、二要素認証そのものが使えない設定でした。 同じような共用サーバーの利用者は、まず慌てなくて大丈夫です（詳しくは「レンタルサーバーのphpMyAdminを使っている場合」で）
何が起きているのか
本来のWebAuthnの仕組み
WebAuthnは、セキュリティキーやパスキーを使った認証の方式です。ざっくり言うと、次の流れです。
- サーバーが、ランダムな「チャレンジ」を送る
- ユーザーの端末（セキュリティキー）が、手元にしかない秘密鍵でチャレンジに署名する
- サーバーが、登録してある公開鍵で署名を検証する
この3番目の署名の検証 こそが、「本当にその鍵を持っている」ことの証明です。
phpMyAdminで起きていること
phpMyAdminは、web-auth/webauthn-libというライブラリが入っていればそちらを使い、入っていなければCustomServerという自前のWebAuthnの実装を使う作りになっています。
このCustomServerで、ログインのときの応答を確かめている処理（parseAndValidateAssertionResponse）を読むと、確かめているのは次の項目でした。
- クレデンシャルIDが、登録済みのものか
- 応答の種類が、ログイン用（
webauthn.get）か - チャレンジが一致するか
- オリジン（ホスト名）が一致するか
- rpIdHashが一致するか
- ユーザーがその場にいることを示すフラグ（User Present）が立っているか
一方で、署名（signature）は「値があって、空ではないこと」しか確かめておらず、登録済みの公開鍵での検証は一切行われていません。 登録のときに保存した公開鍵も、この処理では使われていません。
そのため、上の項目さえ合わせれば、でたらめな署名でも二要素認証を通れてしまいます。チャレンジやクレデンシャルIDは、パスワードでログインしたあとにサーバー自身が送ってくるので、パスワードさえ知っていれば、そろえるのは難しくありません。
公開されている情報
- 研究者のAbraxas Labsが、GitHubで検証用のコード（PoC）と解説を公開しています
- 研究者自身の評価はCVSS 8.1（High）
- 2026年10月29日時点で、CVE番号と、phpMyAdmin公式のセキュリティ勧告（PMASA）はまだ出ていません
- 公開されている開発中のブランチ（5.2系の次の版と、6.0の開発版）のソースにも、この時点では署名の検証は入っていません
影響を受ける条件
次の すべて に当てはまる場合に影響があります。
| 条件 | 内容 |
|---|---|
| バージョン | 5.2.1〜5.2.3。研究者が検証したのは5.2.3だが、CustomServerは5.2.1から入っていて、同じ処理になっていることをソースで確かめた。5.2.0以前にはWebAuthnの機能自体がない |
| 二要素認証の方式 | WebAuthn（セキュリティキー・パスキー）を設定している |
| ライブラリ | web-auth/webauthn-libが入っていない |
| 攻撃する側の前提 | 対象のユーザーのMySQLのパスワードを知っている |
web-auth/webauthn-libは、phpMyAdminのcomposer.jsonでは「入れると便利なもの（suggest）」と「開発用（require-dev）」の扱いで、必須ではありません。そのため、公式サイトの配布版や、composer install --no-devでセットアップした環境には入っていません。WebAuthnを使っている人の多くは、この条件に当てはまると考えておくのが安全です。
影響を受けない（状況が変わらない）ケース
- 二要素認証を使っていない
もともとパスワードだけでログインできる状態なので、今回の件でリスクは増えません（もちろん、別の意味での対策は必要です） - 二要素認証に、認証アプリ（6桁のコード）を使っている
Google Authenticatorなどのコードの方式は別の実装なので、今回の対象外です web-auth/webauthn-libが入っている
ライブラリの実装が使われるので、この問題には当たりません- phpMyAdminが、ローカル環境やVPNの中だけで動いている
外から届かなければ、攻撃の入口がありません - 5.2.0以前、または4.9系・5.1系を使っている
WebAuthnの機能がないので対象外です。ただし、どれもサポートが終わっているか古い版なので、別の理由で更新が必要です
「データベース全体にアクセスされる」は本当か
SNSでは「データベース全体が危険」と紹介されていますが、正確には 乗っ取られたMySQLユーザーの権限の範囲で アクセスされる、ということです。
rootのような強い権限のユーザーなら影響は大きくなりますが、特定のデータベースだけに権限を絞ったユーザーなら、その範囲にとどまります。なお、研究者も、サーバー上でプログラムを実行されるわけではない（データベースの中身が見られる・変えられる）と説明しています。
自分の環境を確かめる方法
1. phpMyAdminのバージョンを確かめる
ログインしたあとのトップ画面の右側、「phpMyAdmin」の欄にバージョンが表示されます。
2. 二要素認証の方式を確かめる
「設定」→「二要素認証」を開き、WebAuthn（ハードウェアのセキュリティキー）が設定されているかを確かめます。
3. ライブラリが入っているか確かめる
phpMyAdminを置いているフォルダで、次のどちらかを実行します。
ls vendor/web-auth/composer show web-auth/webauthn-libフォルダがない、またはパッケージが見つからない場合は、問題のあるCustomServerが使われています。
対策
最優先：phpMyAdminを公開しない
今回の件に限らず、phpMyAdminはインターネットに直接さらさないのが基本です。
- IPアドレスで制限する
- 手前にBasic認証を置く
- VPN経由でしかつながらないようにする
- 開発用なら、ローカルのDocker環境だけで使う
これだけで、今回の攻撃の入口はほぼふさがります。
WebAuthnを使っている場合
次のどちらかを行います。
- 署名を正しく検証するライブラリを入れる
composer require web-auth/webauthn-lib- ライブラリを入れられない環境なら、二要素認証を認証アプリ（6桁のコード）の方式に切り替える
パスワードも見直す
今回の攻撃は、パスワードが漏れていることが前提です。
- MySQLユーザーのパスワードを強いものにする
- 使い回しをやめる
- 用途ごとにユーザーを分け、権限を必要最小限にする
公式の修正を待って更新する
phpMyAdminの公式から修正版とセキュリティ勧告が出たら、すぐに更新しましょう。
レンタルサーバーのphpMyAdminを使っている場合
レンタルサーバーが用意しているphpMyAdminは、サーバー会社が管理しています。利用者がライブラリを入れたり、バージョンを上げたりすることは、基本的にできません。ファイルも利用者のフォルダの外にあるので、vendor/web-auth/があるかどうかも、利用者からは確かめられません。
ただ、そもそも二要素認証が使える状態かどうかは、画面から確かめられます。phpMyAdminの公式ドキュメントによると、二要素認証を使うには、先に「phpMyAdmin環境保管領域」（phpMyAdminが設定を保存するための専用のテーブル）を用意しておく必要があるからです。
Xserverで実際に確かめた結果
私が契約しているXserverのサーバーで、サーバーパネルからphpMyAdminを開いて確かめました。
まず、トップ画面の右側の「バージョン情報」は5.2.1でした。WebAuthnの機能が入っている版です。
次に、「設定」→「二要素認証」を開くと、「二要素認証は使用できません。phpMyAdmin環境保管領域を有効にしてください。」と表示されました。方式の一覧にWebAuthnは出てきますが、環境保管領域がないので、設定を保存できません。
つまり、このサーバーのphpMyAdminでは、WebAuthnの二要素認証をそもそも設定できないので、今回の問題には当たりません。 もともとパスワードだけでログインする状態なので、守りの要は、引き続きMySQLのパスワードです。
ほかのレンタルサーバーでも、次の手順で同じように確かめられます。
- サーバーの管理画面からphpMyAdminを開いて、ログインする
- トップ画面の右側で、バージョンを確かめる（5.2.0以前なら対象外）
- 「設定」→「二要素認証」を開き、二要素認証が使える状態か、WebAuthnを設定しているかを確かめる
画面にWebAuthnが設定済みと出た場合は、利用者の側ではライブラリの有無を確かめられないので、認証アプリの方式に切り替えるか、サーバー会社に問い合わせてください。
あわせて気づいたこと：表示されている版が古い
今回の件とは別ですが、表示されている版の5.2.1は、2023年2月に出たものです。2025年1月の5.2.2では、XSSの脆弱性（PMASA-2025-1、PMASA-2025-2）が直っていますが、版の番号の上ではこの修正は含まれていません。
サーバー会社が独自に修正を当てている可能性もあるので、これだけで危ないとは言えません。ただ、レンタルサーバーのphpMyAdminも、いつまでも最新とは限らないことは知っておいて損はありません。利用者にできるのは、変わらず次の3つです。
- データベースのパスワードを強いものにしておく
- サーバー会社からのお知らせを確かめる
- 使わないときはログインしない
情報の受け取り方についての注意
今回の情報は、研究者本人ではなく、別のセキュリティ会社が「無料のセキュリティレビュー」の案内とあわせて広めているケースも見かけました。
脆弱性の情報を見かけたときは、次の一次情報を確かめるのがおすすめです。
- 研究者が公開しているリポジトリや解説
- phpMyAdmin公式のセキュリティ勧告のページ
- 該当するソースコードそのもの
あおり気味の見出しだけで判断せず、「どんな条件で」「何ができてしまうのか」を確かめると、落ち着いて対応できます。
まとめ
- phpMyAdmin 5.2.1〜5.2.3のWebAuthnの二要素認証には、署名を検証しない問題が実際にある
- ただし、悪用には「パスワードの漏えい」「WebAuthnの利用」「ライブラリが入っていない」がすべて必要
- 二要素認証なし、認証アプリの方式、ライブラリ導入済みの環境は対象外
- いちばん効く対策は、phpMyAdminを外に公開しないこと
- 公式の修正版が出たら更新する