WordPress updates reset permissions to 775/664 instead of preserving existing permissions #2

New Issue

MrUnknownDE · 2026-04-05T20:25:16+02:00

MrUnknownDE commented

2026-04-05 20:25:16 +02:00

Originally created by @chiareu on 3/31/2026

CloudPanel version(s) affected

2.5.3

Description

On CloudPanel-managed servers, WordPress updates (core, plugins, themes) do not preserve existing file and folder permissions.

During any update operation (even when triggered from the WordPress dashboard), updated directories and files are recreated with default permissions:

Directories → 775
Files → 664

This overrides previously hardened permissions, such as:

Directories → 770
Files → 660 or 644

Expected behaviour:

Existing permissions should be preserved
or
CloudPanel should enforce a secure default (e.g. 770/660)

Actual behaviour:

Updated folders are set to 775
Updated files are set to 664
Existing hardened permissions are overridden

Impact:

Breaks manual security hardening
Violates principle of least privilege
Exposes directories to “others” (read/execute)
Requires manual or scripted remediation after every update

Notes:

This behaviour appears to be a regression (previous setups preserved stricter permissions)
Root cause seems related to PHP-FPM/system umask (0002) not being overridden
Currently no native way in CloudPanel to define or enforce a stricter umask

How to reproduce

Set a theme or plugin folder to 770 (and files to 660 or 644)
Trigger an update from the WordPress dashboard
Check permissions after update

Possible Solution

Workaround:
Using PHP auto_prepend_file to enforce: umask(007);

Suggestion:

Allow configurable umask per PHP-FPM pool
Or enforce secure defaults for WordPress environments
Or preserve existing permissions during updates

Additional Context

OS: Ubuntu 24.04
CloudPanel: v2.5.3
PHP: 8.5
WordPress: latest (observed across multiple installations)

*Originally created by @chiareu on 3/31/2026* ### CloudPanel version(s) affected 2.5.3 ### Description On CloudPanel-managed servers, WordPress updates (core, plugins, themes) do not preserve existing file and folder permissions. During any update operation (even when triggered from the WordPress dashboard), updated directories and files are recreated with default permissions: - Directories → 775 - Files → 664 This overrides previously hardened permissions, such as: - Directories → 770 - Files → 660 or 644 **Expected behaviour:** - Existing permissions should be preserved or - CloudPanel should enforce a secure default (e.g. 770/660) **Actual behaviour:** - Updated folders are set to 775 - Updated files are set to 664 - Existing hardened permissions are overridden **Impact:** - Breaks manual security hardening - Violates principle of least privilege - Exposes directories to “others” (read/execute) - Requires manual or scripted remediation after every update **Notes:** - This behaviour appears to be a regression (previous setups preserved stricter permissions) - Root cause seems related to PHP-FPM/system umask (0002) not being overridden - Currently no native way in CloudPanel to define or enforce a stricter umask ### How to reproduce 1. Set a theme or plugin folder to 770 (and files to 660 or 644) 2. Trigger an update from the WordPress dashboard 3. Check permissions after update ### Possible Solution **Workaround:** Using PHP auto_prepend_file to enforce: `umask(007);` **Suggestion:** - Allow configurable umask per PHP-FPM pool - Or enforce secure defaults for WordPress environments - Or preserve existing permissions during updates ### Additional Context - OS: Ubuntu 24.04 - CloudPanel: v2.5.3 - PHP: 8.5 - WordPress: latest (observed across multiple installations)

MrUnknownDE referenced this issue

2026-04-05 20:25:51 +02:00

issue #200

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github/cloudpanel-ce#2