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

@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!

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.

Hello,

how i can to Fix vulnerability in WordPress 6.1.1?

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;

Thank you.

@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.