WordPressのwp-includes/Requestsに不審なPHPがある時の確認｜正規コアとバックドアを見分ける

WordPressのwp-includes/Requestsを確認していて、見覚えのないPHPファイルや、
セキュリティスキャンの警告を見つけて困っていませんか？

この場所には、WordPressが外部サイトやAPIと通信するための正規ライブラリが含まれます。
PHPファイルが複数あること自体は正常ですが、攻撃者が正規名に似たファイルを追加したり、既存ファイルへ短いコードを追記したりする場合もあります。

慌ててフォルダごと削除すると、更新確認、外部API、プラグイン連携、メール配信などが壊れるおそれがあります。
反対に「コアだから安全」と決めつけると、WordPressの早い段階で動くバックドアを残しかねません。

よこやま良平

WordPressの復旧を多数手がけてきたよこやま良平です。わたしの現場経験をもとに、Requestsライブラリの正規構成を確認し、不審なPHPを実行せずに判定・復元する順番を解説します。

結論から言うと、wp-includes/Requestsの判定は、ファイル名の印象ではなく、
WordPressの版、公式配布物との差分、コードの位置、ログ、周辺の変更を組み合わせて行います。

まず現状を保全し、同じ版の公式パッケージでフォルダ全体を比較してください。
悪意を示す差分があれば侵入経路を止めた後、コア領域を部分編集せず、検証済みの正規一式へ安全に戻します。

【無料プレゼント】
WordPress緊急チェック50

「自分のサイトは今、安全なのか？」
自信を持って答えられますか？

こんなお悩みはありませんか？

• ある朝、サイトを開いたら真っ白画面になっていた
• 管理画面にログインできなくなって手が止まった
• 身に覚えのない記事やページが勝手に増えていた
• プラグインを更新したらサイト全体が崩れてしまった
• 以前バックアップを取ったか自分でも覚えていない

累計1,000件以上のWordPressトラブル対応の経験から、「壊れる前に備える」ためのチェックリストを1冊にまとめました。
ログイン・本体・バックアップ・サーバー・運用の5分野を、50項目で「危険度・確認方法・対処法」まで解説しています。

セキュリティプラグイン・WordPressの教科書も含めた3大特典を、
今なら無料で受け取れます。

今すぐ無料ダウンロードする →

※登録後すぐにメールで特典をお届けします

WordPressのwp-includes/Requestsは削除前に証拠を保存する

WordPressのwp-includes/Requestsに不審なPHPを見つけた時は、
ブラウザーで開いたり、ファイルを消したりする前に、現状を複製して記録するのが最初の結論です。

不審ファイルが実行された時刻や作成元を調べるには、内容だけでなく、パス、所有者、権限、更新日時、
ハッシュ、周辺ファイル、アクセスログが必要です。先に上書きすると、復旧できても侵入口を追えなくなります。

不審なPHPをブラウザーやコマンドで実行しない

ファイルの動きを確認するために公開URLへアクセスしたり、php suspicious.phpのように直接実行したりしてはいけません。
外部から追加コードを取得する、別ファイルを書き換える、認証情報を送る処理が動く可能性があるためです。

確認は隔離コピーをテキストとして開く静的解析から始めます。
難読化を解く場合も、本番サーバーや管理端末でコードを実行せず、必要ならネットワークを切った専用環境へ切り替えます。

絶対パス・属性・ハッシュ・周辺一覧を一組で残す

対象ファイルだけをダウンロードするのではなく、wp-includes/Requests全体の一覧を取得します。
同じ時刻に増えたファイル、正規ファイルに似せた名前、別所有者のファイルが見つかることがあります。

date -u
pwd
find wp-includes/Requests -type f -maxdepth 5 -print0 | sort -z | xargs -0 shasum -a 256 > requests-sha256.txt
find wp-includes/Requests -type f -maxdepth 5 -exec stat -f '%N %z %Sm %Su %Sg %Sp' {} \; > requests-stat.txt

ファイル一式・DB・ログを調査用として分けて保存する

WordPress一式とデータベースを作業前の状態で保存し、アクセスログ、WAF、FTP・SFTP、SSH、
管理画面ログイン、Cronの記録も同じ期間で確保します。ログは保存期間が短いことがあるため、ファイル修正より先に退避してください。

サイト全体に転送、未知の管理者、スパムページなども出ている場合は、
Requestsだけのファイル問題として扱わず、公開範囲を制限して被害拡大を止めてください。

クイックレスキュー

