A major security issue has occurred on the core server with the major update of WordPress 7.0!

⌛Time it takes to read this article: 2 minutes

Last updated: June 27, 2026 at 3:00 PM

This is a report regarding an issue discovered during the upgrade to WordPress 7.0 released on May 20, 2026 on Core Server V1.
Due to a major WordPress update, the directory permissions were unintentionally rewritten to "757" (octal notation that grants write permission to other users).

In the example below, after a major update, the permissions of all directories in the following hierarchy, including the WordPress plugin folder, are rewritten to "757".

In conclusion, the setting "757" is extremely dangerous and incorrect when operating websites such as WordPress.
This means that all privileges have been given to "Others (third parties)", and since "Writable" is checked in "Others", there is an extremely high risk that a malicious third party will install a malicious file or rewrite (tamper with) an existing file.

The safest permission settings recommended by WordPress officials are "755" for folders and "644" for files (however, "400" or "600" for wp-config.php).

When I checked again, I found that the wp-content and wp-includes folders had all been rewritten with dangerous permissions ``757''.
Therefore, it is necessary to immediately modify all relevant folders to have the correct permissions of "755".

In the first place, as for why permissions were changed in a major WordPress update, according to Gemini, the reasons are as follows, but the direct cause seems to be a combination of "1" and "3" based on the server settings (umask).

🕵️‍♂️ The permission is “757” mechanism

Movements on the WordPress side
When performing a major update to WordPress 7.0 or updating a plugin, old files will be deleted and new folders and files will be automatically generated.

Core server side specifications (CGI mode/owner issue)
Due to security and operational stability of the core server (especially the traditional V1 plan), the user running the program (web server side) and you connecting via FTP (FTP user) may be internally treated as different "owners".

"757" to avoid errors
When WordPress creates a new folder, the server system determines that ``In order for WordPress (the program) to write plugin files (.php, etc.) into this folder from now on, you must allow other permissions (WEB server permissions) to write, otherwise an error will occur.''
Therefore, as a safety valve to prevent the update from failing due to an error, a folder is automatically created with the rightmost number set to ``7 (writable),'' or 757, which is a wide range of permissions.

The following is a quote from Gemini, but it seems that the reason why the permission was unintentionally rewritten to "757" is "Basic server rules: umask settings” as well as “WordPress internal code: FS_CHMOD_DIR” can be summarized easily.

table of contents

Basic server rules: umask settings
WordPress internal code: FS_CHMOD_DIR
Bulk change permissions with net2ftp file manager
Display issues after upgrading to WordPress 7.0

Basic server rules: umask settings

Servers (Linux) have a configuration file (or OS settings) called umask that determines the basic numerical value when creating new files and folders.

Usually, many rental servers default to a safe value of 755 for folders and 644 for files.
However, depending on the specifications of ``when a program (PHP) creates a file'' on a shared rental server such as a core server, or the specific server environment, this basic rule itself may be set to a loose setting close to ``757'' (such as 020 or 000) from the beginning.

WordPress internal code: FS_CHMOD_DIR

On the WordPress side, the program convention (constant) that says, ``When creating a new folder (directory), apply for this permission value'' is written directly into the code.

If the permissions are always buggy due to the server environment, there is a trick to manually add the following "agreement" to the WordPress configuration file wp-config.php. *Ref: Editing wp-config.php

php

/**
 * WordPress のパーミッション自動設定
 */
define( 'FS_CHMOD_DIR', ( 0755 & ~ umask() ) );
define( 'FS_CHMOD_FILE', ( 0644 & ~ umask() ) );

*If you write this code in wp-config.php, when WordPress automatically updates, you will be able to strongly command the server to "create folders with 755 and files with 644!"
This is recommended by the WordPress official as a description method that automatically subtracts and matches the server environment settings (umask), and is said to be relatively error-prone.

Furthermore, if you add this code, it may cause the theme or plugin update to fail, as shown below, so if this problem only occurs during major updates, I don't think there is any need to forcefully add it.
As I will explain later, you can easily change permissions in bulk using the core server's FTP tool.

When WordPress tries to create a folder with "755", the server side may return an error (e.g., update failed: package could not be installed) saying, "With that setting, the WordPress system itself will not be able to write to it, so it will be rejected."

Bulk change permissions with net2ftp file manager

Veteran users may use the Linux shell to change permissions all at once, but manually changing the permissions of hundreds or thousands of directories and files using general FTP software is time-consuming and hellish work.

Fortunately, Core Server V1 provides a tool called ``net2ftp file manager'' that allows you to change permissions for any folder in bulk.
From the control panel (management screen) of the core server, select [FTP Settings] >> [net2ftp File Manager] and change the permissions of the specified directory, including subdirectories, to "755" at once as shown below.
If you want to change files to "644" all at once, change them all to 644 and then change them to 755 all at once.
The gallery below is an example of its application to the wp-content folder.

Bulk changes to 755 will also be made to the wp-admin and wp-includes folders.

Below are the subdirectories within the Jetpack plugin in the wp-content folder, and we have confirmed that the permissions have all been corrected to "755".

Display issues after upgrading to WordPress 7.0

As a side note, after upgrading to WordPress 7.0 in the classic theme, a problem occurred with the display of quote blocks on the block editor editing screen.
This issue was resolved with additional CSS as shown in the article below.