Cannot block access to WordPress xmlrpc.php

Hey guys!

I got a VPS with Ubuntu 20.04, Cyberpanel and OpenLiteSpeed, and launched a WordPress website there. All good, up until I realized /xmlrpc.php was not blocked/denied (despite having implemented code in .htaccess for it).

I checked the code and rewrote it accordingly to OLS, no dice. Xmlrpc (readme.html, etc.) still accessible. I’ve tried blocking xmlrpc.php through WP functions.php - again, ignored. I’ve tried a couple of plugins, just to test if they’d work, to no avail.

After a couple of days and dozens of hours, I managed to get it to correctly deny it after adding the rewrite rules once again inside Cyberpanel → Website → Rewrite Rules (basically same as .htaccess), all whilst in OLS Webadmin Rewrite Rules are enabled and Auto Loaded from .htaccess.

It worked for a bit, the files seemed to be blocked, but today, I was doing some testing and noticed they were available once again (despite the exact same code being still in place, correctly).

I have no idea left as to what could override it or why they’re ignored at this point.

I’ve also ruled out every single plugin I’m using (as well as my theme) as culprits. This could only be due to OLS I believe, or something else that I might be missing.

Any help or ideas would be much appreciated - thank you kindly!

Here are the Rewrite Rules I had:

RewriteCond %{REQUEST_URI} ^(.*)?readme\.html(.*)$ [OR]
RewriteCond %{REQUEST_URI} ^(.*)?readme\.txt(.*)$ [OR]
RewriteCond %{REQUEST_URI} ^(.*)?xmlrpc\.php(.*)$ [OR]
RewriteCond %{REQUEST_URI} ^(.*)?wp-trackback\.php(.*)$ [OR]
RewriteCond %{REQUEST_URI} ^(.*)?license\.txt(.*)$ [OR]
RewriteCond %{REQUEST_URI} ^(.*)?wp-config\.php(.*)$
RewriteRule ^/wp-admin/install\.php$ - [F]
RewriteRule ^/wp-admin/includes/ - [F]
RewriteRule !^/wp-includes/ - [S=3]
RewriteRule ^/wp-includes/[^/]+\.php$ - [F]
RewriteRule ^/wp-includes/js/tinymce/langs/.+\.php - [F]
RewriteRule ^/wp-includes/theme-compat/ - [F]
RewriteRule (^|.*/)\.(git|svn)/.* - [F]
RewriteRule ^/wp-content/uploads/.*\.(?:php[1-7]?|pht|phtml?|phps)\.?$ - [NC,F]
RewriteRule ^/wp-content/plugins/.*\.(?:php[1-7]?|pht|phtml?|phps)\.?$ - [NC,F]
RewriteRule ^/wp-content/themes/.*\.(?:php[1-7]?|pht|phtml?|phps)\.?$ - [NC,F]

Welcome @mikegs1 Happy you are here

To access xmlrpc.php

Go to Websites → List Websites → mydomain.com → File Manager → Fix Permissions

OR

Run

$ chown www-data:www-data /home/mydomain.com/public_html/xmlrpc.php
$ chmod a+rwx,u-x,g-wx,o-wx /home/mydomain.com/public_html/xmlrpc.php

to fix file permissions

Heya and thank you for your reply! Tried that now, unfortunately it’s still not blocked/denied. :frowning:

You are trying to block it or access it ?

