CVE-2025-1648 | Yawave Plugin Unauthenticated SQL Injection

Overview

Last year, Atvik Security was performing security reviews on various WordPress plugins. Because the vast majority WordPress plugins’ source code is freely available, code security audits can easily be performed. When viewing a plugin on WordPress.com, you can see a plugin’s source code after selecting the “Development” tab. When reviewing the Yawave wordpress plugin we found a completely unauthenticated SQL injection vulnerability.

At the time of writing, the source code is available from the WordPress API here. This vulnerability was assigned the identifier CVE-2025-1648. This vulnerability affects Yawave versions <=2.9.1, and the plugin is currently closed for download. This means that all current versions of the plugin are vulnerable, and there is no remediation.

You can easily test if you have the Yawave plugin installed and to see if you’re impacted. If you make a request to the following URL of your WordPress instance, and see a really strange error that looks like the following screenshot:

http://<wordpress-host>/wp-admin/admin-ajax.php?action=js_liveblog_update

You are affected. You need to disable and remove the Yawave plugin from your WordPress instance, as anyone navigating to the website can read or write data to the WordPress database, including fetching usernames, passwords, and any other databases the WordPress database user has access to. These claims were validated in Atvik Security’s lab environment.

Detail

The issue arises from the following flow within the shortcode.liveblog.php file of the Yawave plugin:

1. js_liveblog_update action is registered, without any privilege requirements (unauthenticated action allowed) [Line 67]
2. $get_liveblog_id is then set to the user provided URL parameter lbid after it goes through the sanitize_text_field function [Line 77]
3. The value of $get_liveblog_id is then used in the value of $filter_in_rows_var, as raw SQL [Line 96]
4. The value of $filter_in_rows_var is then used in the get_results function to execute the raw SQL against the WordPress database. [Line 122]

Here are all the code issues in a single screenshot, from injectable locations to database SQL execution:

Let’s dive into why this even happens in the first place. Although the sanitize_text_field() function is used in an attempt to sanitize the user input against all attacks, it is unsuccessful:

$get_liveblog_id = sanitize_text_field($_GET['lbid']);

The value of $filter_in_rows_var is then directly used in the SQL queries on lines 122, 130, and 140. A completely unauthenticated attacker can make requests that contain the URL parameter lbid to gain access to the WordPress database and execute queries against it. This means that anyone navigating to the website can read or write data to the WordPress database, including fetching usernames, passwords, and any other databases the WordPress database user has access to. These claims were validated in Atvik Security’s lab environment.

With this vulnerability, it is possible to enumerate the database without any other requirements. You can enumerate usernames, password hashes, tables, and any information you would like.

An example request can be seen below:

GET /wp-admin/admin-ajax.php?action=js_liveblog_update&lbid=<Inject SQL here>

As a full example, upon navigating to the following URL:

http://<wordpress-host>/wp-admin/admin-ajax.php?action=js_liveblog_update&lbid=(SELECT%205845%20FROM%20(SELECT(SLEEP(5)))FdfP)

The database to sleep for 5 seconds (because it takes ~5 seconds for the page to load), showing that it is under our control and that there is at least blind SQL injection. The above string is the URL encoded version of:

action=js_liveblog_update&lbid=(SELECT 5845 FROM (SELECT(SLEEP(5)))FdfP)

Even though the function sanitize_text_field() is used on line 77 of shortcode.liveblog.php, this only provides protections against XSS and not SQLi, especially when the input is used directly in an SQL query.

Also, it is possible to see the entire value of $output_array just by making a request against:

/wp-admin/admin-ajax.php?action=js_liveblog_update

There are certainly more errors and issues you can cause, especially with this error page at your disposal.

Atvik Security made the following suggestions to the developer, to remediate the vulnerability:

• When raw SQL queries are required, always use $wpdb->prepare().
• Use placeholders (%d, %s, etc.) instead of direct variable concatenation.
• For numeric values, consider additional validation using int() or similar typecasting
• Consider using WordPress’s built-in functions where possible instead of raw SQL

Disclosure Timeline

Atvik Security reached out several times over email, and then over LinkedIn where the Yawave company appeared more active but we never received a response. Below is a timetable of discovery and disclosure.