WPScan flags XML-RPC even when disabled in SG Security

Hey there @alderete,

We did a test with the plugin you’ve mentioned, and it gave a message that ‘XML-RPC was found to be disabled’, meaning that everything is working as expected.

When the XML-RPC is Disabled via the SiteGround Security plugin interface, an htaccess rule is added, making sure that the access to the xmlrpc.php is denied.

However, if you still experience the issue, please provide a site URL to check it.

Kind regards,
Stoyan

@stoyangeorgiev Ah, that starts to explain it. There does seem to be an issue here, but it’s not compatibility between the two plugins. It turns out that SG Security isn’t actually disabling XML-RPC on my site.

I think there are two bugs/opportunities for enhancement here.

1) The XML-RPC setting defaults to on. (Correct? I don’t remember needing to enable it.) However, when the plugin is activated it doesn’t check to see if it was actually able to add the .htaccess rule. It just shows the setting enabled, even though no such rule exists in my .htaccess file.

2) When I disabled the SG Security setting for XML-RPC, and then tried to re-enable it, I get an error that it can’t be enabled. “ERROR. Failed to enable XML-RPC.” And the setting remains disabled.

I suspect that the issue is that I’ve manually added a couple of rules to my .htaccess file, and that the plugin’s parser is erring on the side of safety, and not making changes when it can’t be certain it’s not going to break anything. (Yay!)

Seems like the top priority would be making sure the plugin notices errors when it activates settings during initial plugin activation. That’s a genuine bug.

The opportunity for enhancement is to be able to handle .htaccess files that have been touched by more than just WordPress plus the two SiteGround plugins.

For now, I can work around this, and just add the rule manually. Uh…any chance you could provide the right rule here…? (Or, better yet, in the plugin documentation.)

Thanks!

Hmmm, a quick look through the code on Trac, and I think my real issue is that I have Jetpack installed and activated. It seems like the XML-RPC service checks for this, and won’t activate if that (or other XML-RPC-dependent plugins) are active?

I also found the .htaccess rule to add manually, in …/templates/xml-rpc.tpl. Which I’ve done, and tested manually. (Both via direct URL access, and running the WPScan test again.)

I notice that the SG Security plugin is not noticing that I’ve added the rule. For whatever reason, the ‘enabled’ regular expression must be failing. Here’s the exact contents I added to my .htaccess file:

# SGS XMLRPC Disable Service
<Files xmlrpc.php>
    order deny,allow
    deny from all
</Files>
# SGS XMLRPC Disable Service END

Plus blank lines before and after.

In case it’s useful, the site I’m testing against is https://aldosoft.com/.

• This reply was modified 3 years, 5 months ago by alderete.

Hey there @alderete,

Indeed the XML-RPC disable rules are not added if the Jetpack Plugin is present since it is relying on it to work.

We will make sure to add a notice when activating the option in the next release.

As for the second issue with manually adding the rule to the htaccess, make sure you have added the code from the template as it is. The regular expression should catch it, regardless of where in the file it is located.

Thank you for the feedback! It is highly appreciated!

Kind regards,
Stoyan