CVE-2026-9848 is an unauthenticated SQL injection in WP Ticket, the WordPress plugin also listed as Customer Support Ticket System & Helpdesk. It lets a site collect and manage support tickets inside WordPress rather than sending customers to a separate helpdesk. That puts the bug in reach of businesses handling web enquiries, agencies supporting clients, internal IT helpdesks, and WooCommerce or Easy Digital Downloads stores; WordPress.org reported roughly 400 active installations when checked, a count of sites rather than organisations.
The affected versions are 6.0.4 and earlier. A visitor needs no account, ticket, or staff-level access: a normal front-end WordPress search request is enough. The search term is ordinarily treated as text to match against posts. Here, WP Ticket added it directly into a database query used to find ticket-related content.
A search string reaches the database query
The vulnerable code runs for unauthenticated front-end searches and takes WordPress’s s search parameter after WordPress has removed its magic-quotes escaping. It then concatenates that raw value into SQL LIKE conditions within a UNION subquery, without parameterising it or escaping SQL wildcard characters. In practical terms, specially crafted search input can alter the query rather than merely supply words to search for.
That gives a remote attacker a route to extract sensitive information from the WordPress database through an already-existing query. The published severity assessment is CVSS 3.1 7.5, with high confidentiality impact and no integrity or availability impact. SQL injection can expose far more than ticket data depending on the database account’s permissions and what the WordPress installation stores, so teams should not treat the plugin’s helpdesk role as a boundary around the risk.
The fix parameterises the search
Version 6.0.5 changed the unsafe interpolation to an escaped wildcard string passed as query parameters. The important shift is that user input becomes data supplied to %s, rather than syntax joined into the SQL statement:
+ $wildcard_search = '%' . $wpdb->esc_like($search) . '%';
- $input_add .= "(" . $wpdb->posts . ".post_title LIKE '%" . $search . "%' OR " . $wpdb->posts . ".post_content LIKE '%" . $search . "%'))";
+ $input_add .= $wpdb->prepare("(" . $wpdb->posts . ".post_title LIKE %s OR " . $wpdb->posts . ".post_content LIKE %s))", $wildcard_search,$wildcard_search);The vendor’s WordPress.org changelog describes 6.0.5 only as fixing unauthenticated SQL injection for the search parameter; it does not provide indicators of compromise or a standalone security advisory. WordPress.org now lists 6.0.6, so administrators should update to that or a later patched release, rather than pinning to the first fixed build. The detailed advisory identifies the affected and fixed boundaries and credits researcher she11f.
Public demonstration, but no confirmed attacks
Public web-published demonstration material with requests and extraction payloads has surfaced, so it is inaccurate to say no public proof of concept exists. However, a maintained, researcher-authenticated GitHub or Exploit-DB repository for CVE-2026-9848 could not be independently confirmed. More importantly, there is no confirmed report of exploitation in the wild, no named victim or campaign, and the CVE is not in CISA’s Known Exploited Vulnerabilities data. NVD’s SSVC enrichment recorded exploitation as none on June 15, 2026.
Inventory WordPress sites that use WP Ticket, update them, and review web and database logs for unusual search requests or unexpected query errors around the exposure period. If logs or database contents suggest disclosure, rotate credentials stored in WordPress and investigate scope. SecAlerts monitors an organisation’s actual software stack and alerts on new vulnerabilities affecting the products it runs, which is useful when a small plugin turns a public search box into a database exposure path.