Webサイト改ざんされたら最初にやること【WordPress被害確認から復旧・再発防止まで】 Webサイトが改ざんされて困っていませんか？突然サイトの内容が書き換えられた・スパムページが増えている・Googleに危険と表示されている——そんな緊急事態への対処法を、…

WordPressのwp-includes/Requestsが正規コアである理由を理解する

wp-includes/Requestsは、WordPressのHTTP通信を支える正規コア領域です。
更新確認、外部API、フィード、ループバック、プラグインやテーマの通信が間接的に利用するため、フォルダごとの削除は正しい対処ではありません。

Requestsは外部HTTP通信を安全に扱うライブラリ

WordPressはURLへ接続する時、環境に応じてcURLやPHPのストリームなどを使い分けます。
Requestsライブラリは、リクエスト、レスポンス、ヘッダー、Cookie、認証、プロキシ、証明書などの処理を共通化します。

つまり、Requests.php、Response、Transport、Cookieに関係するPHPが存在しても、
その名前だけでは異常と言えません。正規版に存在するか、同じ相対パスと内容かを確認する必要があります。

WordPressの版によってディレクトリ構成や名前空間が異なる

RequestsライブラリはWordPress本体の更新に合わせて構成が変わってきました。
古い版と新しい版では、ファイル数、サブディレクトリ、クラス名、名前空間、互換用ファイルが一致しない場合があります。

最新版のWordPressを比較対象にすると、稼働中の旧版にないファイルを「欠損」、
旧版だけにある互換ファイルを「マルウェア」と誤判定しかねません。必ず稼働版と同じリリースを基準にします。

PHPがあるだけでバックドアと断定しない

WordPressのwp-includes/Requestsを同じ版の公式配布物と比較する

正規コアとバックドアを分ける最も確実な入口は、稼働中と同じWordPress版の公式配布物を、
安全な別ディレクトリへ取得し、Requestsフォルダを相対パスと内容で比較することです。

WordPressの版・ロケール・設置先を先に確定する

管理画面の表示だけに頼らず、wp-includes/version.php、WP-CLI、更新履歴で版を確認します。
更新途中で新旧ファイルが混在している場合は、改ざんと更新失敗の両方を候補に残してください。

サブディレクトリ設置や複数WordPressでは、公開ルートと本体のパスが異なることがあります。
別サイトのwp-includesと比較しないよう、URL、DB接頭辞、絶対パスの対応を先に記録します。

WP-CLIチェックサムは入口として使い差分を個別確認する

公式WordPress.org版であれば、WP-CLIのコアチェックサムで改変候補を確認できます。
成功はコア一致の強い材料になりますが、失敗行を自動削除する命令としては使いません。

wp core version --path=/path/to/wordpress
wp core verify-checksums --include-root --path=/path/to/wordpress
wp core download --version=対象版 --locale=対象ロケール --skip-content --path=/safe/clean-wordpress

フォルダ単位とファイル単位の二段階で差分を見る

最初に相対パス一覧で「追加・欠損」を確認し、その後に同名ファイルのハッシュと行差分を見ます。
追加ファイルだけでなく、正規ファイルの冒頭や末尾へ数行だけ追記する改ざんもあるためです。

find /safe/clean-wordpress/wp-includes/Requests -type f | sed 's#^.*/Requests/#Requests/#' | sort > clean-list.txt
find /path/to/wordpress/wp-includes/Requests -type f | sed 's#^.*/Requests/#Requests/#' | sort > live-list.txt
diff -u clean-list.txt live-list.txt
diff -ruN /safe/clean-wordpress/wp-includes/Requests /path/to/wordpress/wp-includes/Requests

コア全体のチェックサムと安全な復元の考え方は、Requests以外のwp-admin・wp-includesを含めて判断します。
単一フォルダだけ正常でも、別のコアファイルから再生成される可能性があるためです。

クイックレスキュー

WordPressの不審なPHPファイルは放置していい？危険度と削除判断の考え方 WordPressのサーバーで見覚えのないPHPファイルを見つけて困っていませんか？放置・即削除を避け、場所、正規版との差分、コード、ログから危険度を判断する手順を解説。証…

WordPressのwp-includes/Requestsにある不審なPHPを静的に判定する

公式版との差分が見つかったら、ファイル名や一つの関数だけで断定せず、
配置、由来、入力、処理、通信、書き込み、ログ、サイト症状が同じ方向を示すかを確認します。

正規版にない追加ファイルと似た名前を確認する

