最終更新日：2026年6月3日 at 3:38 PM
これは、コアサーバーV1において、2026年5月20日にリリースされた WordPress 7.0 へのアップグレードで判明した件での報告です。
WordPressのメジャーアップデートによって、ディレクトリの権限（パーミッション）が意図せず「757」（8進数でその他ユーザーへの書込権限付与）に書き換わってしまいました。
以下の例では、メジャーアップデート後にWordPressのプラグインフォルダを含めて、以下の階層の全てのディレクトリのパーミッションが「757」に書き換わっています。
結論から言うと「757」という設定は、WordPressなどのWebサイト運用においてセキュリティ上非常に危険であり、正しくありません。
これは、「その他（第三者）」に対してすべての権限を与えてしまっている状態であり、「その他」に「書込可」のチェックが入っているため、悪意のある第三者によって不正なファイルを設置されたり、既存のファイルを書き換えられたり（改ざん）するリスクが極めて高くなります。
WordPress公式が推奨する最も安全なパーミッション設定値は、フォルダは「755」、ファイルは「644」とされています（但し、wp-config.php は「400」または「600」）。
改めて確認したところ、wp-content フォルダ、wp-includes フォルダの全てが危険なパーミッション「757」に書き換えられていました。
よって、全ての当該フォルダを正しいパーミッション「755」へ早急に修正する必要があります。
そもそも、何故、WordPress のメジャーアップデートで、このようなパーミッションに変更されてしまったのかという事に関しては、Gemini によると、以下の理由らしいのですが、直接の原因は、サーバーの設定（umask）に基づく「１」と「３」のコンビネーションではないかと思われます。
🕵️♂️ パーミッションが「757」になったメカニズム
- WordPress側の動き
WordPress 7.0へのメジャーアップデートやプラグイン更新の際、古いファイルを一度消して、新しいフォルダやファイルを自動生成します。- コアサーバー側の仕様（CGIモード / 所有者問題）
コアサーバー（特に従来のV1プランなど）はセキュリティと動作安定のため、プログラムを実行するユーザー（Webサーバー側）と、FTPで接続するあなた（FTPユーザー）が内部的に異なる「所有者」として扱われることがあります。- エラーを回避するための「757」
WordPressが新しいフォルダを作る際、サーバーのシステム側が「これからWordPress（プログラム）がこのフォルダの中にプラグインのファイル（.phpなど）を書き込むためには、その他（WEBサーバー権限）に書き込みを許可しなければエラーになる」と判断します。
そのため、エラーを出してアップデートを失敗させないための安全弁として、自動的に一番右側の数値を「7（書き込み可）」、つまり 757 という広めの権限でフォルダを作成してしまうのです。
以下は、Gemini からの引用ですが、意図せずにパーミッション「757」へ書き換えられた原因と思われる「サーバーの基本ルール：umask設定」ならびに、「WordPressの内部コード：FS_CHMOD_DIR」を簡単に纏めます。
目次
サーバーの基本ルール：umask設定
サーバー（Linux）には、新しくファイルやフォルダを作るときの基本的なベース数値を決める umask という設定ファイル（またはOSの設定）があります。
- 通常、多くのレンタルサーバーでは「フォルダは755、ファイルは644」になるよう安全な値がデフォルト設定されています。
- しかし、コアサーバーのような共有レンタルサーバーで「プログラム（PHP）がファイルを作る時」の仕様や、特定のサーバー環境によっては、この基本ルール自体が最初から「757」に近い緩めの設定（020 や 000 など）になっている場合があります。
WordPressの内部コード：FS_CHMOD_DIR
WordPress側にも「新しいフォルダ（ディレクトリ）を作る時は、このパーミッションの数値で申請しなさい」というプログラムの取り決め（定数）がコード内に直接書き込まれています。
もしサーバー環境のせいで毎回パーミッションがバグってしまう場合、WordPressの設定ファイルである wp-config.php に、手動で以下の「取り決め」を追記する裏技もあります。*Ref: wp-config.php の編集
php
/**
* WordPress のパーミッション自動設定
*/
define( 'FS_CHMOD_DIR', ( 0755 & ~ umask() ) );
define( 'FS_CHMOD_FILE', ( 0644 & ~ umask() ) );※このコードを wp-config.php に書いておくと、WordPressが自動更新する際、「フォルダは755、ファイルは644で作れ！」とサーバーに強く命令できるようになります。
これは、サーバーの環境設定（umask）と自動で引き算をして整合性を合わせる記述方法として、WordPress公式でも推奨されており、比較的にエラーは起きにくいとされます。
なお、このコードを追加すると、以下のように、テーマやプラグインの更新で失敗することもあるそうなので、メジャーアップデート時だけに限りこの事象が発生するのならば、無理に追加する必要はないかと思います。
後述しますが、コアサーバーのFTPツールでパーミッションの一括変更が簡単にできるからです。
- WordPressが「755」でフォルダを作ろうとしたとき、サーバー側が「その設定ではWordPressシステム自身が書き込みできなくなるので拒否します」とエラー（アップデートに失敗しました：パッケージをインストールできませんでしたなど）を返すことがあります。
net2ftp ファイルマネージャーでパーミッションを一括変更
ベテランの方は、Linuxのシェルを使ってパーミッションを一括で変更するのかもしれませんが、それに対して一般的なFTPソフトを用いて手動で何百・何千ものディレクトリやファイルをパーミッション変更するのは手間がかかり、正に地獄の作業となります。
幸いなことに、コアサーバーV1 には、任意のフォルダーに対しパーミッションの一括変更ができるツール「net2ftp ファイルマネージャー」が用意されています。
コアサーバーのコントロールパネル（管理画面）より、[FTP設定] >> [net2ftp ファイルマネージャー] を選択し、以下のように指定ディレクトリのパーミッションをサブディレクトリも含めて「755」へ一括で変更します。
なお、ファイルを「644」へ一括変更したい場合は、644への一括変更後に755への一括変更を実施します。
以下のギャラリーは、wp-content フォルダへの適用例です。
755への一括変更は、wp-admin、wp-includes フォルダに対しても実施します。
以下は、wp-content フォルダの中にある Jetpack プラグイン内のサブディレクトリですが、全て「755」へパーミッションが修正されているのを確認しました。
WordPress 7.0 へのアップグレードでの表示不具合
これは、余談ですが、クラシックテーマにおいて、WordPress 7.0 へのアップグレードを行うと、ブロックエディタの編集画面で引用ブロックの表示に不具合が発生しました。
この不具合は、以下の記事に示す通り、追加CSSで対応しました。