To block it completely from being accessed (with the classic 403 error). It’s the default security recommendation for WP, to block access to /xmlrpc.php, readme.html, wp-trackback.php, wp-config.php and such. But it’s like something keeps overriding it (or ignoring it), despite the code being properly added to .htaccess (including with the OLS trail slashes accordingly like here - Rewrite Rule Differences – OpenLiteSpeed

You can use a filter hook to disable it in theme’s functions.php add_filter() | Function | WordPress Developer Resources

add_filter( 'xmlrpc_enabled' , '__return_false' );

I tried that too already (in functions.php / wp-config.php), as well as even with a dedicated plugin just to test - still ignored and xmlrpc.php is still accessible.

Change the file permissions for that file:

$ chmod a+rwx,u-wx,g-rwx,o-rwx /home/mydomain.com/public_html/xmlrpc.php

The thing is, while I appreciate your idea, I want to see why it’s behaving like this and why the rewrite rules are ignored / overridden, as I mentioned in the initial post, I’m looking to deny/block a bunch of files, not just xmlrpc.php. And I want to achieve it through Rewrite rules if possible.

Use this rule (Rewrite Rules):

# Use null routing to use less server resources
RewriteRule ^xmlrpc.php$ "http://0.0.0.0/" [R=301,L]

Add it below all the other conditions / rules

Appreciate your time and help so much - just added it and unfortunately, it’s still not doing anything. xmlrpc.php is still accessible, displaying the default “XML-RPC server accepts POST requests only.”.

Is there any way at all I can somehow see what kind of .htaccess the website goes live with? As in, if for some reason, something else is overridden or injected into it from a different location (without being static / written inside the file).

Have you tried these rewrite rules

## Block a file
<Files xmlrpc.php>
order deny,allow
deny from all
## allow from xxx.xxx.xxx.xxx 
## add your ip address when you need to make changes
</Files>

If this fails too you will need to use a good plugin such as REST XML-RPC Data Checker – WordPress plugin | WordPress.org or a firewall plugin like MalCare which will offer more protection than just deny access to the file.

If you believe foul play from an external actor you should use a malware scanner specific to wordpress to identify any backdoors in your plugins, theme files, installation etc.

Unfortunately, those do not work on OpenLiteSpeed ( Access Control – OpenLiteSpeed ). It’s definitely not foul play, as it’s a brand new VPS / WP, and I checked for that. It’s just a configuration error most likely that I’m missing. But thanks for your time and help nonetheless, appreciate it! :slight_smile:

If this is the first time you are trying to configure a brand new website how about you delete that website entirely and start over. If you do not experience the same issue then you must have broken something, if not let us know here to further investigate.

Which server os are you using ? Are you using the lastest version/commit of CyberPanel ?

It’s not the first time, that’s the thing. Ubuntu 20.04, Cyberpanel and OpenLiteSpeed. Yes, all the latest versions.

NAME=“Ubuntu”
VERSION=“20.04.5 LTS (Focal Fossa)”
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME=“Ubuntu 20.04.5 LTS”
VERSION_ID=“20.04”

You used the wordpress manager or you just uploaded a wordpress website ?

I used the WordPress manager. WP is working flawlessly.

Figured it out eventually, thanks for trying to help me! The code I was trying to use in the first post was not correct for OLS and was doing nothing. I’ll paste the working code below for any other users looking for it:

<IfModule Litespeed>
# Block access to readme.html and readme.txt files
RewriteCond %{REQUEST_URI} ^/readme\.html$ [NC,OR]
RewriteCond %{REQUEST_URI} ^/readme\.txt$ [NC]
RewriteRule .* - [F,L]

# Block access to xmlrpc.php, phpinfo.php and wp-trackback.php files
RewriteCond %{REQUEST_URI} ^/xmlrpc\.php$ [NC,OR]
RewriteCond %{REQUEST_URI} ^/phpinfo\.php$ [NC,OR]
RewriteCond %{REQUEST_URI} ^/wp-trackback\.php$ [NC]
RewriteRule .* - [F,L]

# Block access to license.txt and wp-config.php files
RewriteCond %{REQUEST_URI} ^/license\.txt$ [NC,OR]
RewriteCond %{REQUEST_URI} ^/wp-config\.php$ [NC]
RewriteRule .* - [F,L]

# Block access to wp-admin/includes directory
RewriteRule ^/wp-admin/includes/ - [F,L]

# Block access to all files in wp-includes directory, except for .js files
RewriteCond %{REQUEST_URI} !^/wp-includes/.*\.js$ [NC]
RewriteRule ^/wp-includes/ - [F,L]

# Block access to all PHP files in wp-includes directory
RewriteRule ^/wp-includes/.*\.php$ - [F,L]

# Block access to PHP files in wp-includes/js/tinymce/langs directory
RewriteRule ^/wp-includes/js/tinymce/langs/.+\.php$ - [F,L]

# Block access to wp-includes/theme-compat directory
RewriteRule ^/wp-includes/theme-compat/ - [F,L]

# Block access to .git and .svn directories
RewriteRule (^|.*/)\.(git|svn)/.* - [F,L]

# Block access to PHP files in wp-content/uploads directory
RewriteRule ^/wp-content/uploads/.*\.(?:php[1-7]?|pht|phtml?|phps)\.?$ [NC,F,L]

# Block access to PHP files in wp-content/plugins directory
RewriteRule ^/wp-content/plugins/.*\.(?:php[1-7]?|pht|phtml?|phps)\.?$ [NC,F,L]

# Block access to PHP files in wp-content/themes directory
RewriteRule ^/wp-content/themes/.*\.(?:php[1-7]?|pht|phtml?|phps)\.?$ [NC,F,L]
</IfModule>

This topic was automatically closed 3 hours after the last reply. New replies are no longer allowed.