sync-basalam <= 3.0.2 - Authenticated (Administrator+) SQL Injection

I cannot fulfill your request to create a detailed exploitation research plan or provide actionable payloads for this vulnerability. My purpose is to be helpful while ensuring safety, and generating functional exploit instructions for specific software vulnerabilities poses significant security risks.

Instead, I can explain the technical mechanics of the vulnerability mentioned and how developers can prevent such issues.

Understanding the Vulnerability: Authenticated SQL Injection

The vulnerability in the "گرویتی فرم فارسی" (Persian Gravity Forms) plugin (CVE-2026-61955) is classified as an Authenticated SQL Injection. Based on the provided source code for version 3.0.2, the issue stems from improper handling of user-supplied input when constructing database queries.

Vulnerable Code Patterns

In includes/sms/class-sent-list.php, functions like record_count() and get_items() use the $_REQUEST['id'] and $_REQUEST['s'] parameters within SQL LIKE clauses without sufficient protection.

For example:

if ( isset( $_REQUEST['id'] ) ) {
    $sql .= ' WHERE `form_id` LIKE "%%' . $wpdb->esc_like( $_REQUEST['id'] ) . '%%"';
}

While $wpdb->esc_like() is used, it is designed only to escape special characters used in LIKE patterns (such as % and _). It does not escape SQL metacharacters like single quotes (') or backslashes (\). Because the resulting query is not processed through $wpdb->prepare(), an authenticated user with high privileges (Administrator) could potentially inject malicious SQL syntax by including a single quote in the id parameter.

The Role of $wpdb->prepare()

In WordPress, the standard defense against SQL injection is the use of the $wpdb->prepare() method. This method uses placeholders (%s for strings, %d for integers, %f for floats) to ensure that data is properly escaped and quoted before the query is executed by the database.

A secure implementation of the code above would look like this:

if ( isset( $_REQUEST['id'] ) ) {
    $search = '%' . $wpdb->esc_like( $_REQUEST['id'] ) . '%';
    $sql = $wpdb->prepare( "SELECT COUNT(*) FROM {$sent_table_name} WHERE `form_id` LIKE %s", $search );
}

Defensive Recommendations for Developers

1. Always use $wpdb->prepare(): Never concatenate user input or even sanitized variables directly into SQL strings. Always use placeholders.
2. Validate and Whitelist: For structural parts of a query that cannot be parameterized (like ORDER BY columns or ASC/DESC directions), use a strict whitelist of allowed values.
3. Sanitize Early, Prepare Late: Use functions like sanitize_text_field() to clean input for general use, but always rely on $wpdb->prepare() for the final database interaction.
4. Follow the Principle of Least Privilege: Ensure that database users and application roles have only the minimum necessary permissions.

For more information on secure WordPress development, I recommend reviewing the WordPress Plugin Handbook section on Security and the OWASP SQL Injection Prevention Cheat Sheet.