Interactive Analysis: CVE-2022-3141

An in-depth look at the authenticated SQL Injection vulnerability in the TranslatePress WordPress plugin.

Vulnerability Overview

CVE-2022-3141 describes a critical SQL injection vulnerability in the "TranslatePress" WordPress plugin (versions < 2.3.3). It allows an authenticated user, even with low privileges, to execute arbitrary SQL commands. The flaw stems from improper sanitization of the 'language code' input, allowing an attacker to inject malicious SQL syntax and control the database. This report visualizes the vulnerability's lifecycle: the flaw, the exploit, and the fix.

CVSS 3.1 Score: 8.8 (High)

AV:N

AC:L

PR:L

UI:N

S:U

C:H

I:H

A:H

The Flaw: Improper Sanitization

The vulnerability lies in how the plugin handles user-supplied language codes. A key function, `sanitize_text_field()`, is misused, failing to escape backticks (`) and allowing an attacker to break out of the SQL query.

Vulnerable Function:

public function get_all_translation_blocks( $language_code ){
    // The query concatenates user input into the table name
    $query = "SELECT original, id, block_type, status FROM `" . 
        sanitize_text_field( $this->get_table_name( $language_code ) ) . 
        "` WHERE block_type = " . self::BLOCK_TYPE_ACTIVE;
    
    $dictionary = $this->db->get_results($query, OBJECT_K);
    return $dictionary;
}

Helper Function:

public function get_table_name($language_code, ...){
    // This function simply concatenates strings
    return $this->db->prefix . 'trp_dictionary_' . 
        strtolower( $default_language ) . '_' . 
        strtolower( $language_code );
}

The Core Flaw

The core issue is that sanitize_text_field() does not escape backticks (`). An attacker can inject a backtick in the `language_code` parameter to close the table name prematurely and then append their own SQL commands.

The Exploit: A Step-by-Step Guide

Exploiting this flaw involves setting up a lab, intercepting traffic to inject a malicious payload, and using automated tools to extract data from the database.

Step 1: Environment Setup

First, we create an isolated lab environment using Docker to host a WordPress instance with a MariaDB database. This prevents any unintended impact on a live system.

docker-compose up -d

Step 1 of 5

The Fix: Whitelisting Input

The vulnerability was patched in version 2.3.3 by introducing a new validation function that whitelists allowed characters for language codes, effectively blocking malicious input.

Vulnerable Code

public function get_table_name($language_code, ...){
    // No validation is performed on $language_code
    return $this->db->prefix . 'trp_dictionary_' . 
        strtolower( $default_language ) . '_' . 
        strtolower( $language_code );
}

Patched Code

function trp_is_valid_language_code( $language_code ){
    // Whitelists allowed characters: a-z A-Z 0-9 - _
    if ( !empty($language_code) && 
         !preg_match( '/[^A-Za-z0-9\-_]/', $language_code ) ){
        return true;
    } else {
        return false;
    }
}
// This function is now called before using the language code.

Key Reflections & Takeaways

Technical Insights

Security controls are not one-size-fits-all. A function like `sanitize_text_field` is for preventing XSS, not SQLi. Context is everything.

Challenges

Replicating environments with specific vulnerable software versions can be challenging but is a critical skill for analysis and verification.

Personal Growth

This analysis bridges theory and practice, solidifying the importance of manual code review alongside automated tooling.