uploadsフォルダにPHPファイルがあるのは危険?正常・不正を見分ける手順

uploadsフォルダのPHPファイルを実行せず安全に確認するイメージ

WordPressのuploadsフォルダでPHPファイルを見つけたら、まず危険を疑うのが正解です。
ただし、見つけた瞬間に削除すると、侵入経路の証拠や正常な処理まで失うおそれがあります。

結論は、ファイルの拡張子だけで白黒を決めず、置かれた場所、作成・更新時刻、内容、アクセス履歴、設置元を順番に確認することです。
標準のWordPressは、画像保存先でPHPを実行する必要がありません。

よこやま良平
よこやま良平

20年以上ITエンジニアとして、WordPressの制作・PHP調査・不正アクセス復旧に携わっている、よこやま良平です。現場では、削除を急いだために原因を追えなくなる例を何度も見てきました。

この記事で解決できること
  • uploads内のPHPが危険といわれる理由
  • 正常な可能性と不正ファイルの違いを調べる順番
  • ファイルを実行せず、安全に内容と履歴を確認する方法
  • 削除・隔離・復旧を判断する基準と再発防止策

この記事では、サーバーのファイルマネージャーやSFTPでPHPファイルを見つけた場面を想定し、初心者でも事故を増やさない確認手順を説明します。
ブラウザから不審なURLを開いたり、コードをサーバー上で実行したりする必要はありません。

すでに管理者が増えた、勝手に転送される、検索結果が汚染されたなどの症状がある場合は、1ファイルだけの問題ではない可能性があります。
その場合も、まず現状を保存してから調査を進めてください。

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

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

WordPress緊急チェック50

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

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

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

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

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

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

uploadsフォルダのPHPファイルは原則として危険を疑う

uploadsフォルダにPHPファイルがあれば、原則として警戒対象にしてください。
画像やPDFを保存する場所に、サーバー側で動くプログラムがあること自体が通常の用途から外れているためです。

WordPress標準はuploads内のPHP実行を必要としない

WordPressのメディア機能は、アップロードした画像、動画、PDFなどを年月別フォルダへ保存します。
通常は、wp-content/uploads/2026/10/のような場所に画像ファイルと派生サイズが並びます。

WordPress本体の動作に必要なPHPは、ルート直下、wp-admin、wp-includesなどにあります。
テーマやプラグインのPHPも、それぞれthemes、plugins配下に置かれるのが基本です。

そのため、uploadsの年月フォルダにあるPHP、とくに画像と同じ階層へ突然現れたものは、外部から配置されたバックドアを疑います。
不正ファイルは、後から再侵入する入口や迷惑メール送信、別サイトへの転送に使われます。

PHPが1つあるだけで感染確定とは限らない

一方で、PHPという拡張子だけを根拠に感染確定とは言えません。
古いプラグインが空のindex.phpを置き、ディレクトリ一覧を見せない目的で使っている例があります。

バックアップ、キャッシュ、フォーム添付、画像処理系のプラグインが、独自フォルダをuploads配下へ作ることもあります。
ただし「プラグインが置いたかもしれない」という推測だけで安全扱いするのも危険です。

見つけた直後にやってはいけないこと
  • 不審なPHPのURLをブラウザで開く
  • サーバー上でPHPコマンドとして実行する
  • 記録せずに削除・上書き・名前変更する
  • 同じフォルダだけを見て「駆除完了」と判断する

uploadsフォルダを調べる前に証拠と復旧手段を確保する

PHPファイルを調べる前に、現状をそのまま残すことが重要です。
調査対象を保全し、失敗時に戻せる状態を作ってから、複製したファイルで確認してください。

ファイル名・パス・時刻・権限を記録する

最初に、完全なパス、ファイル名、サイズ、所有者、パーミッション、作成または更新時刻を記録します。
サーバー管理画面なら画面を保存し、SFTPなら一覧情報をメモしてください。

更新時刻は重要な手掛かりですが、それだけで不正とは断定できません。
サーバー移転、バックアップ復元、展開処理によって、正常なファイルの時刻が一括で変わる場合があるためです。

同時刻に管理者追加、プラグイン更新、投稿改ざん、海外IPからのログインがあれば、危険度は上がります。
単独の属性ではなく、サイト側の出来事と組み合わせて見ます。

原本を変更せず複製とハッシュを作る

調査用の複製を作り、原本には触れないようにします。
可能なら、サイト本体とは別の安全な保存先へファイルと関連ログを退避してください。

SHA-256ハッシュを記録すると、後で同じファイルか、調査中に内容が変わっていないかを確認できます。
ハッシュは危険性を判定するものではなく、同一性を確かめる指紋です。

