WordPressのuploadsに.htaccessがある時の確認｜正規防御と改ざんを見分ける

WordPressのwp-content/uploadsを確認した時、見覚えのない.htaccessがあり、削除してよいのか迷っていませんか？
隠しファイルなので感染を疑いやすい一方、画像フォルダでPHPを動かさないために、正規の防御機能が置いた可能性もあります。

結論から言うと、uploads内の.htaccessは、存在するだけでは正常・改ざんのどちらとも断定できません。
削除前に内容、設置元、上位設定、サーバー方式、更新時刻を確認し、正規防御を壊さず不審なルールだけを止める必要があります。

よこやま良平

WordPressの復旧を多数手がけてきたよこやま良平です。わたしの現場経験をもとに、uploads内の.htaccessを安全に判定し、証拠を残して復旧する順番を解説します。

大切なのは、ファイル名だけで削除を決めず、実際に何を許可・拒否しているかを読むことです。
まずはサイトを壊しやすい操作を避けながら、正常な防御と改ざんの違いを整理しましょう。

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

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

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

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

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

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

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

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

WordPressのuploadsに.htaccessがあってもすぐ削除しない

WordPressのuploadsに.htaccessがあっても、最初の行動は削除ではなく内容の保全です。
このファイルは、画像保存先でPHPを実行させない防御にも、不審なファイルを実行可能にする改ざんにも使えるからです。

.htaccessは置かれた階層以下の動作を変える

.htaccessはApache系Webサーバーで使われる分散設定ファイルです。
公開領域直下だけでなく、uploadsのような下位フォルダへ置くと、その場所と配下の年月フォルダへ限定したルールを設定できます。

WordPress本体が標準状態でuploads直下へ必ず作るファイルではありません。
ただし、セキュリティプラグイン、保守担当者、サーバー会社の防御設定が、PHP実行禁止や一覧表示禁止のために作成することはあります。

「WordPress標準ではない」と「不正ファイルである」は同じ意味ではありません。

隠しファイルという理由だけでは感染と判断できない

先頭がドットのファイルは、FTPソフトやファイルマネージャーの設定によって表示されません。
普段見えないファイルが急に現れると不安になりますが、非表示属性は攻撃の証拠ではなく、Unix系環境の一般的な命名です。

反対に、見た目が短く整った設定でも安全とは限りません。
画像拡張子をPHPとして処理する、特定のファイルだけアクセスを許す、外部サイトへ転送するといった数行のルールでも、実害につながる場合があります。

クイックレスキュー

WordPressの不審なPHPファイルは放置していい？危険度と削除判断の考え方

WordPressのuploadsにある.htaccessを正規防御と改ざんで見分ける

WordPressのuploadsにある.htaccessは、禁止している処理と許可している処理を分けて読むと判断しやすくなります。
正常な防御はuploadsで不要な実行を狭める方向、不審な改ざんは画像や特定ファイルの実行・転送を広げる方向に働くことが多いです。

PHP実行を拒否するルールは正規防御の可能性が高い

uploadsは本来、画像、PDF、動画などのメディアを保存する場所です。
通常はPHPを直接実行する必要がないため、FilesMatchなどでPHPへのアクセスを拒否する設定は、防御目的として合理的です。

<FilesMatch "\.(php|phtml|phar)$">
  Require all denied
</FilesMatch>

ただし、Apache 2.2系の古い構文、サーバー会社独自の記述、プラグインが管理するコメント付きブロックなど、正常な書き方は一つではありません。
コード片だけで正誤を決めず、提供元の公式資料や設定画面と一致するか確認します。

実行許可・ハンドラー変更・外部転送は重点確認する

AddHandlerやSetHandlerで画像拡張子をPHP処理へ渡す記述、特定ファイルだけ拒否を解除する記述は、重点確認が必要です。
uploads内の画像に見せたスクリプトを動かすため、攻撃者が実行条件を追加するケースがあるからです。

RewriteRuleやRedirectが外部ドメインを指している場合も、URLをブラウザーで開く前に保全してください。
正規CDNや画像最適化の設定もあり得ますが、検索エンジン・スマホ・参照元だけを条件にした転送は、条件付き改ざんを疑う材料になります。

クイックレスキュー

WordPressのfavicon.icoに不審なコードが入る理由｜偽装マルウェアの確認方法

WordPressのuploadsの.htaccessを変更前に保全する

WordPressのuploadsの.htaccessを変更する前には、ファイル単体ではなく周辺情報を一緒に保全してください。
内容だけコピーしても、完全パス、更新時刻、所有者、権限、同時刻に変わった別ファイルが分からなければ、設置元を追いにくくなります。

原本を別名保存してハッシュと属性を記録する

まず対象ファイルをサーバー上で編集せず、アクセスを限定した保存先へコピーします。
完全パス、ファイルサイズ、更新時刻、所有者、グループ、パーミッションを記録し、可能ならSHA-256ハッシュも残します。

確認例（実際のパスは環境に合わせる）
stat wp-content/uploads/.htaccess
shasum -a 256 wp-content/uploads/.htaccess
find wp-content/uploads -maxdepth 2 -type f -mtime -7 -print

