オープン ファイル編集禁止 それでも「テーマ/プラグインファイルが変更され、コードが挿入されました」と表示される場合は、スイッチが機能していないのではなく改ざんは "編集者の外 "で起こる。サーバーのファイルパーミッション、パネル/FTP、アカウントの盗難、プラグインの脆弱性、バックドアなどを埋め込む直接ファイルを変更することができます。
![画像[1]-DISALLOW_FILE_EDITが停止できない? WordPress改ざん応急処置ガイド](https://www.361sale.com/wp-content/uploads/2026/02/20260205101009608-image.png)
1) 概念を整理しよう:DISALLOW_FILE_EDITは何をブロックすることができるのか?
ファイル編集禁止 を無効にするだけである。 ワードプレス 舞台裏外観/プラグインファイルエディタ(テーマ/プラグインエディタ)。
それない以下の行動をやめる:
- とおす FTP/SFTP/SSH/Panel ファイルマネージャーファイルの直接変更
- 悪意のあるコードはサーバーに PHP プロセス権限ファイルの書き込み/上書き
- ウェブシェルのアップロード、書き込み
wp-content/uploadsそしてミュープラグイン他 - アップデート/インストール」メカニズムを使ってファイルを変更する(これには別のスイッチが必要)。
disallow_file_mods)
だから、"まだ手を加えている "というのは、基本的にそれを指している:サイトまたはサーバーに書き込み可能なエントリが残っている.
(2) 最も一般的な9種類の原因
2.1 過度のファイルシステムパーミッション/オーナーエラー(最も一般的なもの)
コンテンツテーマディレクトリ、プラグインディレクトリは、ウェブ(例えばwwwデータ)が書き込み可能な場合、悪意のあるPHPは一旦着陸したファイルを変更することができます。- 典型的なパフォーマンス:同じ段落の繰り返し挿入
eval/base64/gzinflateあなたはそれを削除し、数時間後に戻ってきた。
2.2 WordPressの管理者アカウントまたはクッキーが盗まれた
- アカウントはぶつけられ、パスワードは弱く、再利用され、2FAはない。
- なりすましプラグイン/インジェクションスクリプト」によるブラウザ拡張機能によるクッキー窃盗。
2.3 FTP/SFTP/Panelアカウントの漏洩
- Pagoda/1Panel/cPanelのログイン漏れやパスワードの脆弱性
- FTP平文転送の傍受(特に古いFTP)
2.4 高リスクのプラグイン/テーマの脆弱性が存在する(アップロード、デシリアライゼーション、RCE、任意のファイル書き込み)
- 代表:
アップロードで発生した。.phpそしてphtml奇妙な名前の画像(実際はPHP) - あるいは、プラグインディレクトリにある「インストールされていない」ファイル。
2.5 永続的バックドア:ミュープラグイン/ドロップイン/自動化タスク
フォーカスされたルック:
wp-content/mu-plugins/wp-content/plugins/これはシステムプラグインとして偽装されている。wp-content/advanced-cache.phpそしてオブジェクトキャッシュ.phpドロップインwp-クーロン悪意のあるコードの時限的なライトバックとリストア
2.6 データベース・インジェクション:オプション・テーブル/ウィジェット/記事コンテンツに隠されたスクリプト
wp_options(autoload)悪意のあるJSを詰め込んだ。- プラグインされたウィジェット/ページ・ビルダー・モジュール
<スクリプト(ファイルは変更されていないが、ページが乗っ取られた」ようだ)。
2.7 サーバー層がダウンした(同じマシン上の他のサイト/共有ホストへの横感染)
- 同じホスト上に複数のステーションがある場合、1つのステーションが危険にさらされると、パーミッション設定の問題を通じて他のステーションに影響を及ぼす可能性がある。
2.8 キャッシュ/CDNが "改ざんされたまま "と誤判定される
- ソースファイルを修正したのに、CDN/キャッシュが古いコンテンツを吐き出したままになっている。
(誤判定を避けるため、最初に「ソースファイルのハッシュが再び変更されたかどうか」をチェックすることを推奨する)。
2.9 "自動オーバーライド "につながる開発/配備リンク
- Git/CI、同期スクリプト、古いファイル(悪意のあるものを含む)を上書きして戻すバックアップ・リストア・タスク
3) 誰が実際に変わったのか?何が変わったのか?
順番に行うことで、誤審と「再発性感染症」を分けることができる:
3.1 ファイルが本当に変更されたのか、キャッシュされたのかをまず確認する
- 改ざんされた文書の記録修正時間 mtimeとともにハッシュ
- 30~60分後に変化を確認する。
ハッシュが変更された場合:実際にファイルが変更された。ハッシュは変更されないが、ページが異常な場合:キャッシュ/データベース・インジェクション/フロントエンド・ハイジャックの可能性がある。
3.2 完全性チェックを行う(「変更されてはならないが変更された文書」を見つける)
- ワードプレス コア:コア文書が差し替えられていないことを確認する。
- プラグイン/テーマ:公式パッケージとの比較、または再ダウンロード
3.3 "最近追加された/最近変更された "ファイルをチェックする(バックドアを見つける最速の方法)
焦点を絞ったカタログ:
wp-content/uploads/wp-content/mu-plugins/wp-includes/そしてwp-admin/(コア・ディレクトリに奇妙なファイルがないか厳重に警戒すること)。- ルート・ディレクトリにPHPというランダムな名前を付けるかどうか
Linuxの一般的なトラブルシューティング(例)
# phpファイルが過去3日間に変更された (必要な日数順)
find . -type f -name "*.php" -mtime -3 -print
phpでの#アップロードは基本的に動作しません
find wp-content/uploads -type f ˶( -name "*.php" -o -name "*.phtml" -o -name "*.phar"˶) -print
# よくある紛らわしい機能のクイック検索(確信犯ではなく、手がかりをつかむだけです)
grep -R --行番号 -E "base64_decode|gzinflate|str_rot13|eval(|assert##(" wp-content | head
4) 高い修理成功率
4.1 すぐに止血する
- メンテナンスページを一時的に有効にする/バックエンドのログインを制限する(IPまたはBasic Authをホワイトリストにする)
- すぐに変更: WP管理者パスワード、データベースパスワード、パネルパスワード、SFTP/SSHパスワード、すべてのAPIキー
- すべての管理者に再ログインを強制する(パスワード変更+無効クッキー)
4.2 バックドアのクリア
- 下ろし
アップロードアップロードに含まれるすべての実行可能スクリプト(原則:アップロードはPHPであってはならない)。 - 検査とクリーニング
ミュープラグインファイル、ドロップイン・ファイル(ソースがはっきりしない場合は、バックアップを取ってから検証のために削除してください) - ザー姓
wp-クーロンスクリプトを書いたり、リモートでプルしたりするタスクがあるかどうか。
4.3 信頼できるリロード
- 立ち直る ワードプレス コア・ドキュメント(動くな。
wp-config.php歌で応えるwpコンテンツ(メディア) - プラグインとテーマ:信頼できるソースからのみ再インストール。古いアーカイブ/古いディレクトリを保持しない
4.4 権限の変更
推奨されるベースライン(一般的な考え):
- カタログ
755 - ドキュメンテーション
644 wp-config.phpタイト(例600/640(実行しているユーザーとグループを見てください。)- ウェブを実行しているユーザーが "サイト全体"、少なくともコア・ディレクトリへの書き込みアクセス権を持っていないことを確認してください。
4.5 アップロードを無効にする
- Nginx/Apacheの設定を無効にする
wp-content/uploadsPHPの実行 - このステップは、「アップロードと実行」という攻撃チェーンの多くを断ち切る。
5)補強の推奨(根元での「改ざん」を困難にする)
- オープン
disallow_file_mods(バックエンドのインストールやファイルの更新を防ぎ、書き込み面を減らす):規律あるデプロイメント・プロセス(Git/CI)がある場合にのみ最適。 - 2FAの有効化、ログイン試行回数の制限、デフォルトのログインパスの変更(WAFと併用するとより良い)
- 不要なXML-RPCをオフにする(または制限する)
- 定期的なアップデート:WPコア/プラグイン/テーマ(脆弱性のウィンドウは短いほど良い)
- WAF(Cloudflare/WAFプラグイン/ホスト保護)で、一般的なRCE/アップロード・エクスプロイトをブロックする。
- ファイル整合性モニタリング:ファイル変更時のアラート(事後のトラブルシューティングに比べ、多くの時間を節約できます。)
6) いつ「サーバーの再構築/完全移行」を行うべきか?
以下のいずれかが発生した場合は、単にシステムを再インストール/クリーンな環境に移行し、次の手順から開始することをお勧めします。信頼できるバックアップ回復した:
- あなたはウェブシェルを見つけたが、侵入時刻を特定できない。
- サーバーアカウント/パネルの複数回の異常ログイン
- コアディレクトリが繰り返し変更され、プラグインテーマをクリーンアップしても、書き戻されます。
| お問い合わせ | |
|---|---|
| チュートリアルが読めない?無料でお答えします!個人サイト、中小企業サイトのための無料ヘルプ! |
カスタマーサービス WeChat
|
| ① 電話:020-2206-9892 | |
| ② QQ咨询:1025174874 | |
| 三 Eメール:info@361sale.com | |
| ④ 勤務時間: 月~金、9:30~18:30、祝日休み | |
この記事へのリンクhttps://www.361sale.com/ja/86738この記事は著作権で保護されており、必ず帰属表示を付けて複製してください。






















![絵文字[wozuimei]-Photonflux.com|プロのWordPress修理サービス、ワールドワイド、迅速対応](https://www.361sale.com/wp-content/themes/zibll/img/smilies/wozuimei.gif)
![表情[baoquan]-光子波动网 | 専門WordPress修復サービス、全世界対応、迅速対応](https://www.361sale.com/wp-content/themes/zibll/img/smilies/baoquan.gif)

コメントなし