XSS2Shell（CVE-2026-64638）とは？WordPressの脆弱性の影響と対策をわかりやすく解説

2026年8月6日、WordPress本体（WordPressコア）のログイン画面に関する脆弱性「XSS2Shell」が公表されました。正式な識別番号は CVE-2026-64638 です。

この脆弱性は特定のプラグインやテーマではなく、WordPress本体に存在します。そのため「プラグインをほとんど入れていないから大丈夫」という考え方は通用しません。

株式会社オレンジソフトウェアでは、数多くのWordPressサーバーの構築・運用・保守に携わり、WordPress本体やプラグインが適切に自動更新されるよう、サイトごとの構成を確認しながら設定しています。ただし、自動アップデートは「ONにすれば終わり」ではありません。更新が実際に適用されたかの確認、バックアップ、ファイル権限、プラグインとの互換性、障害時に復旧できる体制まで含めて考える必要があります。

この記事では、前半で非エンジニアの方にも分かる言葉で概要と対応方法を、後半でエンジニア・サーバー管理者向けに仕組みと確認方法を解説します。

先に結論：いま実行すべきこと

1. WordPress本体を 7.0.3（または利用中の系列の修正版）以上に更新する
2. 更新後にバージョンが実際に変わったかを管理画面で確認する
3. 管理者ユーザーとアプリケーションパスワードに見覚えのないものがないか確認する
4. WordPressにログインしたまま、不審なメール・SNSのリンクを開かない

※ 2026年8月10日時点で、この脆弱性を再現する実証コード（PoC）はすでに一般公開されています。悪用報告を待たずに対応してください。

この記事について 本記事は、株式会社オレンジソフトウェアが2026年8月10日時点で公開されているWordPress公式情報、CVE／NVD情報、GitHub Security Advisory、公的機関の注意喚起、セキュリティ研究者の技術情報などを調査し整理したものです。正確性には十分注意していますが、公開後に情報が更新される可能性や、解釈・記載に誤りが含まれる可能性があります。実際の対応は、WordPress公式の最新情報、ご利用中のサーバー会社からの案内、専門家の判断もあわせてご確認ください。

【一般の方向け】XSS2Shellの要点

XSS2Shellとは何ですか？

XSS2Shellは、WordPressのログイン画面の表示処理を悪用し、攻撃者が用意したJavaScriptを被害者のブラウザ上で実行できる脆弱性です。

名前の「XSS」はWebページに不正なスクリプトを実行させる攻撃を指し、「Shell」は攻撃がさらに進むとサーバー上で不正なプログラムを実行される可能性があることを表しています。

WordPress公式は2026年8月6日に公開した WordPress 7.0.3 の説明で、この問題を「ログイン画面における認証前の反射型XSSで、PHPコードの実行につながる可能性がある」と案内しています。なお 7.0.3 は、XSS2Shellを含む合計12件のセキュリティ問題を修正するリリースです。

プラグインを入れていなくても影響しますか？

はい。今回の問題はWordPress本体にあるため、次のようなサイトも確認が必要です。

• 会社案内だけを掲載している小規模なWordPressサイト
• 更新をほとんど行っていない古いホームページ
• プラグインをほとんど使っていないサイト
• 管理画面に普段ログインしないサイト
• 制作会社から納品された後、そのままになっているサイト

CVEの公式記録およびGitHub Security Advisoryでも、WordPressコアのログイン画面に存在する認証前の反射型XSSとして登録されています。

URLを開くだけで、すぐにサーバーを乗っ取られるのですか？

「誰でもWordPressにアクセスするだけで、すぐにサーバーを乗っ取れる」という説明は正確ではありません。

XSS（スクリプト実行）の入口については、攻撃者はWordPressのアカウントを持っていなくても成立させられます。一方、サーバー上でPHPコードを実行する段階まで進むには、WordPressにログイン中の管理者が、攻撃者の用意したページを開く・リンクをクリックするといった能動的な操作が必要です。

これは公式のCVSS評価にも表れています。CVSS v4.0のベクトルは次のとおりで、AC:H（攻撃条件が複雑）、UI:A（利用者の能動的な操作が必要） と評価されています。

CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:A/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H  →  8.9 High

米国NVDの説明でも、RCEへの発展は「攻撃者の制御下にない条件が揃った場合」とされています。