コマンドが使えない共有サーバーでは、ファイルマネージャーの詳細表示とダウンロードで代替できます。
スクリーンショットだけでなく原本も残し、顧客情報やサーバー情報を第三者の解析サイトへ不用意に送らないようにしてください。

同じ時刻に変わったPHP・画像・Cron・ログを結び付ける

.htaccessの更新時刻を起点に、前後の数分から数時間で追加・変更されたファイルを確認します。
uploads内のPHP、二重拡張子、画像として開けないファイル、隠しディレクトリ、上位階層の設定も同じ時系列で照合します。

アクセスログでは対象ファイルへの直接アクセスだけでなく、直前に呼ばれた管理画面、AJAX、REST API、アップロード処理も確認します。
WordPress側の不審管理者、Application Passwords、WP-Cron、mu-plugins、未使用テーマが再生成元になっていないかも調べます。

クイックレスキュー

WordPressマルウェア駆除を自分で行う方法｜感染ファイルを見つける基本手順

WordPressのuploadsにある.htaccessの適用範囲を確認する

WordPressのuploadsにある.htaccessは、サーバーがそのファイルを読む構成か確認して初めて影響を判断できます。
Apache系では有効でも、Nginx単体では通常読み込まれず、LiteSpeedやリバースプロキシ構成では管理画面側の設定が優先されることがあります。

Apache・LiteSpeedはAllowOverrideと上位設定を見る

Apacheでは、サーバー設定のAllowOverrideが許可した範囲で.htaccessが解釈されます。
uploads内のルールだけでなく、公開領域直下、wp-content、年月フォルダにある設定が重なっていないか確認します。

LiteSpeed Web ServerはApache互換のルールを扱えることが多いものの、ホスティング側の制限やキャッシュ機能により挙動が異なります。
「Apache互換だから必ず同じ」と決めず、サーバー会社の公式仕様とテスト用ファイルの応答で確認するのが安全です。

Nginxでは.htaccess削除よりサーバー設定を確認する

Nginxは通常、各フォルダの.htaccessを読み込みません。
そのためuploads内に不審なファイルがあっても、現在のNginx動作へ直接効いていない可能性がありますが、過去環境の残骸や侵害の痕跡として調査対象にはなります。

PHP実行を止める場合は、Nginxのserver/location設定、PHP-FPMへの転送条件、管理パネルの追加ディレクティブを確認します。
効いていない.htaccessだけを削除して安全になったと判断すると、実際の実行条件を見落とします。

サーバー方式が不明なら、レスポンスヘッダーだけで断定せず契約情報と管理画面を確認してください。

WordPressのuploadsの.htaccessを安全に復旧する

WordPressのuploadsの.htaccessを復旧する時は、不審部分だけでなく設置元と実行条件を止めてから正常版へ戻します。
ファイルだけ削除しても、侵害された管理者、Cron、別サイト、テーマ内ローダーが残れば再生成されるためです。

正規の設置元を確認してから隔離・差し替えする

セキュリティプラグインが管理している場合は、設定画面・公式資料・生成コメントと一致するか確認します。
正規機能ならファイルを直接削除せず、プラグイン側の設定変更や再生成機能を使い、意図した防御が残ることを確認します。

不審と判断した場合は、先に原本を保全し、公開領域外へ隔離して影響を確認します。
いきなり完全削除せず、画像表示、PDFダウンロード、フォーム添付、サムネイル生成、バックアップ処理など、uploadsを使う正規機能をテストしてください。

PHP実行禁止はサーバー方式に合う方法で戻す

Apache系でuploadsのPHP実行を止めるなら、現在のPHP拡張子とApacheのバージョンに合う拒否ルールを使います。
.phpだけを対象にしても、環境が.phtmlや別拡張子を実行する設定なら防御が不足します。

ただし、見本をそのまま貼る前に、WordPressやプラグインがuploads内のPHPを正規利用していないか確認してください。
本来は利用しない構成が望ましいものの、古いシステムや独自実装では機能停止が起きるため、ステージングまたは影響を抑えた時間帯で検証します。

クイックレスキュー

WordPressの.htaccessが何度直しても改ざんされる原因｜再生成前に調べる場所

WordPressのuploadsの.htaccess復旧後に再発を確認する

WordPressのuploadsの.htaccessを直した後は、表示が戻っただけで完了にせず、再生成と実行条件の両方を確認します。
攻撃者が置いたファイルを消しても、入口や自動実行が残っていれば、数分後・次回アクセス時・Cron実行時に戻ることがあります。

時間を分けてファイル属性と応答を再確認する

復旧直後、次のCron実行後、管理画面へのログイン後、画像アップロード後など、条件を分けて属性とハッシュを確認します。
更新時刻だけが変わる場合も、正規処理による再生成なのか、不審なプロセスによる上書きなのかを作業記録と照合してください。