攻撃者はRequest.phpとRequests.php、大文字と小文字、ハイフンとアンダースコアなど、
一覧で見落としやすい名前を使うことがあります。ファイル名だけでなく、正規版の相対パス一覧と機械的に比較してください。

画像やテキストに見える拡張子でも、Webサーバー設定によりPHPとして実行される場合があります。
反対に、PHP拡張子でも正規ライブラリの構成要素があります。拡張子と実際の内容、ハンドラー設定を分けて確認します。

既存ファイルの冒頭・末尾・条件分岐への追記を探す

追加ファイルが0件でも安心できません。正規ファイルの開始タグ直後、クラス定義前、ファイル末尾、
例外処理やオートロード周辺へ短いコードを差し込み、通常通信の一部に見せかける改ざんがあります。

eval、base64_decode、gzinflate、可変関数、長い難読化文字列は調査の手掛かりですが、
単独では悪意の証明になりません。外部入力がコード実行・ファイル作成・通信へつながるかをデータの流れで確認します。

HTTPライブラリの役割から外れる処理を確認する

Requestsの正規目的はHTTP通信の抽象化です。WordPressユーザーの追加、投稿生成、任意PHPの保存、
テーマ書き換え、管理者認証回避、外部から受け取った命令の実行は、この場所の通常役割から外れます。

ただし外部通信、Cookie、証明書、ファイルストリームという語があるだけで危険とは言えません。
送信先、入力元、保存先、実行条件、呼び出し元を追い、正規HTTP処理か不正な命令経路かを分けます。

クイックレスキュー

バックドアは動作してなくても消すべき？放置リスクを解説 バックドアや不審なPHPファイルは、動作していないように見えても放置は危険です。再感染・検索汚染・サーバー停止を防ぐため、消すべき理由と安全な調査方法を初心者向け…

WordPressのwp-includes/Requestsを安全な正規コアへ復元する

悪意ある差分を確認したら、侵入口と再生成元を止めた後に、
Requestsの怪しい数行だけを手編集せず、同じ版の検証済み公式コアへ戻すのが基本です。

復元前に停止範囲と戻す手段を決める

EC、予約、会員、フォーム、外部APIなど、HTTP通信へ依存する機能を洗い出します。
短時間のメンテナンス、担当者、開始時刻、確認項目、ロールバック条件を決めてから変更してください。

感染中のファイルを「安全なバックアップ」として上書き復元に使ってはいけません。
調査用証拠と、復旧に使う検証済みファイルを物理的に分け、担当者が取り違えない名前を付けます。

wp-admin・wp-includesを同じ版の一式で置き換える

Requestsに不正差分がある場合、同じ権限で書き換えられる他のコアも確認します。
安全性を確定できない時は、wp-adminとwp-includesを同じ版の公式一式へ置き換える方が、取り残しを減らせます。

wp-content、wp-config.php、独自アップロード、サーバー固有設定を無差別に消してはいけません。
コア置換とサイト固有領域の調査を分け、必要な設定とコンテンツを保護します。

キャッシュとOPcacheを更新して基本機能を確認する

ファイル置換後は、PHP OPcache、ページキャッシュ、CDNを環境に合う方法で更新します。
古いコードがメモリやキャッシュに残ると、ディスク上は正常でも症状が続き、復元失敗と誤認するためです。

トップページだけでなく、管理画面ログイン、更新確認、プラグインAPI、外部HTTP通信、Cron、フォーム、
決済や会員処理を確認します。PHPエラー、タイムアウト、証明書エラーも同時に監視してください。

キャッシュ用ドロップインなど、コア外から早い段階で読み込まれるPHPも再生成元になり得ます。
Requestsを戻しても差分が再発する場合は、読み込み経路を広げて確認してください。

クイックレスキュー

WordPressのadvanced-cache.php・object-cache.phpが不審な時の確認手順 WordPressのadvanced-cache.phpやobject-cache.phpを見つけ、削除してよいか迷っていませんか？正規キャッシュとの見分け方、証拠保全、ファイル別の安全な停止・隔離、変…

WordPressのwp-includes/Requests改ざんの侵入経路を止めて監視する

正規コアへ戻して表示が直っても、侵入経路が残っていれば復旧完了ではありません。
Requestsが変更された時刻を軸に、WordPress内外の認証・脆弱性・自動処理を時系列で追います。

変更時刻とアクセス・認証・更新ログを照合する

ファイル時刻は偽装や展開で変わるため単独では断定に使えませんが、調査の基準時刻にはなります。
直前のPOST、未知の管理者ログイン、FTP接続、プラグイン更新、WAF検知、Cronを同じ時系列へ並べます。