つまり完全な「ゼロクリック攻撃」ではありません。ただし、攻撃者が取引先やWordPressサポートを装ったメール、偽のセキュリティ情報、SNSのメッセージなどを使えば、管理者がリンクを開いてしまう可能性は十分にあります。 「条件が必要＝安全」ではない点にご注意ください。

何が起きる可能性がありますか？

攻撃が成立すると、状況によっては次のような被害につながる可能性があります。

• WordPress管理者の権限を悪用される
• 不正なページや記事を公開される
• 不正なプラグインやPHPファイルを設置される
• ホームページを改ざんされる
• フィッシングページや迷惑メールの送信に利用される
• サーバー内の情報を閲覧・変更される
• 同じサーバーにある別サイトへ影響が広がる

実際の影響範囲は、WordPressの構成、管理者権限の設計、サーバー設定、WAFの有無などによって変わります。

どのバージョンが危険ですか？（修正版一覧）

WordPress公式は2026年8月6日に 7.0.3 を公開し、セキュリティ修正の対象となる過去系列（4.7以降）にも修正をバックポートしています。4.7.0〜7.0.2のすべてが影響を受けます。

主要な系列の修正版は次のとおりです。

さらに古い系列にも、6.3.9 / 6.2.10 / 6.1.11 / 6.0.13 / 5.9.14 / 5.8.14 / 5.7.16 / 5.6.18 / 5.5.19 / 5.4.20 / 5.3.22 / 5.2.25 / 5.1.23 / 5.0.26 / 4.9.30 / 4.8.29 / 4.7.34 として修正版が提供されています。

ただし、WordPress公式が積極的にサポートしているのは最新系列です。古い系列の修正版を当てただけで長期間使い続けるのではなく、テーマ・プラグインの互換性を確認したうえで最新系列へ移行することをおすすめします。

自動アップデートをONにしていれば安全ですか？

自動アップデートをONにすることは非常に重要ですが、それだけで必ず安全とは限りません。 理由は主に5つあります。

1. 「自動アップデートON」の範囲が違うことがある

WordPress本体・プラグイン・テーマは、それぞれ別に自動更新の設定があります。プラグインの自動更新がONでも、WordPress本体が更新されるとは限りません。

WordPress公式ドキュメントによると、既存サイトでは標準でマイナー更新のみが自動適用される構成があります。WordPress 5.6以降に新規作成したサイトでは、条件によってメジャー更新とマイナー更新の両方が有効になりますが、設定や設置方法によって動作は変わります。

2. 設定上はONでも、更新に失敗することがある

ファイル権限の不備、WordPress.orgへの通信失敗、容量不足、タイムアウト、Gitなどバージョン管理の検出、更新を無効化する設定などにより、自動更新が実行されないことがあります。WordPress公式も、通信上の問題や不適切なファイル権限により自動更新が失敗する場合があると説明しています。

3. 更新できても、サイトが正常とは限らない

本体の更新が完了していても、古いテーマやプラグインとの互換性問題で表示崩れやエラーが発生する場合があります。更新後にトップページ・問い合わせフォーム・管理画面が正常に動作しているかの確認が必要です。

4. 更新前に侵入されていた場合、更新だけでは元に戻らない

脆弱性を修正しても、すでに不正な管理者・アプリケーションパスワード・プラグイン・PHPファイルが作られていれば、それらが自動的に消えるわけではありません。

5. バックアップが正常に戻せるとは限らない

自動取得していても、保存先の容量不足や処理失敗でデータが残っていないことがあります。WordPress公式も、自動バックアップだけに頼らず、ときどき手動で確認することを推奨しています。

では、どうすればよいですか？（チェックリスト）

オレンジソフトウェアが実施しているWordPress保守の進め方

「自動更新をONにした」という設定だけでは、サイトを守り切れません。株式会社オレンジソフトウェアでは、今回のような緊急のセキュリティリリースが出た際に、設定の確認で終わらせず、適用結果まで追い、その後も監視し続ける進め方をとっています。実際の流れは次のとおりです。

ステップ1｜対象サイトの棚卸し

管理しているWordPressサイトを一覧化し、現在のバージョン・系列・PHPバージョンを洗い出します。「どのサイトが影響を受けるか」を先に確定させることで、対応の優先順位を決められます。ここが曖昧なままだと、更新漏れのサイトが必ず残ります。

ステップ2｜更新前のバックアップ取得

WordPressのファイル一式とデータベースを取得します。重要なのは 「取得できたこと」ではなく「戻せること」 です。保存先の容量、ファイルサイズ、取得時刻を確認します。