テストは、既存の不審ファイルへアクセスして動作を試す方法ではなく、安全な検証用ファイルとHTTP応答で行います。
外部公開中の環境で実行可能性を試すと、ログを汚したり被害を広げたりするため、専門家へ切り替える判断も必要です。

WordPress全体と同じサーバーの別サイトも確認する

uploadsの.htaccessだけが改ざんされるケースでも、侵入口がそのフォルダにあるとは限りません。
脆弱なプラグイン、不審管理者、漏えいしたFTP・SSH、古い別WordPress、サーバー内の残骸から書き込まれる場合があります。

WordPress本体・テーマ・プラグインの正規版比較、管理者と認証情報、Cron、mu-plugins、データベース、アクセスログを確認します。
同じ契約内に複数サイトがあるなら、現在使っていないCMSも含めて棚卸しし、共通の書き込み元を残さないことが重要です。

書き込み禁止だけで再発防止を終わらせない

.htaccessを読み取り専用にしたり、パーミッションを強く制限したりすると、一時的に上書きが止まることがあります。
しかし、それだけでは書き換えようとした不審な処理、侵害されたアカウント、別の書き込み先は残ったままです。

さらに、所有者やPHP実行ユーザーの関係によっては、見た目の数値を変えても同じプロセスが書き込める場合があります。
反対に厳しすぎる設定では、正規プラグインの防御更新やメディア処理が失敗し、別のエラーを増やします。

権限変更は原因調査中の封じ込めとして使い、誰が書き込みを試みたかをログで追い、正規運用に必要な所有者と権限へ戻してください。
ファイル改ざん監視を導入する場合も、通知だけでなく変更時刻、変更元、差分を確認できる構成が実務的です。

キャッシュとWAFを含めて利用者側の表示を確認する

サーバー側の設定が直っても、CDNやブラウザーのキャッシュに古い転送応答が残り、改ざんが続いているように見えることがあります。
逆に管理者だけ正常で、検索経由・スマホ・未ログイン利用者だけ不審な応答が出る条件付き被害もあります。

PCとスマホ、ログイン済みと未ログイン、通常アクセスと検索結果からのアクセスを分け、HTTPステータスと転送先を確認します。
WAFを一時的に切り分ける場合は、対象時間と確認項目を決め、終わったら必ず元へ戻してログを保存してください。

正常表示だけでなく、WordPressから新しい画像を1枚アップロードし、サムネイル生成、公開表示、削除まで確認すると、uploadsの正規機能を壊していないか判断できます。
検証用データは業務画像と分け、テスト後に不要なファイルとメディア登録を整理します。

クイックレスキュー

WordPressマルウェア駆除後にやることは？再感染を防ぐ設定と見直しポイント

WordPressのuploadsと.htaccessに関するよくある質問

uploads内の.htaccessは環境差が大きいため、削除可否や設定方法について同じ質問が起きやすいです。
ここでは、復旧前に押さえたい判断を短く整理します。

uploads内の.htaccessはWordPress標準ファイルですか？

WordPress本体が標準状態で必ず作るファイルではありません。ただし、セキュリティプラグイン、サーバー会社、保守担当者がPHP実行禁止などの防御目的で作る場合があるため、標準でないという理由だけで削除しないでください。

.htaccessを削除すれば不審なPHPは動かなくなりますか？

逆に実行禁止ルールが消え、PHPが動ける状態へ戻る可能性があります。また、実行条件が上位設定やNginx側にあれば削除だけでは止まりません。現在のルールが許可か拒否か、どのサーバー設定が有効かを先に確認します。

Nginxならuploads内の.htaccessは無視してよいですか？

Nginx単体は通常.htaccessを読みませんが、過去のApache環境の残骸、別サーバーへ移した時の危険設定、侵害時に置かれた証拠である可能性があります。現在の影響と設置された理由を分けて確認してください。

自分で判断できない時は何を残して相談すればよいですか？

.htaccess原本、完全パス、更新時刻、所有者、権限、同時刻に変わったファイル一覧、症状、アクセス・エラーログを残してください。認証情報や顧客情報はチャットへ貼らず、安全な共有方法を相談します。

WordPressのuploadsにある.htaccessは内容と適用範囲で判断する

WordPressのuploadsに.htaccessがあっても、隠しファイルという理由だけで感染とは断定できません。
PHP実行禁止などの正規防御もあるため、何を拒否・許可しているか、誰がいつ設置したか、サーバーが読む設定かを確認することが先です。

不審な実行許可、外部転送、説明できないハンドラー変更があれば、原本・属性・ログを保全し、再生成元を止めてから隔離します。
復旧後は時間と操作条件を分けて再発を確認し、uploadsの正規機能とPHP実行禁止が両立している状態を完了条件にしてください。

判断に迷う場合は、削除や上書きの前に証拠を残した段階で相談するのが安全です。

uploadsの.htaccessが正規か改ざんか判断できない時は

uploadsの設定改ざん、不審なPHP、再生成するファイルでお困りなら、
クイックレスキューが証拠保全から調査・駆除・復旧まで対応します。

こんなお悩みなら最短30分ですぐに解決します！
いまなら期間限定で3つの安心保証