同じ時刻にwp-config.php、wp-settings.php、mu-plugins、uploads、cacheが変わっていれば、
一つのファイルを単独事故として扱わず、共通の書き換え元を探してください。

WordPress内外の永続化経路を調べる

通常プラグイン、テーマ、mu-plugins、ドロップイン、WP-Cron、データベースのoptions、
Application Passwords、不審管理者、サーバーCron、デプロイ、自動復元を確認します。

同一ホスティングアカウントの別WordPressや古いCMSから書き戻されるケースもあります。
対象サイトだけ認証情報を変更して終えず、同じユーザー権限で書き込める領域を棚卸ししてください。

クイックレスキュー

WordPressのmu-pluginsに不審なファイルがある時の確認と安全な削除手順 WordPressのmu-pluginsに見覚えのないPHPファイルがあり不安な方へ。正規機能と不正コードを見分ける確認軸、証拠を残す隔離・削除手順、削除後に戻る場合の調査範囲を解説…

直後・24時間後・72時間後・一週間後に再比較する

復元直後、24時間後、72時間後、一週間後に、同じコマンドでファイル一覧とSHA-256を取得します。
再発時刻が一定ならCronや自動復元、特定アクセスの直後ならWeb経由の入口を優先して調べます。

ファイルだけでなく、管理者、投稿、options、Cron、外部通信、404、転送、CPU負荷も監視します。
攻撃者がRequestsへの再投入を諦め、別の永続化場所へ移る可能性があるためです。

設定ファイルにも不審な追記がある場合は、DB情報や認証キーを含むため、
安全な端末から失効・変更する順番を決め、画面共有やログへ秘密情報を残さないでください。

クイックレスキュー

WordPressのwp-config.phpが改ざんされた時の確認点｜認証キーとDB情報を守る復旧手順 WordPressのwp-config.phpに不審な変更を見つけ、認証キーやDB情報の漏えいが心配ではありませんか？証拠保全、差分確認、資格情報の交換、周辺侵害の調査、再発防止まで安…

WordPressのwp-includes/Requestsでよくある質問

wp-includes/RequestsにPHPファイルが多いのは感染ですか？

いいえ。RequestsはWordPressのHTTP通信を支える正規PHPライブラリです。PHPが多いこと自体ではなく、同じWordPress版の公式配布物にない相対パス、ハッシュ不一致、役割外の処理、ログとの一致で判断します。

セキュリティプラグインが警告したファイルはすぐ削除してよいですか？

すぐ削除しないでください。誤検知、更新途中、管理された独自変更の可能性もあります。絶対パス、属性、ハッシュ、ログを保存し、同じ版の正規ファイルと比較してから隔離・復元を判断します。

Requestsフォルダだけ公式版へ上書きすれば直りますか？

一時的に直ることはありますが、侵入経路や別の改ざんが残ると再発します。wp-admin・wp-includes全体の整合性、mu-plugins、drop-ins、Cron、管理者、同居サイトまで確認し、再生成元を止めてから復元してください。

最新版のRequestsフォルダを古いWordPressへコピーしてよいですか？

避けてください。WordPress版によりライブラリ構成や互換性が異なります。稼働版と同じ公式パッケージを基準にし、更新する場合はWordPress本体の正式な更新手順とバックアップ、互換性確認を行います。

WordPressのwp-includes/Requestsは正規版との差分で判断する

wp-includes/Requestsに不審なPHPを見つけたら、実行・削除・上書きの前に、
絶対パス、属性、ハッシュ、周辺一覧、WordPress一式、DB、ログを保存します。

次に稼働中と同じWordPress版の公式配布物を安全な場所へ取得し、相対パス、ハッシュ、行差分を比較してください。
ファイル名や難読化関数だけで決めず、HTTPライブラリの役割から外れる処理とログの一致を確認します。

悪意ある差分を確認したら侵入口と再生成元を止め、同じ版の正規コア一式へ戻します。
復元後はチェックサム、業務機能、キャッシュ、外部通信を確認し、時間を分けて再発監視を続けることが重要です。

WordPressのRequests改ざんを自分で判断できない時は

Requestsフォルダの正規構成、改ざん範囲、侵入経路、再生成元を判断できない場合は、
クイックレスキューが証拠保全、感染調査、正規コア復元、再発防止まで対応します。

初期費用・調査費用0円。復旧できない場合やマルウェアを駆除できない場合は全額返金保証、
作業後90日間の再感染・動作保証があります。