ステップ3｜更新の適用

自動更新が有効なサイトは適用状況を確認し、適用されていないサイトは手動で更新します。テーマやプラグインのカスタマイズが入っているサイトは、影響を確認しながら進めます。

ステップ4｜適用結果の確認（最重要）

管理画面の表示だけを信じず、実際のバージョン番号が変わっているかを確認します。オレンジソフトウェアでは、多数のサイトを扱う都合上、WP-CLIでバージョンを一括取得して確認する方法を用いています。

「自動更新ONと表示されていたのに、実際には数か月前のバージョンのまま止まっていた」というケースは、実務では珍しくありません。ファイル権限、外部通信、プラグインによるフィルターなど、原因はさまざまです。この確認工程を省くと、対応したつもりで無防備なまま運用が続きます。

ステップ5｜更新後の表示・動作確認

トップページ、下層ページ、問い合わせフォーム、管理画面の動作を確認します。特に問い合わせフォームは、壊れていても気づきにくく、そのままだとビジネス上の機会損失に直結する箇所です。

ステップ6｜監視による継続的な確認（Uptime Kuma）

更新作業のたびに人手で全サイトを目視確認するのは現実的ではありません。オレンジソフトウェアでは、管理しているサイトの監視に Uptime Kuma（オープンソースの監視ツール）を自社サーバー上で運用しています。

Uptime Kumaを使うことで、次のような確認を自動化できます。

重要なのは、「更新した瞬間だけ確認する」のではなく「更新後も継続的に監視され続けている」状態を作ることです。 更新直後は正常でも、キャッシュが切れたタイミングや特定ページのアクセス時にはじめて不具合が表面化するケースがあります。

なお、監視ツールは死活・表示の異常を検知するものであり、改ざんや不正ファイルの設置そのものを検知するわけではありません。 ステップ7の侵害確認とは役割が異なる点にご注意ください。

ステップ7｜侵害の痕跡確認

管理者ユーザー、アプリケーションパスワード、wp-content 配下の不審なPHPファイル、最近作成された投稿・固定ページなどを確認します。脆弱性の修正と、すでに入られていないかの確認は別作業です。

ステップ8｜問題発生時の切り戻し

更新後に不具合が出た場合は、ステップ2のバックアップから切り戻し、原因を切り分けたうえで再度対応します。切り戻せる状態を作ってから更新する、という順序が守られていることが前提になります。

WordPressは、制作して公開した後も継続的な管理が必要なシステムです。「ホームページが表示されているから問題ない」と判断せず、定期的にバージョンと運用状態を確認することが重要です。

WordPressの保守・セキュリティ対応でお困りではありませんか？ 「今のバージョンが分からない」「自動更新が正常に動いているか不安」「長期間更新していないサイトがある」といったご相談を承っています。サーバー構築から公開後の運用まで一貫して対応可能です。 ▶ WordPress保守について相談する

【エンジニア・サーバー管理者向け】CVE-2026-64638の技術情報

脆弱性の基本情報

脆弱性の入口：サニタイズ処理の解析差（parser differential）

存在しないユーザー名でログインを試みると、WordPressは入力されたユーザー名をログインエラーに含めて表示します。この入力値は複数のサニタイズ処理を通過しますが、wp_strip_all_tags()（内部でPHPの strip_tags() を使用）と wp_kses_post() の間でタグの解釈が食い違います。

• strip_tags() は < area id=test> のように < の直後に空白が入った文字列をタグとして認識しない ため、除去せずそのまま通します
• wp_kses_post() は同じ文字列を 正規の <area> 要素として解釈 し、許可済みHTML要素として出力します

この結果、攻撃者が指定した属性を持つDOM要素がログイン画面に生成されます。

XSSからPHPコード実行までのチェーン

公開された研究では、おおむね次の攻撃チェーンが示されています。

1. 攻撃者のページから、細工したユーザー名を wp-login.php へ送信させる
2. サニタイズ処理の解析差により、ログインエラー内に <area> 要素が生成される
3. DOM clobbering：<area id=ajaxurl href=...> により window.ajaxurl を攻撃者の値で上書きする
4. ログイン画面で読み込まれる WordPress 標準の wp-admin/js/user-profile.js の委譲ハンドラが、注入されたDOM要素に対して自動的に発火する
5. jQuery の $.post() が、上書きされた ajaxurl に向けてリクエストを送出する
6. WordPress REST API の JSONP応答（_jsonp パラメータ） をJavaScriptとして評価させる
7. Same Origin Method Execution（SOME） により、window.opener 経由でログイン中の管理者コンテキストの要素（承認ボタン等）を操作する
8. アプリケーションパスワードを作成し、その資格情報を攻撃者側へ渡す
9. 取得したアプリケーションパスワードで認証済みREST APIを操作し、プラグインアップロード機能からPHPファイルを設置してWebサーバーユーザー権限で実行する

