【更新 2026-08-09】本記事を見直し、修正しました。主な修正点：影響を受けるバージョンを「4.7以降」から「7.0.3より前のすべて（4.7は修正バックポートの下限であって影響範囲の下限ではない）」に訂正、悪用状況の根拠をCISA KEV（2026-08-09時点で未収録）に差し替え、CVSS 8.9の出典を「報道」からCVE採番元の登録値（NVD掲載）に訂正しました。
WordPress本体（コア）に、ログイン画面の認証不要なクロスサイトスクリプティング（XSS）脆弱性が見つかりました。CVE-2026-64638として管理され、修正版のWordPress 7.0.3が2026年8月6日（現地時間）に公開されています。対象は7.0.3より前のすべてのバージョン（修正のバックポートは4.7まで）で、実証コード（PoC）もすでに公開済みです。
ただし「認証不要のXSS」＝「即座に全サイトが乗っ取られる」ではありません。PHPコード実行にまで至るには管理者としてログイン中の人が、攻撃者の用意したリンクを踏む必要があります。つまりこれは無差別攻撃ではなく標的型です。だからこそ、更新作業と同じくらい「WordPressの管理者権限を持っている人が社内外に誰なのか」の把握が重要になります。
この記事でわかること
- CVE-2026-64638で何が起きるのか（攻撃の成立条件）
- 自社が影響を受けるかどうかの判別と、旧バージョン利用時の対応
- 同時に修正された残り11件のうち、実務上見落としやすいもの
- 情報源によってCVSSスコアが割れている理由と、優先度判断への影響
- 自動更新に任せている場合の落とし穴
何が起きたのか
WordPress.orgは2026年8月6日（現地時間）、セキュリティリリースとして7.0.3を公開しました。日本語版のリリースノートも8月7日に公開されています。修正されたのは合計12件で、そのうち最も深刻なのが次の1件です。
| 項目 | 内容 |
|---|---|
| CVE | CVE-2026-64638 |
| 種別 | 反射型クロスサイトスクリプティング（XSS） |
| 該当箇所 | ログイン画面（認証前にアクセス可能） |
| 想定される影響 | PHPコードの実行に至る可能性 |
| 対象バージョン | 7.0.3より前のすべて（CVEレコードは「WordPressのすべてのバージョンが影響を受ける」と記載） |
| 修正版 | 7.0.3（旧ブランチにもバックポート） |
| 報告者 | pwn.ai |
| 公表 | 2026年8月6日リリース、7日に技術詳細が公開 |
攻撃手法は研究者らによって「XSS2Shell」と名付けられ、実証コードを含む技術詳細が公開されています。なお、2026年8月9日時点で、実際の悪用（in the wild）を示す公的な報告は確認されていません（CISAの「悪用が確認された脆弱性カタログ（KEV）」にも未収録。カタログ版2026.08.07）。ただし実証コードが出回っている以上、猶予があると考えるべきではありません。
なぜXSSがPHPコード実行につながるのか
XSSはブラウザ上でJavaScriptが動く脆弱性であり、通常はサーバ側のPHP実行までは届きません。今回問題になったのは、その先に伸びる攻撃の連鎖です。
報告によると、起点はログイン画面のユーザー名入力の処理にあります。入力値は sanitize_user() や wp_strip_all_tags() といった無害化処理を通るものの、空白を含んだタグ状の文字列が完全には落ちきらず、後段の wp_kses_post() がそれを「許可されたHTML」として解釈してしまう、という組み合わせの問題です。結果として攻撃者が制御するDOM要素がログイン画面に出現します。
そこから先は、ユーザープロフィール管理用のスクリプトとREST APIのJSONP機能を経由して、同一オリジンでのリクエストをJavaScriptから発火させる、という流れになります。管理者権限のセッションでこれが動けば、WordPressの管理画面から本来管理者ができること——すなわちコードの書き込み——が攻撃者の意図どおりに実行されうる、というのが「PHPコード実行」の中身です。
XSSそのものの仕組みについてはクロスサイトスクリプティング（XSS）とは？仕組みと対策で解説しています。
攻撃が成立する条件は？
成立には「管理者権限でログイン中の人が、攻撃者の用意したURLを開く」ことが必要です。反射型XSSは保存型と違い、細工したリンクを踏んだ本人のブラウザでしか発火せず、自動的に拡散もしません。踏んだ人が管理者でなければ、コード実行までは至りません。
裏を返せば、攻撃者は「このサイトの管理者は誰か」を調べたうえで、その人にリンクを送りつけることになります。フィッシングメールやSNSのDMと組み合わさる前提だと考えてください。技術的な更新作業と、管理者アカウント保有者への注意喚起は、セットで進める必要があります。
同時に修正された残り11件
CVE-2026-64638ばかりが注目されていますが、他の11件にも実務上の意味があります。特に「寄稿者（Contributor）以上の権限があれば悪用できる」ものが5件ある点は見落としがちです。
| 内容 | 必要な権限 |
|---|---|
| 絵文字設定要素を介した投稿内の保存型XSS | 寄稿者以上 |
| 「投稿コンテンツ」ブロックの保存型XSS | 寄稿者以上 |
| 「クイック編集」機能の保存型XSS | 寄稿者以上 |
| 「投稿日」ブロックの保存型XSS | 寄稿者以上 |
| CSS属性フィルターのバイパス | 投稿者以上 |
| マルチサイトネットワークの権限昇格 | マルチサイト環境 |
| 「最新のコメント」ブロックの情報漏洩 | — |
| 投稿スラッグの列挙 | — |
| コメントフィードにおけるメモの漏洩 | — |
| メールアドレス確認フローのバイパス | — |
| URL検証におけるSSRF | — |
外部ライターや制作会社、インターンにアカウントを配っているサイトでは、この「寄稿者以上」の条件はハードルになりません。保存型XSSは反射型と違い、仕込まれた内容を閲覧した人のブラウザで自動的に発火します。標的型のCVE-2026-64638よりも、こちらのほうが自社の状況次第では現実的なリスクになりえます。
自社は影響を受けるか
判断は単純で、WordPress 7.0.3より前を使っていれば対象です。管理画面の「ダッシュボード → 更新」、またはページのソースに出力される <meta name="generator"> で確認できます。
旧ブランチを使っている場合も、修正は4.7まで遡ってバックポートされています。7.0系でなくとも、各ブランチの最新版に上げれば対処できます。逆に4.7より古いバージョンは、影響を受けるもののバックポートの対象外で、修正は提供されません。この場合は本体のアップグレードそのものが課題になります。
自動更新に任せていて大丈夫か
WordPressはマイナーリリースを自動バックグラウンド更新する仕組みを持ち、公式も「対応しているサイトではまもなく更新が開始されます」と案内しています。ここが落とし穴です。
実務では、自動更新が切られているケースが珍しくありません。テーマやプラグインとの相性問題を避けるために制作会社の保守方針で無効化されている、WP_AUTO_UPDATE_CORE を false にしている、ファイルシステムが書き込み不可（読み取り専用デプロイやコンテナ運用）で自動更新が走れない、といった構成です。「自動更新のはずだから見なくていい」ではなく、更新後のバージョン番号を実際に目で確認するところまでを1セットにしてください。ステージング環境や、公開を止めたまま放置されている旧サイトも同様です。
CVSSスコアが情報源で割れている
今回、公表されているスコアが情報源によって食い違っています。CVE採番元が登録したCVSS v4.0ベーススコアは8.9（重要度：高）で、NVDにもこの値が掲載されています。一方、脆弱性データベースのPatchstackは7.1を掲載しています。
これは評価者が「PHPコード実行に至る条件（管理者のクリックが必要）」をどう重み付けするかの差だと考えられます。前提条件を織り込めばスコアは下がり、最悪ケースを重く見れば上がります。どちらかが誤っているというより、評価の観点が違うということです。
現場としては、スコアの数字だけで優先度を機械的に決めないのが実務的な結論になります。今回の場合、判断材料は「実証コードが公開済み」「対象が4.7以降と極めて広い」「更新自体は数分で終わる」の3点で、これだけで十分に「すぐやる」と言えます。優先度づけの考え方は脆弱性管理とは？プロセスと情シスの進め方も参考にしてください。
現場目線の課題：WordPressは「情シスの管理外」にありがち
正直なところ、この手の脆弱性で一番やっかいなのは技術ではなく持ち主が誰か分からないWordPressです。
コーポレートサイトは広報部、採用サイトは人事部、製品のキャンペーンLPは事業部、それぞれ別の制作会社が構築している——という構図は、多くの会社で見覚えがあるはずです。情シスの資産台帳にはサーバもドメインも載っていないのに、いざ改ざんされれば対応の矢面に立つのは情シスです。
さらに今回は、7月にCISAが悪用を警告したWordPressコアの脆弱性連鎖（修正版7.0.2）からわずか3週間で再びコアの更新です。「先月更新したばかりだから大丈夫」という感覚が、今回に限っては最も危ない。プラグイン側でもSSOプラグインの認証回避のような問題が続いており、WordPress周辺は当面「頻度が高い前提」で構えるほかありません。
そして、限られた人員で社外の制作会社に連絡を取り、更新の実施と完了報告まで追いかけるのは、実際にはかなり骨が折れます。だからこそ、脆弱性が出てから連絡先を探し始めるのではなく、平時のうちに「うちのWordPressサイト一覧と、それぞれの更新責任者」を1枚の表にしておくことの価値が大きいと感じます。今回のような連続更新の局面で、この1枚があるかどうかで対応速度がまるで変わります。
情シスはどうすべきか
まずは7.0.3（または利用中ブランチの最新版）への更新が最優先です。ダッシュボードの「更新」から「今すぐ更新」で適用できます。そのうえで、次の2点を並行して進めてください。
- 管理者権限アカウントの棚卸し：今回のRCE経路は管理者のクリックが起点です。退職者・契約終了した制作会社のアカウントが管理者のまま残っていないかを確認し、不要なものは権限を下げるか削除します。
- 管理者・編集者への注意喚起：「WordPressにログインした状態で、心当たりのないリンクを開かない」という一文を、Web担当者と制作会社に共有してください。技術的な修正が終わっても、標的型の入口は人です。
体系的な対策の進め方は、自前でチェックリストを作り込むより公的機関の指針をそのまま使うほうが確実です。IPAの中小企業の情報セキュリティ対策ガイドラインは、資産の把握と管理責任者の明確化という今回まさに効く部分を扱っています。エンドユーザ側の啓発には対策のしおりが使いやすく、「リンクを安易に踏まない」といった地道な周知の土台になります。派手さはありませんが、標的型の入口を塞ぐのは結局こうした啓発の積み重ねです。
万一、更新前に踏まれた可能性がある場合は、更新して終わりにせず侵害の有無を確認する必要があります。管理者ユーザーの追加履歴、テーマ・プラグインファイルの更新日時、見覚えのないPHPファイルの有無などが確認の入口です。実際に改ざんが起きた場合の初動はWebサイト改ざんで外部誘導、情シスの初動と対策にまとめています。
まとめ
- WordPress 7.0.3で12件が修正された。最も深刻なのはログイン画面の認証不要な反射型XSS（CVE-2026-64638）で、対象は4.7以降のすべて。実証コードは公開済み、8月9日時点で公的な悪用報告（CISA KEV収録）はなし。
- PHPコード実行には管理者のクリックが必要な標的型。更新と同時に、管理者権限アカウントの棚卸しと、管理者・制作会社への注意喚起をセットで行う。
- 自動更新任せにせず、バージョン番号を目で確認する。広報・人事・事業部が個別に持つWordPressサイトこそ抜けやすい。平時に「サイト一覧と更新責任者」の表を用意しておく。
出典
- WordPress 7.0.3リリース – WordPress.org 日本語
- WordPress 7.0.3 release – WordPress News
- WordPress 7.0.3 Released: 12 Vulnerabilities Found and Fixed – Patchstack
- CVE-2026-64638 – NVD
- Patchstack 脆弱性データベース：CVE-2026-64638
- New WordPress Pre-Auth XSS Could Lead to PHP Code Execution – The Hacker News
- 「WordPress」のログイン画面にXSS脆弱性 – 修正版を公開 – Security NEXT
- 中小企業の情報セキュリティ対策ガイドライン – IPA
