Exploit for CVE-2026-9848

## https://sploitus.com/exploit?id=B0A59809-6697-5CDA-AF4E-0CF7601CE1A5
# CVE-2026-9848
CVE-2026-9848 is an Unauthenticated SQL Injection (SQLi) vulnerability affecting the WP Ticket (Customer Support Ticket System & Helpdesk) plugin for WordPress up to and including version 6.0.4.The flaw occurs because the plugin takes the WordPress search parameter s and concatenates it directly into a SQL LIKE clause inside a UNION subquery without using $wpdb->prepare() or proper escaping. As a result, a remote attacker can manipulate database queries and extract sensitive information without authentication.

Affected Software
Property	Value
Product	WP Ticket (Customer Support Ticket System & Helpdesk)
Affected Versions	≤ 6.0.4
Fixed Version	6.0.5
Affected Component	Front-end Search (s parameter)

Vulnerability Type


  Category: SQL Injection
  CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')

Root Cause

The plugin hooks WordPress's posts_request filter through wp_ticket_com_posts_request(). During an unauthenticated front-end search, it eventually calls emd_author_search_results(), which reads the search parameter:

````html
$query->query_vars['s']
````

At this stage, WordPress has already removed magic quotes using wp_unslash(). Instead of safely parameterizing the SQL statement, the plugin concatenates the raw user input into a SQL LIKE clause within a UNION subquery.

Conceptually:

````text
User searches website
        │
        ▼
Search parameter "s" received
        │
        ▼
Plugin concatenates value into SQL query
        │
        ▼
No $wpdb->prepare()
        │
        ▼
Database executes modified query
````

The vulnerability exists because untrusted input is incorporated into SQL using string concatenation rather than parameterized queries.

Attack Flow
````text
Attacker
    │
    ▼
Submits a crafted search request
    │
    ▼
WordPress passes the "s" parameter
    │
    ▼
WP Ticket builds SQL query using concatenation
    │
    ▼
Database executes injected SQL
    │
    ▼
Sensitive database information may be disclosed
````

Attack Scenario

A normal visitor performs a website search:

````html
GET /?s=printer
````

The plugin incorporates the value of the s parameter into a SQL query that searches ticket-related information.

Because the plugin concatenates the search value directly into the SQL statement instead of using parameterized queries, a specially crafted search request can alter the intended SQL logic. An unauthenticated attacker may exploit this behavior to retrieve sensitive information from the WordPress database, such as usernames or other stored data. The exact outcome depends on the application's configuration and database permissions.

Impact

Successful exploitation may allow an attacker to:


Extract sensitive information from the database.
Enumerate WordPress users.
Read application configuration data.
Access information from plugin-specific database tables.
Gather information useful for further attacks.

The vulnerability primarily impacts confidentiality.

Severity
Metric	Score
CVSS v3.1 (Wordfence CNA)	7.5 (High)

NVD has not yet published its own CVSS assessment.

Conceptual Vulnerable Code

Note: The vendor has not published the complete vulnerable implementation. The following illustrates the vulnerable coding pattern.
````html
$search = $query->query_vars['s'];

$sql = "
SELECT *
FROM tickets
WHERE title LIKE '%" . $search . "%'
";

$wpdb->get_results($sql);
````

Why It Is Vulnerable

The SQL statement is constructed by concatenating user-controlled input directly into the query string. Since the input is not parameterized or escaped, it can alter the structure of the SQL statement.

Corrected Code (Conceptual)
````html
$search = $query->query_vars['s'];

$sql = $wpdb->prepare(
    "SELECT *
     FROM tickets
     WHERE title LIKE %s",
    '%' . $search . '%'
);

$wpdb->get_results($sql);
````

Why This Fix Works

Using $wpdb->prepare() separates SQL syntax from user input. The database treats the search value as data rather than executable SQL, preventing attackers from modifying the query structure. The official fix in WP Ticket 6.0.5 replaces the vulnerable query construction with a properly parameterized implementation.