• We value your experience with Plesk during 2025
    Plesk strives to perform even better in 2026. To help us improve further, please answer a few questions about your experience with Plesk Obsidian 2025.
    Please take this short survey:

    https://survey.webpros.com/
  • On Plesk for Linux mod_status is disabled on upgrades to improve Apache security.
    This is a one-time operation that occurs during an upgrade. You can manually enable mod_status later if needed.

Question odd file rewrites and wp directories

World eSports

New Pleskian
Server operating system version
Alma_Linux
Plesk version and microupdate number
Plesk Obsidian 18.0.75 Web Host Edition
Hey there Plesk community!

I am creating this post because recently I enabled remote backup. I have a dedicated server with (plesk obsidian) and a vps (cloudpanel). I backed up plesk remotely to the VPS. It was successful in backing up the plesk installation. Yes, I know I could not restore these backups to CloudPanel nor am I trying too. I was just storing plesk backups on the VPS. I did not restore any of the backups however. Well, the very next day one of my websites in plesk is down throwing 403 errors throughout. I check the filesystem and noticed in my /public directory (it runs laravel) that there were wp directories such as wp-content, wp-admin, and wp-includes. For those who do not know, the /public directory in laravel is where the application is served inside index.php. Even the index.php was altered and had ini_set() and _GET statements that should never be inside index.php. At first I thought maybe there was a glitch in the backup process and it made a mistake by installing wp directories into a laravel site. Then I realized that I am not even using wp-toolkit for any website so it should have never been touched or even used in the backup. Even my file permissions for the /public directory was changed in an attempt to lock out the admin role from altering the files albeit they could not crack the admins password. I also found .htaccess files throughout the project directories and laravel does not use .htaccess lol nor does plesk add .htaccess files to existing laravel toolkit projects. I have never seen this type of behavior in Plesk, even when using remote backup. I could understand if it was just the wp directories as I do have wp-toolkit installed but not being used.

I deleted all those files from the /public directory yesterday (enabled the backup a couple days prior). I logged in today and guess what? All of those files are present again including the altered index.php.

I only have one question for y'all: was my server hacked or did i botch the backup process? If it is compromised, does anyone have a solution how to lock it down without reinstalling the entire server? I do have DDoS protection from my hosting provider (OVHCloud) but not application-layer protection.

Note: I had turned off ModSecurity because I thought it was blocking client http requests from the frontend. Turns out it was but I disabled the rule and added headers to the http request and they stopped getting blocked. However, I forgot to put ModSecurity back into detection mode. I know its my fault for not turning back on ModSecurity but fail2ban was still on as was the WAP for each domain in plesk.
 
Note #2: I just checked my other laravel projects and one of them also have .htaccess and .DSStore files inside /public which is again, not normal for laravel projects. I definitely did not do this lol.

Note #3: I encrypted the backup using SSH keys ONLY. I did not use password authentication. Perhaps the backup was compromised? I doubt it unless someone had the private key from my server and the public key from my vps which having both is highly improbable.
 
Note #4: I just ran this repair command and was meet with this error. Again, I did not alter these files nor did I restore the backups. I think it was the backups because prior to this none of this was present lol.

root@server:~# plesk repair --fs -y

Checking Linux system files[2026-01-16 19:56:42.810] 2165725:696a97fac5db6 ERR [util_exec] proc_close() failed ['/opt/psa/admin/bin/fsmng' '--check-plesk-packages'] with exit code [1]


Some files packaged by Plesk have incorrect permissions ........... [ERROR]
To see more details, run the command in the verbose mode: plesk repair fs -verbose
Repairing incorrect permissions ................................. [2026-01-16 19:56:52.034] 2165725:696a97fac5db6 ERR [util_exec] proc_close() failed ['/opt/psa/admin/bin/fsmng' '--fix-plesk-packages'] with exit code [1]
[FAILED]
- fsmng failed: ERROR: Unable to retrieve repository
configuration from autoinstaller: autoinstaller is busy

Checking virtual hosts' file system
One or more files or directories in the root directory of the domain
'keithprinkey.bio' are either writable by anyone or neither readable
nor writable by the owner. Such permissions are insecure and may
result in or indicate a security breach ........................... [INFO]
To see more details, run the command in the verbose mode: plesk repair fs -verbose

Error messages: 1; Warnings: 0; Errors resolved: 0
 
I have taken back control the filesystem and permisssions via the root user, turned on ModSecurity to detection mode with daily ruleset updates, increased fail2ban ban parameters to ban offenders much quicker.

I am still curious as to how this happened. I did create a forensics directory with a tar.gz of the malicious files if anyone wants to have a look at them. Someone made all of my .htaccess files in /public/webmail world-writable. I had to log into plesk and open a terminal and take back control of the files and directories.

I hardened the webmail directory with
###############################################################################
# AfterLogic Webmail – Hardened (Apache + PHP-FPM safe)
# Domain: keithprinkey.bio
# Path: /public/webmail
###############################################################################

# ---------------------------------------------------------------------------
# BLOCK ALL PHP EXECUTION BY DEFAULT
# ---------------------------------------------------------------------------
<FilesMatch "(?i)\.(php|phtml|phar|php[0-9])$">
Require all denied
</FilesMatch>

# ---------------------------------------------------------------------------
# ALLOW ONLY THE LEGIT WEBMAIL FRONT CONTROLLER
# ---------------------------------------------------------------------------
<Files "index.php">
Require all granted
</Files>

# ---------------------------------------------------------------------------
# BLOCK WORDPRESS PAYLOAD PATHS (HARD FAIL)
# ---------------------------------------------------------------------------
RewriteEngine On

RewriteRule ^wp-admin - [F,L]
RewriteRule ^wp-content - [F,L]
RewriteRule ^wp-includes - [F,L]
RewriteRule (^|/)wp(/|$) - [F,L]

# Block classic WP PHP entrypoints explicitly
RewriteRule (?i)wp-(config|load|settings|blog-header)\.php$ - [F,L]

# ---------------------------------------------------------------------------
# BLOCK DOUBLE-EXTENSION & DROPPER TECHNIQUES
# ---------------------------------------------------------------------------
RewriteCond %{REQUEST_URI} (?i)\.php\.
RewriteRule .* - [F,L]

# ---------------------------------------------------------------------------
# BLOCK BACKUPS, METADATA, AND RECON FILES
# ---------------------------------------------------------------------------
<FilesMatch "(?i)\.(bak|old|orig|save|swp|tmp|log|sql|zip|tar|gz|7z|rar|DS_Store)$">
Require all denied
</FilesMatch>

# ---------------------------------------------------------------------------
# RESTRICT HTTP METHODS (SAFE FOR WEBMAIL)
# ---------------------------------------------------------------------------
<LimitExcept GET POST HEAD OPTIONS>
Require all denied
</LimitExcept>

###############################################################################
# END FILE
###############################################################################
 
Back
Top