XSSの成立自体にWordPressアカウントは不要です。 一方、公開されたRCEチェーンには次の追加条件があります。

• 管理者がWordPressにログイン中であること
• 管理者が攻撃者のページを開くなどの能動的な操作を行うこと
• アプリケーションパスワードが有効であること
• プラグインアップロード（install_plugins / upload_files 相当）が可能であること

したがって、脆弱性の入口は「認証前」ですが、これを単純に「無条件の未認証RCE」「ゼロクリックRCE」と表現するのは適切ではありません。CVSS v4.0 の AC:H / UI:A もこの点を反映しています。

wp2shellとは別の脆弱性です

2026年7月に公表された wp2shell と、今回の XSS2Shell は別の脆弱性です。混同すると対応漏れが起きます。

WordPress 7.0.2 は wp2shell への修正を含みますが、XSS2Shell の修正版は 7.0.3 です。7.0.2 へ更新済みでも、今回の対応は完了していません。

WP-CLIによるバージョン確認と更新

作業前に、データベースとファイルのバックアップを取得してください。その後、設置ディレクトリで次のように確認します。

wp core version                 # 現在のバージョン確認
wp core check-update            # 更新可否の確認
wp core update                  # コア更新
wp core update-db               # DBスキーマ更新
wp core verify-checksums        # コアファイルの整合性確認

複数サイトをまとめて確認する場合の例：

