Part of the reason that WordPress remains so insecure is that you have a WordPress security industry largely built around profiting off issues not being properly addressed instead of working to get them properly addressed. The developer of the most popular WordPress security plugin, Wordfence, has been a prime offender for years. When there is a chance to help improve the security or a chance to promote themselves, their choice has repeatedly been to promote themselves. One area is in with server-side request forgery (SSRF).

WordPress has a set of functions for making requests to URLs that are supposed to prevent SSRF. Here is how that is described with the function wp_safe_remote_get():

This function is ideal when the HTTP request is being made to an arbitrary URL. The URL, and every URL it redirects to, are validated with wp_http_validate_url() to avoid Server Side Request Forgery attacks (SSRF).

The problem is that it doesn’t actually accomplish that in a known way.

In December 2022, Wordfence published a post about SSRF titled “Exploiting WordPress Plugin Vulnerabilities to Steal AWS Metadata.” They had this explanation of addressing SSRF:

Preventing the creation of SSRF vulnerabilities is similar to other vulnerabilities. Developers must develop their code in a way that accounts for vulnerabilities within the chosen programming language, and also ensures that any input is properly sanitized and validated.

In order to properly validate the input, the developer must understand how the functionality can be misused, and programmatically eliminate each way the functionality can be misused. That is why understanding the impact of vulnerabilities such as SSRF vulnerabilities is critical for developers. Keeping code secure can be difficult to ensure during the development phase, which is why the code must be tested for vulnerabilities during and after it has been written.

For SSRF vulnerabilities specifically, the best method for developers to secure the endpoint is to ensure that all forms of input are properly validated and URLs are properly restricted if passed to a function that does a call to the URL. This means that every input should only be accepted if it meets the expected formatting and content, and checks should be in place to ensure that the current user is allowed to make the request. If the request does not fit what is expected from the application, the user is not authorized for the request, or the location the request is coming from is not the expected location, then the request should simply return an error.

That is a lot of words without giving people a clear answer of what should be done.

If the WordPress functions actually prevented SSRF, the answer should have been to use the relevant WordPress function. It doesn’t. The example used involved making a request to the IP address 169.254.169.254, which those functions don’t block. It should as that IP address is “is used in AWS, Azure, GCP and other cloud computing platforms to host instance metadata service.” By comparison, when requesting 127.0.0.1, which should also be blocked, the request will fail with the message that “A valid URL was not provided.”

Wordfence had a chance to get this right in June 2023 when they had another post about the issue. In this case, a plugin was using wp_remote_get() when they should have been using wp_safe_remote_get(). Wordfence didn’t note that, which might have to do with disclosing that wp_safe_remote_get() has an issue (like when they neglected to mention the issue with maybe_unserialize()).

Wordfence has had more chances to get this right as someone writing about this issue with the failing SSRF protection in those functions in February wrote this:

I won’t mention any names here also because I have some pending reports on Wordfence, but let’s simply say that your favorite form plugin(s) and your favorite ecommerce plugin are vulnerable at the time of writing.

But Wordfence hasn’t.

It should be easy enough to understand why, as addressing the problem in WordPress and making sure plugins use the secured function would give them less chance to get press coverage while the issue continues to not get addressed.

It would be great if Wordfence would change what they are doing, but unless others in the WordPress community start addressing the problem of security providers who are able to profit off of not helping to get things properly fixed, it is highly unlikely to happen.