SQL Injection Vulnerability Patched in RSS Aggregator by Feedzy WordPress Plugin

🎉 Did you know we’re running a Bug Bounty Extravaganza again?

Earn over 6x our usual bounty rates, up to $10,000, for all vulnerabilities submitted through February 29th, 2024 when you opt to have Wordfence handle responsible disclosure!

On February 1st, 2024, during our second Bug Bounty Extravaganza, we received a submission for a SQL Injection vulnerability in RSS Aggregator by Feedzy, a WordPress plugin with more than 50,000+ active installations. The vulnerability enables threat actors with contributor-level permissions or higher to extract sensitive data from the database, such as password hashes.

Props to Lucio Sá who discovered and responsibly reported this vulnerability through the Wordfence Bug Bounty Program. This researcher earned a bounty of $329.00 for this discovery during our Bug Bounty Program Extravaganza.

All Wordfence Premium, Wordfence Care, and Wordfence Response customers, as well as those still using the free version of our plugin, are protected against any exploits targeting this vulnerability by the Wordfence firewall’s built-in SQL Injection protection.

We contacted Themeisle on February 8, 2024, and received a response on the same day. After providing full disclosure details, the developer released a patch on February 9, 2024. We would like to commend Themeisle for their prompt response and timely patch, which was released in just one day.

We urge users to update their sites with the latest patched version of RSS Aggregator by Feedzy, which is version 4.4.3, as soon as possible.

Vulnerability Summary from Wordfence Intelligence

The RSS Aggregator by Feedzy – Feed to Post, Autoblogging, News & YouTube Video Feeds Aggregator plugin for WordPress is vulnerable to SQL Injection via the ‘search_key’ parameter in all versions up to, and including, 4.4.2 due to insufficient escaping on the user supplied parameter and lack of sufficient preparation on the existing SQL query. This makes it possible for authenticated attackers, with contributor access and above, to append additional SQL queries into already existing queries that can be used to extract sensitive information from the database.

Technical Analysis

RSS Aggregator by Feedzy is a WordPress plugin, which includes many features, such as feed to post, import, RSS feed display and many more.

While use of the wpdb prepare() function is the most effective method of preventing SQL injection, it’s not a foolproof solution and it is possible for developers to use it in a way that still allows exploitation. Unfortunately in this case, inappropriate use of the wpdb prepare() function allows for SQL injection in vulnerable versions of the plugin. Examining the code reveals that the plugin uses the fetch_custom_fields() function in the Feedzy_Rss_Feeds_Import class to query the custom fields for the specified post type. The function also contains a ‘search_key’ parameter, which can be used to search postmeta keys.

public function fetch_custom_fields() {
    global $wpdb;

    // @codingStandardsIgnoreStart
    $post_type  = isset( $_POST['post_type'] ) ? filter_input( INPUT_POST, 'post_type', FILTER_UNSAFE_RAW ) : '';
    $search_key = isset( $_POST['search_key'] ) ? filter_input( INPUT_POST, 'search_key', FILTER_UNSAFE_RAW ) : '';
    // @codingStandardsIgnoreEnd

    $like = '';
    if ( ! empty( $search_key ) ) {
        $like = " AND $wpdb->postmeta.meta_key LIKE '%$search_key%'";
    }

    // phpcs:ignore
    $query_result = $wpdb->get_results( $wpdb->prepare( "SELECT DISTINCT($wpdb->postmeta.meta_key) FROM $wpdb->posts LEFT JOIN $wpdb->postmeta ON $wpdb->posts.ID = $wpdb->postmeta.post_id WHERE $wpdb->posts.post_type = '%s' AND $wpdb->postmeta.meta_key != '' AND $wpdb->postmeta.meta_key NOT RegExp '(^[_0-9].+$)' AND $wpdb->postmeta.meta_key NOT RegExp '(^[_feedzy].+$)' AND $wpdb->postmeta.meta_key NOT RegExp '(^[0-9]+$)'$like LIMIT 0, 9999", $post_type ), ARRAY_A );

The filter_input() function with FILTER_UNSAFE_RAW removes slashes, which means that WordPress global default magic quotes protection is removed with that.

Typically, the prepare() function would parameterize and escape the SQL query for safe execution in WordPress, thereby providing protection against SQL injection attacks. But, in this instance, the $like value is not used as a parameter, it is just appended to the query as a string. This is a perfect example of why developers need to properly use functions in order for them to provide the security they intend to.

While initially verified as a time-based blind SQL injection, UNION-based SQL injection also appears to be possible with this vulnerability, meaning that an attacker could retrieve information from the database much more quickly than with blind injection.

How to use the Prepare Function

Let’s take an example where the prepare function is used incorrectly:

$query = "SELECT * FROM $wpdb->posts WHERE post_type = %s AND post_title LIKE '%$search%'";
$wpdb->get_results( $wpdb->prepare( $query, array( $post_type ) ) );

This code is vulnerable. The $search value is not specified and used as a prepare parameter, instead it is just appended to the query as a string. This means that the $search value will not be escaped and will be used as in the query, allowing characters such as “‘“, which can be used to break out of the existing query and append additional SQL commands.

The following is an example where the prepare function is used correctly:

$query = "SELECT * FROM $wpdb->posts WHERE post_type = %s AND post_title LIKE %s";
$wpdb->get_results( $wpdb->prepare( $query, array( $post_type, '%' . $wpdb->esc_like( $search ) . '%' ) ) );

In this case, the $search value is specified as a prepare parameter which means it will undergo the standard escaping that prepare() provides. In addition, esc_like() is used on the function to provide added escaping on the $search value used in a LIKE clause. It is important that all user inputs must be passed to the query as prepare parameters, otherwise they will not be escaped and they can be used to perform SQL Injection attacks.

Wordfence Firewall

The following graphic demonstrates the steps to exploitation an attacker might take and at which point the Wordfence firewall would block an attacker from successfully exploiting the vulnerability.

The Wordfence firewall rule detects the malicious SQL query and blocks the request.

Disclosure Timeline

February 1, 2024 – We receive the submission of the SQL Injection vulnerability in RSS Aggregator by Feedzy via the Wordfence Bug Bounty Program.
February 7, 2024 – We validate the report and confirm the proof-of-concept exploit.
February 8, 2024 – We initiate contact with the plugin vendor asking that they confirm the inbox for handling the discussion.
February 8, 2024 – The vendor confirms the inbox for handling the discussion.
February 8, 2024 – We send over the full disclosure details. The vendor acknowledges the report and begins working on a fix.
February 9, 2024 – The fully patched version of the plugin, 4.4.3, is released.

Conclusion

In this blog post, we detailed a SQL Injection vulnerability within the RSS Aggregator by Feedzy plugin affecting versions 4.4.2 and earlier. This vulnerability allows authenticated threat actors with contributor-level permissions or higher to inject malicious SQL queries to steal sensitive information from the database. The vulnerability has been fully addressed in version 4.4.3 of the plugin.

We encourage WordPress users to verify that their sites are updated to the latest patched version of RSS Aggregator by Feedzy.

All Wordfence users, including those running Wordfence Premium, Wordfence Care, and Wordfence Response, as well as sites still running the free version of Wordfence, are fully protected against this vulnerability.

If you know someone who uses this plugin on their site, we recommend sharing this advisory with them to ensure their site remains secure, as this vulnerability poses a significant risk.