for d in /var/www/*/public_html; do
  printf '%s\t' "$d"
  wp --path="$d" core version --allow-root 2>/dev/null || echo "N/A"
done

wp core verify-checksums はコアファイルの整合性確認に有効ですが、wp-content 内の不正ファイル、データベースの改ざん、追加されたユーザーは検出できません。

自動アップデート設定の確認

wp-config.php の主な設定は次のとおりです。

define( 'WP_AUTO_UPDATE_CORE', true );

true はメジャー・マイナー・開発版を含むコア更新を有効化し、'minor' はマイナー更新のみ、false はコアの自動更新を無効化します。

すべての自動更新を止める次の設定が存在しないかも確認します。

define( 'AUTOMATIC_UPDATER_DISABLED', true );
define( 'DISALLOW_FILE_MODS', true );   // これも自動更新を止めます

また、プラグイン・テーマ・MUプラグイン内で次のようなフィルターが使われていないかを確認してください。

add_filter( 'automatic_updater_disabled', '__return_true' );
add_filter( 'auto_update_core', '__return_false' );

WP-CLIでの一括確認：

wp config get WP_AUTO_UPDATE_CORE
wp config get AUTOMATIC_UPDATER_DISABLED
wp config get DISALLOW_FILE_MODS

WordPress公式によると、WP_AUTO_UPDATE_CORE を定義していない既存サイトでは、通常マイナーコア更新が標準で有効です。一方、WordPress 5.6以降の新規インストールでは、バージョン管理環境などの例外を除き、メジャー更新とマイナー更新の両方が有効になる場合があります。

自動更新が失敗する主な要因

• WordPressファイルの所有者・書き込み権限が不適切
• WordPress.org API への名前解決や外部通信ができない
• PHPのメモリ、実行時間、ストレージ容量が不足
• .git / .svn / .hg などのVCSディレクトリが検出された
• DISALLOW_FILE_MODS / AUTOMATIC_UPDATER_DISABLED が設定されている
• プラグインやMUプラグインが自動更新をフィルターで停止している
• Basic認証、WAF、プロキシが更新処理に干渉している
• サーバー管理パネル側の更新設定とWordPress側の設定が一致していない
• 更新処理中に通信やPHPプロセスが中断した

管理画面に「自動更新ON」と表示されているかだけを見るのではなく、更新通知メール、WordPressのデバッグログ、サーバーログ、監視システムを用いて実際の適用結果を確認してください。

侵害有無の確認

管理者ユーザーとアプリケーションパスワードの確認：

wp user list --role=administrator
wp user application-password list USER_ID

さらに、次の項目を調査します。

• wp-login.php に対する不自然なPOSTリクエスト
• _jsonp / _method / _envelope を伴う不自然なREST APIアクセス
• wp-admin/authorize-application.php への不審なアクセス
• wp-admin/update.php?action=upload-plugin の実行履歴
• 最近作成された固定ページや投稿
• 最近追加・変更された wp-content/plugins 内のPHPファイル
• wp-content/uploads 内のPHPファイル
• wp-content/mu-plugins 内の未知のファイル
• .htaccess、wp-config.php、テーマの functions.php の変更
• WordPress cron、OSのcron、systemd、SSHキーなどへの永続化

# 直近7日以内に変更されたPHPファイルを洗い出す
find wp-content -name '*.php' -mtime -7 -ls
# uploads配下のPHPファイル（通常は存在しないはず）
find wp-content/uploads -name '*.php'

ApacheやNginxの標準アクセスログには通常POST本文が記録されないため、POST /wp-login.php の記録だけでは、送信されたユーザー名が攻撃用だったか判断できません。WAF、ModSecurity、CDN、WordPress監査ログなど、POST本文や遮断理由を保持するログもあわせて確認してください。

侵害が疑われる場合は、更新だけで作業を終了せず、サイトを保全したうえで次を検討します。

1. 不審なアプリケーションパスワードの失効
2. 管理者パスワードの変更
3. WordPress認証用SALTの更新によるセッション無効化（wp config shuffle-salts）
4. 不審な管理者・プラグイン・PHPファイルの調査と除去
5. コア・テーマ・プラグインの正規ファイルからの再展開
6. データベース内の不正な投稿・オプション・cronの確認
7. サーバー、データベース、メールなど関連認証情報の変更
8. 信頼できる侵害前バックアップからの復元

通常の管理者パスワードを変更しても、アプリケーションパスワードが自動的にすべて無効になるとは限りません。両方を個別に確認してください。

更新までの暫定的な防御策

根本対策はWordPressコアの更新です。 更新までの短時間の暫定策としては、次が考えられます。

• 管理画面へのアクセスをVPNまたは許可IPに制限する
• WAFで既知の攻撃パターンや不審なJSONPリクエストを遮断する
• REST APIのJSONP応答を無効化する

add_filter( 'rest_jsonp_enabled', '__return_false' );

公開されたチェーンでは、REST APIのJSONP応答（_jsonp パラメータ）をJavaScriptとして評価させる工程が含まれます。これを無効化すれば当該工程は成立しなくなると考えられますが、これはWordPress公式やベンダーが公式な回避策として案内しているものではなく、公開された攻撃チェーンの構成からの判断です。 他の経路が存在する可能性は否定できません。また、JSONPを利用している外部連携がある場合は動作に影響します。あくまで更新までのつなぎとしてご検討ください。

• 不要な場合はアプリケーションパスワードを無効化する

add_filter( 'wp_is_application_passwords_available', '__return_false' );

• DISALLOW_FILE_MODS により本番管理画面からのプラグイン・テーマの編集や追加を制限する
• wp-content/uploads でPHPを実行できないようWebサーバーを設定する
• 管理者権限を日常の投稿作業に使用しない
• 管理者がログイン中に、メールやSNSの不審なリンクを開かない

ただし、ログインURLの変更、REST APIの一律制限、WAFだけに依存する対策は、環境差や回避手法の存在を考えると恒久対策になりません。必ず修正版を適用してください。

2026年8月10日時点の悪用状況

• 発見者による技術解説と実証内容が公開されており、公表の翌日にはPythonベースのエクスプロイトツールがGitHubで公開されています。
• 2026年8月10日時点で確認した範囲では、XSS2Shellについて大規模な実悪用が公的に確定したという情報は確認できませんでした。CISAのKEV（Known Exploited Vulnerabilities）カタログにも、同日時点では登録されていません。
• 英国NHS EnglandのCSOCは、この脆弱性について「悪用される可能性が高い（exploitation as likely）」と評価し、早急な更新を推奨しています。

参考として、先行するwp2shell（CVE-2026-63030）では、株式会社サイバーセキュリティクラウドの観測により、公表当日に攻撃検知が前日比277倍へ急増し、観測期間中の全世界の累計は約195万件に達したと報告されています。「悪用報告が出てから対応する」では間に合わないことを示す実例です。

同レポートでは、攻撃の送信元を国別に集計した結果、日本国内の984個のIPアドレスから68,771件の攻撃通信が観測されたことも報告されています（1IPあたり平均69.9件と、少量ずつ多数のIPから発信される分布）。これは日本のサイトが狙われた件数ではなく、日本国内に設置されたサーバーが攻撃の送信元になっていたという数字です。更新されないまま放置されたサイトは、被害者になるだけでなく、他者を攻撃する踏み台として利用される可能性がある点も意識しておく必要があります。

XSS2Shellについても、技術情報とPoCが公開されている現段階で対応を完了させてください。

まとめ

XSS2Shell（CVE-2026-64638）は、WordPressのログイン画面に存在する認証前の反射型XSSで、条件がそろうと管理者権限の悪用やPHPコード実行につながる可能性があります。

重要な点は次のとおりです。

• 特定のプラグインではなくWordPress本体の問題（4.7.0〜7.0.2が対象）
• プラグインが少ないサイトも確認が必要
• XSSの入口には攻撃者のWordPressアカウントが不要
• RCEまでにはログイン中の管理者による操作などの追加条件がある（ゼロクリックではない）
• WordPress 7.0.2 では不十分。7.0.3、または各系列の修正版が必要
• 自動更新をONにしていても、実際に適用されたかの確認が必要
• PoCがすでに公開されており、悪用報告を待つ理由はない
• 更新・バックアップ・監視・更新後確認を組み合わせることが重要

株式会社オレンジソフトウェアでは、WordPressサイトの制作だけでなく、サーバー構築、WordPress本体・プラグインの更新管理、バックアップ、SSL、障害対応、セキュリティ確認など、公開後の運用も含めて対応しています。

WordPressのバージョンが分からない、自動更新が正常に動いているか不安、長期間更新していないサイトがある、不審な管理者やファイルが見つかった。こうした場合は、早めに専門家へご相談ください。

WordPressの脆弱性対応・保守のご相談 現状のバージョン確認から、更新作業、侵害有無の確認、復旧対応まで承ります。 ▶ お問い合わせはこちら

よくある質問（FAQ）

Q. 7.0.2 に更新済みですが、対応は完了していますか？ A. 完了していません。7.0.2 は7月公表の wp2shell への修正を含むリリースで、XSS2Shell（CVE-2026-64638）の修正版は 7.0.3 です。

Q. 管理画面にログインしなければ安全ですか？ A. 攻撃チェーンがPHPコード実行まで進むにはログイン中の管理者の操作が必要なため、リスクは下がります。ただしXSS自体は認証なしで成立するため、根本対策は更新です。

Q. ログインURLを変更していれば大丈夫ですか？ A. 恒久的な対策にはなりません。ログインURLの変更は発見を遅らせる効果しかなく、修正版の適用が必要です。

Q. WordPress 6.8系を使い続けたいのですが？ A. 6.8.7 に更新すればXSS2Shellの修正は適用されます。ただし公式が積極的にサポートしているのは最新系列のため、互換性を確認のうえ最新系列への移行を検討してください。

Q. 更新したら、もう何もしなくていいですか？ A. 更新前にすでに侵入されていた場合、更新だけでは不正な管理者・アプリケーションパスワード・不正ファイルは消えません。本記事の「侵害有無の確認」もあわせて実施してください。

主な参考情報

• WordPress 7.0.3 公式リリース
• WordPress GitHub Security Advisory：GHSA-52p2-r8wf-jcrf
• NVD：CVE-2026-64638
• pwn.ai：XSS2Shell 技術解説
• Patchstack：WordPress 7.0.3 Released – 12 Vulnerabilities Found and Fixed
• NHS England Digital：XSS2Shell 注意喚起（CC-4827）
• 株式会社サイバーセキュリティクラウド：wp2shell 攻撃検知レポート
• Uptime Kuma（オープンソース監視ツール）
• The Hacker News：New WordPress Pre-Auth XSS Could Lead to PHP Code Execution

免責事項 本記事は2026年8月10日時点でインターネット上に公開されている情報を、株式会社オレンジソフトウェアが調査・整理したものです。内容の正確性・完全性を保証するものではなく、公開後に脆弱性の評価、対象バージョン、攻撃状況、対策方法などが変更される可能性があります。本記事のみを根拠として操作や判断を行わず、WordPress公式および関係機関の最新情報をご確認ください。また、サーバーやWordPressへの操作は、事前にバックアップを取得し、環境に詳しい管理者または専門家の責任のもとで実施してください。