shasum -a 256 suspicious-file.php
# Linux環境では次でも確認できます
sha256sum suspicious-file.php
バックアップの扱い

感染疑いの時点で取るバックアップは、復元用の安全なバックアップとは限りません。
「調査用の現状保存」と明記し、正常確認済みバックアップへ混ぜないでください。

uploads内PHPを正常・不正に分ける5つの確認手順

正常・不正を見分けるには、場所、名前、時刻、内容、外部からのアクセスという5段階で確認します。
1項目に違和感があっても即断せず、複数の手掛かりが一致するかを見てください。

手順1:uploads全体から実行可能な拡張子を探す

まず、見つけた1個だけでなくuploads全体を対象にします。
攻撃者は、年月フォルダの深い場所や、キャッシュ・一時フォルダに複数の入口を残すことがあるためです。

find wp-content/uploads -type f \( \
  -iname "*.php" -o -iname "*.phtml" -o \
  -iname "*.phar" -o -iname "*.php5" \
\) -print

コマンドを使えない場合は、サーバーのファイルマネージャーで拡張子検索を行います。
検索結果は、パスが分かる形で保存し、件数も記録してください。

手順2:ファイル名と配置場所の不自然さを見る

index.phpだから安全、ランダム名だから不正、とは限りません。
攻撃者がindex.phpへ偽装する一方、正常なシステムが一時ファイルへランダム名を使う場合もあります。

危険度が高いのは、画像名に見せた二重拡張子、年月フォルダ直下のPHP、同じ内容の大量複製、見覚えのない隠しフォルダ内のファイルです。
たとえばphoto.jpg.phpは、末尾がPHPであれば画像として扱えません。

手順3:更新時刻をサイトの変更履歴と照合する

ファイルの更新時刻を、プラグイン導入、テーマ更新、メディア投稿、サーバー移転の時刻と照合します。
正規作業と一致するなら、その作業を行った担当者と配布元まで確認します。

誰も作業していない深夜に作成され、その直前にwp-login.phpへの成功応答や脆弱なプラグインへのPOSTがあれば、不正の可能性が高まります。
時刻はサーバー、WordPress、WAFでタイムゾーンが違うことがあるため、JSTかUTCかもそろえてください。

uploads内のPHPを発見・内容確認・隔離の順で安全に調べるイメージ

手順4:複製したファイルをテキストとして読む

内容確認は、サーバーから安全な端末へ複製し、実行機能のないテキストエディターで行います。
ダブルクリックやブラウザ表示ではなく、文字列として開くことが重要です。

空のindex.phpで、コメントと終了だけなら、ディレクトリ一覧防止用の可能性があります。
それでも、利用中プラグインの公式配布ファイルや説明書と一致するかを確認してから判断します。

外部入力を受け取って任意コードを実行する処理、長い難読化文字列、外部URLからコードを取得する処理、認証なしのファイル操作があれば危険です。
evalやbase64_decodeなどの関数は正常コードにも使われるため、関数名だけでなく入力元と処理結果を追います。

手順5:アクセスログで実行された形跡を調べる

ファイルが置かれていても、外部から実行されたかどうかで緊急度は変わります。
アクセスログから完全パスに対応するURLを検索し、GET・POST、応答コード、接続元IP、User-Agentを確認します。

200応答やPOSTが繰り返されていれば、単なる残骸ではなく活動中の入口かもしれません。
404でも、別名へ移動された後の探索や、WAFで遮断された記録の可能性があります。

判定は証拠の組み合わせで行う
  • 公式配布物との一致と設置理由
  • 作業履歴と作成・更新時刻の一致
  • コードが受け取る入力と実行する処理
  • アクセスログ上の外部実行・POSTの有無

uploads内PHPの危険度を正常候補・要注意・高危険で分ける

判定に迷う時は、正常か不正かの二択ではなく、根拠に応じて危険度を3段階に分けます。
要注意の段階を設けると、証拠が足りないファイルを安全扱いしたり、正常な処理を急に消したりする事故を防げます。

正常候補は設置理由と公式ファイルの一致を説明できる

正常候補にできるのは、利用中のプラグインが作ることを公式資料で確認でき、配布物や別の正常環境と内容が一致するファイルです。
空のindex.phpであっても、どの製品が、何の目的で置いたかを説明できることが条件です。

正規の更新時刻と一致し、外部からそのPHPへアクセスされた記録がなく、任意入力を実行する機能もなければ危険度は下がります。
ただし、不要なPHPなら、プラグイン提供元へ削除可否を確認し、uploadsで実行できない構成にする方が安全です。

要注意は根拠が不足して安全とも不正とも言えない状態

