[1] 読み取りチャネルとしてはタイミング/ブラインドのみ。ブリッジ内にUNION偽造投稿プリミティブは存在するが、抽出オラクルとして公開されていない。 [2] 単純な可用性プローブ（0) UNION SELECT ...）はオブジェクトキャッシュのハイドレーション中に黙ってドロップされ、available()はfalseを返し、事前認証ブリッジ全体が中断される。§1参照。 [3] プロジェクト自身のREADMEが「永続オブジェクトキャッシュなし（Redis/Memcached）」を前提条件として挙げている。 [4] Sploitusでミラーリングされている公開バリアント（下記リンク）：ブラインド読み取り + INTO OUTFILEドロッパーをRCEステップとして使用し、per_page=-1カテゴリキャリアを使用。 [5] OUTFILE RCEパスは偽造投稿レンダリングに依存しないため、オブジェクトキャッシュはそれをブロックしない。代わりにMySQL FILE権限と共有書き込み可能ディレクトリがブロックする。マネージドホスティングでは、WordPress DBユーザーにFILEが許可されることはほとんどなく、secure_file_privが一般的に設定されている。

1. オブジェクトキャッシュ問題（真の差別化要因）

UNION偽造投稿プリミティブは、WP_Queryが行を返す方法に依存します。

• 全行モード - SQLはwp_postsの行全体を返します。UNIONで注入された行は直接WP_Postになります。偽造がレンダリングされます。
• 分割（IDのみ）モード - SQLはIDのみを返し、各IDはその後（永続）オブジェクトキャッシュ/データベースを通じてハイドレーションされます。偽造行のIDは存在しないため、ハイドレーションは黙ってそれをドロップします。エラーも偽造投稿もなし。

永続オブジェクトキャッシュがあるホストでは、ベースセットが入力された結果セットがWP_Queryを分割モードに押し込みます。公開PoCで使用される標準プローブ -

• はベースセットを入力状態のままにします（post_author NOT IN (0)はすべての行に一致）。そのため、オブジェクトキャッシュの背後では偽造行が消失します。可用性プローブが偽陰性を示し、available()がfalseを返し、事前認証ブリッジ全体が実際には完全に悪用可能なホストに対して「死んでいる」と報告されます。公開統合ツールは、*「永続オブジェクトキャッシュなし」*をハードな前提条件として挙げることで、同じ境界を文書化しています。

このリポジトリは代わりにベースセットを空にします：

ベース行がゼロの場合、偽造行は唯一の行です。クエリは全行モードのままです。ハイドレーションルックアップは決して実行されません。注入された1つのキーワード（AND 1=0）が、オブジェクトキャッシュホストでの「UNIONチャネルが死んでいる」と「完全な事前認証RCE」の間のすべての違いです。そしてオブジェクトキャッシュホストは、マネージドWordPress本番環境の大多数を占めています。診断、プローブマトリックス（per_page × 注入形式）。

範囲に関する注：ブラインド/タイミング読み取りチャネルはオブジェクトキャッシュに影響を受けません（SQL内の行を数えることは偽造投稿のハイドレーションを伴わない）。したがって、すべてのPoCのブラインド読み取りはどこでも機能します。他のPoCでオブジェクトキャッシュが殺すのは、具体的にはUNION依存部分です：インバンド抽出とSQLiから管理者へのブリッジ。

ケーススタディで文書化された2つ目の関連教訓：両方のチャネルが機能する場合、インバンドUNION読み取りを信頼できるものとして扱うこと。本番タイミングオラクルは、インバンド読み取りが明確に確定した値に対して、ジッタの下でビット反転を生成しました。

2. RCEパスの選択

公開PoC全体で3つの事前認証RCEパスが存在します：

このリポジトリはブリッジを実装しています。WordPressがすでに持っている以上のデータベース権限を必要とせず、DBとWeb層が何も共有しない場合でも機能し、FILE権限パスに依存するファイルを残しません。トレードオフは複雑さです。ブリッジは7行の毒された投稿グラフです。これはまさに、§1のオブジェクトキャッシュ偽陰性がかつてこのパスを隠していた場所です。

3. 承認された使用のための安全デフォルト

ラボだけでなく、承認された状態で本番システムに対して実行するために構築されています：

• checkはデフォルトで非破壊的 - 受動的フィンガープリントと良性のマーカーバッチ。--confirm-sqliが指定されない限り、SQLペイロードは送信されません。パッチ適用後、消えるマーカートリプレットは修正検証としても機能します。
• 属性タグ付け - --user-agentがすべてのコマンドにあり、すべてのエクスプロイトトラフィックがログで識別可能になります（公開ツールがデフォルトにしないエンゲージメントの経験則）。
• 自動クリーンアップ - ウェブシェルはランダム化されたパスの下でトークンロックされ、自身を削除します。ブリッジで作成された管理者は、そのコンテンツが借用した管理者アカウントに再割り当てされた後に削除されます。クリーンアップの失敗は、黙殺されずに大きな音で報告されます。
• リクエストアカウンティング - すべてのコマンドが送信したリクエスト数を表示します。

4. このリポジトリが主張しないこと

• 新しい脆弱性ではない。両方のバグは公開されたCVEであり、二重入れ子バッチ形状、author_exclude → author__not_inシンク、偽造WP_Post UNIONプリミティブ、カスタマイザーブリッジの概念はすべて公開技術です（系統は以下で認められています）。
• 新しい悪用プリミティブではない。公開された状況に対する差分は以下の通りです：本番エビデンスを伴うベースセットを空にするオブジェクトキャッシュ修正、本番安全デフォルト、および検出ドキュメント - 技術の新規性ではなく、堅牢性と運用安全性。
• IoC文字列は任意です。ログインプレフィックス、プラグインスラッグ、シェルマーカー、およびUser-Agent値は、すべてのバリアント間および実行ごとに異なります。

参考文献

• Icex0/wp2shell-poc - このリポジトリの系統が共有する完全チェーン実装 - https://github.com/Icex0/wp2shell-poc
• sergiointel/wp2shell-poc - 最初の公開PoC、クラック不要の管理者作成技術の起源 - https://github.com/sergiointel/wp2shell-poc
• 0xsha/wp2shell - 6つの公開PoCの単一ファイル統合ツール、Dockerラボとバージョン×DBマトリックス付き（オブジェクトキャッシュ前提条件を文書化） - https://github.com/0xsha/wp2shell
• OUTFILE variant（ブラインド読み取り + INTO OUTFILEドロッパー）、Sploitusでミラーリング - https://sploitus.com/exploit?id=7CD079AD-E27B-5C54-A696-60635BFDB241
• 公開PoCとチェッカーの厳選リスト（防御者向け） - https://www.cyberkendra.com/2026/07/wp2shell-guide.html
• GHSA-ff9f-jf42-662q / GHSA-fpp7-x2x2-2mjf; WordPress 7.0.2 リリースアナウンス - README.mdの参考文献を参照。