5

I manage many WordPress websites and often encounter vulnerabilities related to WordPress plugins. However, I always wonder how these vulnerabilities can be exploited. I am not looking to exploit them myself or asking you to write any exploit. I am simply curious about how they work. Some vulnerabilities are described as "can be used remotely," but I don't understand how they can be leveraged by someone who has no access to the server host.

Example with this vulnerability :

https://nvd.nist.gov/vuln/detail/CVE-2024-7257

They write :

#################################################

The YayExtra – WooCommerce Extra Product Options plugin for WordPress is vulnerable to arbitrary file uploads due to missing file type validation in the handle_upload_file function in all versions up to, and including, 1.3.7. This makes it possible for unauthenticated attackers to upload arbitrary files on the affected site's server which may make remote code execution possible.

######################################

You can find more about that kind of vulnerabilty here : https://cwe.mitre.org/data/definitions/434.html

How can a non-logged remote user call this function if they can't upload any PHP file or code? There are many vulnerabilities of this kind, marked as "can be used remotely by non-authenticated users," and I don't understand how. At the very least, you should have access to the admin to use the plugin.

Thanks

1
  • 2
    How did you come to the conclusion that the vulnerable method is only called in admin-related code? I've checked the source code of the plugin, and this doesn't seem to be true.
    – Ja1024
    Commented Aug 4 at 15:39

1 Answer 1

10

The vulnerability CVE-2024-7257 isn't in the admin-related code. If you look at the vulnerable method ProductPage::handle_upload_file in YayExtra 1.3.7, then this is called, for example, by ProductPage::add_cart_item_option_data which in turn is assigned to the WooCommerce filter hook woocommerce_add_cart_item_data. So the method is called whenever a user (who doesn't have to be authenticated) adds an item to the cart.

This feature is supposed to allow customers to upload a file when they order an item. If the upload was restricted to, say, an image (like when the customers wants to order a T-shirt with a custom design), this would be fine. But due to the vulnerability, the customer can upload arbitrary files, including scripts.

In general, when the CVE description says “unauthenticated attacker”, this really means the attacker can be unauthenticated (unless the description is wrong due to human error). If the feature can only be accessed by an authenticated user, then the attacker may have to “piggyback” on such a user (e.g., through Cross-Site Request Forgery), but the attacker herself is still unauthenticated.

1
  • OK, I see. I thought this function was only called on the admin side to let the admin upload images of production options (and the PHP file that called this function would have an is_user_logged_in check at the beginning). I got it now. Thanks. Commented Aug 4 at 23:41

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .