Description

The WooCommerce Lottery plugin for WordPress is vulnerable to Time-Based SQL Injection via 'orderby' and 'order' GET Parameters in all versions up to, and including, 2.2.9 due to insufficient escaping on the user supplied parameter and lack of sufficient preparation on the existing SQL query. This makes it possible for unauthenticated attackers to append additional SQL queries into already existing queries that can be used to extract sensitive information from the database.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-08-26T08:16:44.660Z",
  "pubdate": "2026-08-26T08:16:44.660Z",
  "executiveSummary": "The WooCommerce Lottery plugin for WordPress, in all versions up to and including 2.2.9, contains a critical Time-Based SQL Injection vulnerability.\nThe flaw originates from insufficient sanitization of the 'orderby' and 'order' GET parameters within the plugin's query logic.\nThis vulnerability allows unauthenticated, remote attackers to inject malicious SQL commands into existing database queries, potentially leading to unauthorized data exfiltration.\nSuccessful exploitation permits attackers to manipulate backend database interactions, which could expose sensitive information including user credentials, configuration details, or other application data stored in the database.\nDue to the nature of the vulnerability, no authentication or special privileges are required to initiate an attack. The exposure is high, as the vulnerability resides in publicly accessible input parameters, enabling potential exploitation by unauthorized external actors.\nGiven the risk of database compromise and data breach, this vulnerability poses a significant security threat to WordPress installations utilizing the affected versions of the WooCommerce Lottery plugin.",
  "technicalDetails": "The root cause of this vulnerability is improper handling of user-supplied input within the plugin's SQL query construction process. Specifically, the 'orderby' and 'order' GET parameters are concatenated directly into SQL statements without adequate escaping or the use of prepared statements.\nThe vulnerable component processes these parameters to dynamically sort query results. Because the application fails to validate these inputs against a strict whitelist or sanitize them properly for SQL context, an attacker can supply crafted input designed to break out of the intended query structure.\nThe exploitation method relies on Time-Based Blind SQL Injection. In this scenario, the attacker injects SQL subqueries containing conditional logic (e.g., IF statements or SLEEP() functions). By observing the server's response time, the attacker can infer the veracity of specific conditions, effectively extracting data character by character from the database.\nThe attack flow proceeds as follows: First, the attacker identifies a request processed by the WooCommerce Lottery plugin that utilizes the 'orderby' or 'order' parameters. Second, the attacker crafts a malicious payload—such as a payload containing a sleep command dependent on a specific database condition—and appends it to the target parameter. Third, the crafted GET request is sent to the WordPress server. Fourth, the server executes the tainted SQL statement, which triggers the injected time-delay logic if the attacker's condition is met. Fifth, by analyzing the latency of the HTTP response, the attacker confirms the success of their condition and proceeds with further queries to map the database structure or extract sensitive information.\nThis vulnerability does not require authentication, meaning any network-exposed WordPress site running the vulnerable plugin version is susceptible to this attack vector. The post-exploitation impact is severe, potentially leading to full database compromise, unauthorized access to user accounts, or the extraction of sensitive business data stored within the WordPress database tables.\nBecause the vulnerability exists in the query building layer, the application fails to distinguish between intended sorting instructions and attacker-supplied SQL commands. The absence of parameterized queries exacerbates this, allowing the database engine to interpret the injected input as part of the executable command rather than as literal data, enabling arbitrary database query execution."
}