古いバックアップから復元され、設置元が分からないPHPや、停止済みプラグインの独自フォルダに残るPHPは要注意です。
コードが短く害が見えなくても、呼び出し元や配布元を確認できなければ、安全の根拠にはなりません。

この段階では削除を急がず、実行拒否、原本保全、ハッシュ取得、プラグイン提供元への照会を行います。
テスト環境で無効化した時の影響も確認し、本番サイトでいきなり操作しないでください。

高危険は外部操作・難読化・実行履歴が重なる

年月フォルダに突然作られ、POSTで繰り返し呼ばれ、外部入力からコマンドやPHPコードを実行できるなら高危険です。
同じハッシュのPHPが複数階層へ散らばる、削除後すぐ再作成される、所有者や権限が他と違う場合も警戒します。

一見すると画像でも、先頭がPHPコードだったり、末尾に実行コードが追加されたりする偽装があります。
拡張子、MIMEタイプ、ファイル先頭の形式が一致するかを見て、名前だけで画像と判断しないでください。

危険度は固定ではない

調査開始時に要注意でも、アクセスログや公式ファイルとの比較によって高危険または正常候補へ変わります。
判断日、根拠、確認した人を記録し、新しい証拠が出たら評価を更新してください。

uploads内PHPが不正か判断できない時の安全な対応

判断できないPHPは、安全と決めつけず、証拠を残したうえで実行を止める方向へ進めます。
ただし、ファイル1個を削除するだけでは、侵入経路や別のバックドアが残ります。

隔離は証拠保存と影響確認をセットにする

不審ファイルを隔離する場合は、元のパスとハッシュを記録し、Web公開領域の外へ複製します。
その後、uploads側の実行を止め、サイトの画像表示やフォーム添付などに影響がないか確認します。

共有サーバーでは、ファイル名変更だけでは隔離にならない場合があります。
PHPとして解釈されない保存先へ移し、権限とWebアクセスの両方を制限してください。

不正ならサイト全体を調査して正規ファイルへ戻す

不正と判断したら、同じ更新時刻のファイル、wp-config.php、.htaccess、テーマ、プラグイン、管理者ユーザー、データベースも確認します。
uploadsのPHPは結果であり、侵入経路が別にあることが多いためです。

WordPress本体は公式配布物と照合し、テーマとプラグインは信頼できる配布元の正規版へ戻します。
改ざん部分だけを目視で削る方法は、見落としや構文エラーを生みやすいため避けてください。

管理画面、サーバー、SFTP、データベース、メールなどの認証情報は、感染除去後に安全な端末から変更します。
先に変更すると、残ったバックドアから新しい情報を再取得される可能性があります。

削除だけで終わらせない

同じPHPが再作成される場合、別のバックドア、侵害された管理者、盗まれたSFTP情報、未修正の脆弱性が残っています。
再発は「削除に失敗した」のではなく、入口または再設置手段が残っている合図です。

uploadsフォルダでPHPを実行させない再発防止策

調査と復旧後は、uploadsへPHPが置かれても外部から実行できない構成にします。
これは感染ファイルを検出する対策ではありませんが、被害拡大と再侵入の経路を減らせます。

ApacheとNginxで実行拒否を設定する

Apacheでは、uploads配下の.htaccessでPHP系拡張子へのアクセスを拒否できます。
サーバーが.htaccessを許可していることを確認し、必ず画像表示と管理画面のアップロードをテストしてください。

<FilesMatch "\.(php[0-9]?|phtml|phar)$">
  Require all denied
</FilesMatch>

Nginxでは.htaccessが使えないため、サーバー設定側でuploads配下のPHPを拒否します。
レンタルサーバーでは利用者が変更できないことがあるため、提供会社の機能やサポートを確認してください。

location ~* ^/wp-content/uploads/.*\.(php[0-9]?|phtml|phar)$ {
  deny all;
}

アップロード経路と権限も同時に見直す

実行拒否だけでなく、不要な管理者、使っていないフォーム、古いファイル管理プラグイン、放置したSFTPアカウントを整理します。
テーマとプラグインを更新し、公式配布元が確認できない製品は置き換えてください。

uploadsを一律で書き込み禁止にすると、メディア追加や画像生成が止まります。
必要な書き込みは維持しながら、PHP実行だけを止め、最小権限で運用するのが現実的です。

クイックレスキュー365には、uploadsフォルダのPHP動作を禁止する防御機能があります。
ただしマルウェアのスキャン機能はないため、感染確認にはWordfenceなどのスキャンや専門調査を併用してください。

