Site scan reports WP 6.1.1 vulnerability

i too
noticed on all my websites this morning (in the UK) have this same reported from PLESK Control Panel / WordPress Toolkit.

has this link for more info
https://patchstack.com/database/vulnerability/wordpress/wordpress-6-1-1-unauth-blind-ssrf-vulnerability?_a_id=110

and if hover over info “i” :
Unauth. Blind SSRF vulnearbility via DNS Rebinding discovered by THomas Chauchefoin in WordPress versions 6.1.1

dont know if a CVE has been raised in the past for this
have also reached out to Wordfence plugin masters at Defiant

Hallo PG-FUN,

I have the same problem – and I using PLESK too.

@wmonlinemarketing @pg-fun

If you have fail2ban, it would be the best solution to create a jail to filter and block request against wp-xmlrpc

If You like advice, I’ll provide:

In PLESK backend fail2ban do this:

1) create a filter “wp-xmlrpc”:

[Definition]
failregex = ^<HOST> .* "(GET|POST) .*xmlrpc\.php.*
ignoreregex = 

2) and create a jail “wp-xmlrpc” and select the filter “wp-xmlrpc” at action:
iptables-allports[name="wp-xmlrpc"]
and at logfiles:
/var/www/vhosts/system/*/logs/*access*log
Bantime as You like (1 day: 86400 / 1 week: 604800 / ever: -1)
86400
and count
1

Check if fail2ban is active and there should be entries soon ??
Cheers!

Or you can just use the option to disable xmlrpc, at least until a patch is released

-Mia

Hi there,

Re: WP <= 6.1.1 – Unauthenticated Blind SSRF via DNS Rebinding:

iThemes Security integrates and pulls information from the WPScan Database, so as long as no fix is reported there, the vulnerability will show on our plugin’s Site Scan report.

Please take a look at our blog post for more details about this vulnerability and how to protect your site: https://ithemes.com/blog/unpatched-vulnerability-in-wordpress-core/.

If you have already disabled the XML-RPC feature, please follow the steps in muting the vulnerability notification here: https://help.ithemes.com/hc/en-us/articles/360046334433-iThemes-Security-Pro-Site-Scanner.

I hope this helps, and thank you for understanding.

thanks

xmlrpc is an option but may effect some wordpress plugins like Jetpack for example not one i use…

also why yesterday all fine all my sites then today highlights this vulnerability.

aslo as per:

https://blog.sonarsource.com/wordpress-core-unauthenticated-blind-ssrf/

been around for a while!

all my WP websites have this “flagged” now and yesterday / previously did not!!

ITSP only does a version compare, it’s not checking if pingbacks are enabled or not, nor if XML-RPC is enabled or not, so it’s going to throw this on all sites regardless of settings.

IMHO, muting the vulnerability in ITSP is the best/easiest solution to the annoying warnings about this.

Disabling Pingbacks and Trackbacks (presuming you don’t use them, few blogs still do) is the easy low effort solution to fully mitigate this. You should do that anyway if you’re not using them, but IMHO again even that’s not really necessary given how difficult this would be to meaningfully exploit.

ITSP’s blog post should have been a bit more detailed to explain just how minor and low priority this vulnerability is. Yes, it’s rated a 5.3 but that’s largely because on it’s own it’s an “unauthenticated vulnerability”, but practically speaking exploiting this vulnerability would require chaining together multiple HYPOTHETICAL vulnerabilities in OTHER systems than WordPress, and even then would just let the attacker DDOS other servers, not gain access to your site.

1) someone would have to hijack DNS resolution on your server so that they could send a different response to a lookup request each time a request was made. Odds of finding a server with that specific vulnerability and exploiting it are very low. If they’ve compromised a server in a way that allows them to commander DNS resolution then you probably have way bigger issues than this vulnerability.

2) someone would have to hijack 1000s of sites in the same manner to mount an effective DDOS attack on another server using this vulnerability.

Again, nothing about this vulnerability would allow a remote attacker to gain access to your server or WP site. It would just let them hijack your pingacks as a DDOS tool aimed at other sites and then ONLY if they also found a way to hijack DNS resolution.

Other than the vulnerability report I haven’t found a good blog post explaining this… maybe I need to write one myself. Until then read the original vulnerability report, it’s good.

????????I received the email via my site admin address for this “critical error” WP <= 6.1.1 – Unauthenticated Blind SSRF via DNS Rebinding…. and there are instructions of what to do which includes logging in to resolve the plug in issue BUT if I try follow the links I am looped back to the notification saying “check your site email for instructions” which again says to log in to resolve. What do I do as I cannot log in as WP log in page now suggests that my account doesn’t exist. Does that mean I have lost my site? I’m not technical. Not sure what to do now or how to get past this log in issue….. my site, with the site admin email as my log in, was working 48 hours ago.

Hello,

how i can to Fix vulnerability in WordPress 6.1.1?

Hi @dazzlinwp21,

As indicated by others in this topic it is highly unlikely this vulnerability will lead to your site being hacked (in the near future). So even doing nothing will keep your site safe.

That said, if you think you will sleep better you can take precautions by turning off XML-RPC (or just the pingback functionality of XML-RPC) which can be done from the iTSec plugin menu:

Security > Settings > Advanced > WORDPRESS TWEAKS -> XML-RPC

Choose “Disable XML-RPC” (or “Disable Pingbacks”) and then click on the blue Save button at the bottom of the page.

I guess some installations get the “mute” link, and some do not. So far, mine do not. Hmm, I just noticed that if I mouseover the spot where the mute link is supposed to be, my cursor changes to a “hand”, indicating a link. Looking at in inspector, sure enough, there’s a <span> with the word mute in it, tagged .mute-trigger. It looks like the color is supposed to be blue, but I’ve got white on white. Opacity for the trigger and description was 0; so I changed opacity to 100, and at first nothing changed, then I happened to look back at it, and it was there, an X next to a tiny button with the word mute on it, as well as the description underneath. However, when I click on it nothing appears to happen. I looked at the line above, and to the right of “WP <= 6.1.1 – Unauthenticated Blind SSRF via DNS Rebinding” there’s a button for unmute.

What gives, iTheme Security? Why make this so difficult?

opacity: 0;
transition: opacity 1s ease-in-out;

Hi @terry777,

It seems the Mute button is only activated on sites with a valid SSL certificate:

Why Don’t I See an Option to Mute a Security Vulnerability?

Web browsers like Chrome and Safari require sites to have an SSL certificate installed to receive requests back to the site.

If your site doesn’t have an SSL certificate installed, your browser will block requests made from the iThemes Security Pro server back to your site. This means that your browser’s security is preventing the Mute vulnerability button from displaying.

Thank you.

So, I have two sites, with SSL, with the free version of iTheme Security installed, with XML-RPC disabled (and has been for some time). The button to mute did not display, but I displayed it by changing the opacity and muted it a few hours ago. I just received yet another warning, went to that same link, it shows a button that says unmute.

So basically, I have to get these messages until when? New version of WP?

I have a number of other sites also with this plugin. I hate to have to invest the time in switching plugins, but this is ridiculous.

@terry777 – it’s not just you. I manage over 100 sites all on the same server, all fully SSL secured, and for no apparent reason on at least 8 if them the mute button doesn’t display / doesn’t work even when the hidden mute link is clicked. All of the sites in question are running iTsec Pro / paid version. I’ve just spent 2 days muting this like crazy and cannot find any clue as to why on some sites the mute simply does not work. I’m checking server / PHP error logs and comparing sites hoping to spot something that would explain this behavior, and if/when I day I’ll post the info here.