Introduction
An unauthenticated SQL injection in the WP Ticket WordPress plugin allows any remote attacker to extract sensitive database contents simply by submitting a crafted search query on the site's front end. The vulnerability, tracked as CVE-2026-9848 with a CVSS score of 7.5, requires no authentication, no privileges, and no user interaction, making it trivially exploitable against any WordPress site running WP Ticket versions 6.0.4 and earlier.
WP Ticket, officially titled "Customer Support Ticket System & Helpdesk," is a WordPress plugin developed by eMarket Design LLC that provides a customer support ticket management system integrated into WordPress. The plugin has approximately 400+ active installations and has been available on the WordPress.org repository since December 2014. While its installation base is modest, eMarket Design markets its products as enterprise grade solutions for business applications built on WordPress.
Technical Information
Root Cause: wp_unslash() Stripping Magic Quotes Before Unsafe SQL Concatenation
The core of this vulnerability lies in a subtle but well documented interaction between WordPress core's input handling and the WP Ticket plugin's failure to use parameterized queries. Understanding the full chain requires tracing how user input flows from the HTTP request to the SQL query.
WordPress automatically applies wp_magic_quotes() to superglobal data ($_GET, $_POST, $_REQUEST, $_COOKIE) early in the request lifecycle. This function adds backslash escaping to quotes, providing a baseline layer of protection. However, when WP_Query::parse_query() processes the search parameter s, it calls wp_unslash() on the value, stripping those protective backslashes before storing the result in $query->query_vars['s']. This behavior is explicitly documented in the Wordfence SQL injection research guide as a known pitfall for plugin developers.
The Vulnerable Code Path
The attack chain follows four steps through the plugin's filter hooks:
Step 1: Filter Registration. The plugin hooks WordPress's posts_request filter via wp_ticket_com_posts_request(), defined in filter-functions.php at line 22. This filter fires whenever WordPress constructs a SQL query for posts.
Step 2: Request Interception. When the current request is an unauthenticated front end search, wp_ticket_com_posts_request() calls emd_author_search_results(), defined in common-functions.php at lines 164 and 174. The connection through the filter chain is established via query-filters.php at line 57.
Step 3: Unsafe Input Retrieval. The emd_author_search_results() function reads $query->query_vars['s']. As described above, this value has already been processed by wp_unslash(), meaning the wp_magic_quotes() protection has been stripped. The raw, unescaped user input is now available to the plugin.
Step 4: Direct SQL Concatenation. The function concatenates this raw value directly into a SQL LIKE clause inside a UNION sub-SELECT that is appended to the main WordPress query. No $wpdb->prepare(), no esc_sql(), and no other escaping mechanism is applied.
Exploitation Flow
An attacker exploits this vulnerability through the following steps:
-
The attacker identifies a WordPress site running WP Ticket version 6.0.4 or earlier. The plugin's presence can often be detected through front end markup or by probing for known plugin endpoints.
-
The attacker sends a standard HTTP GET request to the WordPress search endpoint (typically
/?s=) with a crafted value in thesparameter containing SQL syntax. -
Because the search value is concatenated into a
LIKEclause within aUNIONsub-SELECT, the attacker can terminate theLIKEclause using a single quote and inject additional SQL statements. -
Using
UNION SELECTinjection, the attacker can query arbitrary tables in the WordPress database, extracting user password hashes, email addresses, authentication tokens, site configuration data, and any other stored information. -
If direct output is not visible in the search results page, the attacker can fall back to blind SQL injection techniques: boolean-based (observing differences in response content based on true/false conditions) or time-based (using
SLEEP()orBENCHMARK()to infer data from response timing).
The entire attack requires only a web browser or a simple HTTP client. No authentication, no CSRF token, and no user interaction are needed.
CVSS Breakdown
The CVSS v3.1 score of 7.5 (assessed by Wordfence as CNA) breaks down as follows:
| Metric | Value | Meaning |
|---|---|---|
| Attack Vector | Network | Exploitable remotely over the internet |
| Attack Complexity | Low | No specialized conditions required |
| Privileges Required | None | No authentication needed |
| User Interaction | None | No victim action required |
| Scope | Unchanged | Impact confined to vulnerable component |
| Confidentiality | High | Full database information disclosure possible |
| Integrity | None | No direct data modification via this vector |
| Availability | None | No direct denial of service impact |
The NVD's own CVSS assessment was still pending at the time of this writing, with only the Wordfence CNA assessment available.
The Fix
Changeset 3565099 in version 6.0.5 replaces the direct variable concatenation with $wpdb->prepare() parameterized statements, using proper placeholders so that user-supplied values are automatically escaped before being incorporated into the SQL query.
Affected Systems and Versions
The vulnerability affects the WP Ticket plugin (slug: wp-ticket, full title: "Customer Support Ticket System & Helpdesk") for WordPress in all versions up to and including 6.0.4.
Version 6.0.5, released on June 8, 2026, contains the fix. The plugin requires WordPress version 4.5 or higher and has been tested up to WordPress 7.0. PHP 8 compatibility was tested as of version 5.11.0.
Any WordPress site running WP Ticket 6.0.4 or earlier with the front end search functionality accessible to unauthenticated users is vulnerable.
Vendor Security History
eMarket Design LLC's WP Ticket plugin has accumulated a notable track record of security issues. The Wordfence WordPress Plugin Vulnerability Database lists 8 total vulnerabilities for this plugin. The changelog on the WordPress.org plugin page reveals the following pattern of security fixes:
| Version | Security Fix |
|---|---|
| 6.0.5 | Unauthenticated SQL Injection via search 's' parameter (CVE-2026-9848) |
| 6.0.3 | XSS vulnerability fix |
| 6.0.1 | XSS vulnerability fix |
| 5.13 | XSS vulnerability fix |
| 5.6.0 | XSS vulnerability fix |
| 5.1.0 | WP Sessions security vulnerability fix |
This pattern of recurring security defects spanning multiple vulnerability classes (XSS, session security, and now SQL injection) suggests a systemic gap in secure coding practices within the development process. The specific failure to use $wpdb->prepare() in a function that processes unauthenticated user input is a fundamental secure coding error. Organizations relying on this plugin should factor the vendor's security posture into their risk assessment.
References
- NVD: CVE-2026-9848
- Wordfence Threat Intel: CVE-2026-9848 Advisory
- Wordfence: WP Ticket <= 6.0.4 Unauthenticated SQL Injection
- WordPress.org: WP Ticket Plugin Page
- Vulnerable Code: common-functions.php Line 164
- Vulnerable Code: common-functions.php Line 174
- Vulnerable Code: filter-functions.php Line 22
- Vulnerable Code: query-filters.php Line 57
- Fix: Changeset 3565099
- Diff: Version 6.0.4 to 6.0.5
- Wordfence: How To Find SQL Injection Vulnerabilities in WordPress Plugins and Themes
- Wordfence: WordPress Plugin Vulnerability Database
- WP Engine: How to Prevent SQL Injection Attack in WordPress
- VulnCheck: Quantifying 2026 Routinely Targeted Vulnerabilities
- CISA Known Exploited Vulnerabilities Catalog