復旧後の確認項目
  • uploads内の実行可能ファイルを再検索した
  • PHPへの直接アクセスが403などで拒否される
  • 画像アップロードとサムネイル生成は正常に動く
  • 同じ不審ファイルが一定期間再作成されていない
  • 管理者・SFTP・サーバーの認証情報を更新した

プラグイン設定だけでなく、更新・バックアップ・緊急復旧まで継続して任せたい場合は、
保守サービス「クイックレスキュー365」の内容も確認してください。

uploadsフォルダのPHPファイルでよくある質問

最後に、uploads内のPHPを見つけた時によくある疑問を整理します。
判断に迷う場合は、削除より先に証拠保全と実行停止を優先してください。

Q
uploadsにindex.phpがあるのは不正ですか?
A

空のindex.phpやコメントだけのファイルは、ディレクトリ一覧を見せない目的で置かれることがあります。
ただし名前だけでは安全と断定せず、内容、更新時刻、設置元プラグインの公式配布物との一致を確認してください。

Q
PHPファイルをダウンロードしても大丈夫ですか?
A

実行せず、隔離した保存先でテキストとして扱うなら調査できます。
業務端末へ直接保存せず、拡張子関連付けによる誤実行を避け、必要なら専門家へ安全な受け渡し方法を確認してください。

Q
Wordfenceで安全と出れば削除しなくてよいですか?
A

スキャン結果だけで安全とは断定できません。
未知のコード、除外設定、短時間だけ存在するファイルもあるため、配置理由、公式ファイルとの差分、ログを合わせて判断します。

Q
PHPを削除したのに再び作られるのはなぜですか?
A

別のバックドア、侵害された管理者、盗まれたSFTP情報、未修正のプラグイン脆弱性などが残っている可能性があります。
再作成時刻を記録し、直前のアクセスログとファイル変更を追ってください。

uploadsフォルダのPHPは実行せず複数の証拠で判断する

uploadsフォルダにPHPファイルがある場合、標準的なメディア保存の用途から外れるため、まず危険を疑ってください。
ただし、安全確認をせずに削除するのではなく、原本保全と実行停止を先に行います。

安全な確認順序
  • 完全なパス・時刻・権限を記録する
  • 原本を保全し、複製のSHA-256を取る
  • uploads全体で実行可能ファイルを検索する
  • 内容、公式配布物、作業履歴、アクセスログを照合する
  • 不正なら全体復旧と認証情報変更、再発防止まで行う

法人サイトや会員サイトでは、PHPの処理内容によって個人情報や認証情報へ触れた可能性も確認します。
アクセスログ、管理画面操作、データベース変更を調べ、影響範囲が不明なら担当者だけで「漏えいなし」と決めないでください。

ホスティング会社へ相談する時は、不審ファイルの完全パス、発見時刻、ハッシュ、関連する接続元IP、実施済みの操作を渡します。
原本を削除していないこと、公開停止やアカウント凍結の有無も伝えると、調査の重複を減らせます。

復旧後は翌日、数日後、更新作業後にも同じ検索を行い、再作成がないかを確認します。
一度だけの正常表示ではなく、ログとファイルの両方が安定していることを完了条件にしてください。

よこやま良平の復旧現場でも、uploadsのPHPだけを消して数日後に再感染した相談は少なくありません。
ファイルは「原因」ではなく「残された入口」の一つと考え、サイト全体を時系列で調べることが安全な解決につながります。

WordPressの不正アクセス・乗っ取りが自分で直せない時は

WordPress・サイト復旧クイックレスキュー

ワードプレスのWordPressエラートラブル解決をしたいなら
クイックレスキューが解決します。

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

・WordPressが真っ白画面
・WordPressがログインできない
・ホームページのマルウェアや乗っ取り
・サイトの表示くずれ
・エラーが表示されている

これらでお悩みなら最短30分ですぐに解決します!

いまなら期間限定で

3つの安心

・万一改善されない場合は全額返金保証で安心!
・30日間動作保証で安心!
・初期費・調査料 0円で安心!

\無料調査・全額返金保証付き/

今すぐ無料で相談する

この記事を書いた人

よこやま良平

こんにちは!20年以上ITエンジニアとして活動してきた
よこやま良平です。

Wordpress復旧やサイト修復、オンライン講座では
200件以上のレビューを頂いており

「すぐに復旧してくれる!」
「当日行ってくれて助かった!」など

評価は4.9/5.0と非常に高く好評です。

またWordPress、SEO、Officeなど25冊以上の書籍を出版しており、
売上ランキング1位を連続で獲得致しました。

その他これまでに3000以上のサービス・システム・サイトを作成。

多くの方の「できない」や「悩み」を解決してきました。
その観点からわかりやすく解説しています。