CVE-2026-78472 in Ni WooCommerce Sales Report Plugin
Summary
by MITRE • 09/16/2026
The Ni WooCommerce Sales Report WordPress plugin before 4.2.0 does not sanitise and escape a parameter before using it in a SQL statement, allowing unauthenticated users to perform SQL injection attacks.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/16/2026
The vulnerability identified in the Ni WooCommerce Sales Report WordPress plugin prior to version 4.2.0 represents a critical security flaw rooted in improper input validation and data handling practices. Specifically, the application fails to properly sanitize or escape user-supplied parameters before incorporating them into SQL queries executed against the underlying database management system. This deficiency creates a direct pathway for unauthenticated attackers to manipulate the structure of these database commands, bypassing intended access controls entirely. The absence of rigorous input filtering allows malicious actors to inject arbitrary SQL code that is interpreted by the database engine as part of the original query logic rather than as data payload.
From a technical perspective, this flaw aligns with Common Weakness Enumeration identifier CWE-89, which classifies Improper Neutralization of Special Elements used in an SQL Command, commonly known as SQL Injection. The vulnerability exists because the plugin accepts input from external sources without applying necessary escaping functions such as wpdb prepare or equivalent sanitization routines that would neutralize special characters like single quotes, double quotes, and semicolons. When these unescaped inputs are concatenated directly into a query string, they alter the command's execution flow. An attacker can exploit this by crafting specific HTTP requests containing malicious payloads designed to extract sensitive data from the database, modify existing records, or potentially execute administrative commands depending on the privileges of the database user account associated with the web application.
The operational impact of this vulnerability is severe due to its unauthenticated nature. Unlike vulnerabilities that require a valid login session, this flaw allows any internet-connected individual to initiate an attack without prior authentication. This significantly lowers the barrier for exploitation and increases the likelihood of successful compromise. Attackers can leverage automated scanning tools to probe for this weakness across large numbers of WordPress installations. Successful exploitation could lead to full database disclosure, exposing customer personal information, payment details, order histories, and administrative credentials stored within the WooCommerce environment. In worst-case scenarios where the database server is configured with excessive privileges or vulnerable extensions are enabled, an attacker might achieve remote code execution on the hosting server, leading to complete system compromise and potential lateral movement within the network infrastructure.
This type of vulnerability maps directly to several techniques in the MITRE ATT&CK framework for enterprise security. It corresponds primarily to T1190 Exploit Public-Facing Application, as it involves leveraging a flaw in software exposed to the internet. Furthermore, if data is extracted through this vector, it falls under T1213 Data from Information Repositories, and potentially T1564 Hidden Files and Directories or T1078 Valid Accounts if subsequent credential harvesting occurs. The lack of authentication requirement also relates to T1078.1 Default Accounts if default credentials are targeted following the initial breach.
To mitigate this risk, immediate action is required by site administrators using versions of the Ni WooCommerce Sales Report plugin older than 4.2.0. The primary remediation step is to upgrade the plugin to version 4.2.0 or later, where the developers have implemented proper input sanitization and output escaping mechanisms. Until an update can be applied, it is advisable to restrict access to the WordPress admin area using IP whitelisting if possible, although this does not fully mitigate risks associated with public-facing endpoints that might expose other vectors. Additionally, deploying a Web Application Firewall (WAF) configured with rulesets specifically tuned for SQL injection detection and blocking can provide an additional layer of defense by intercepting malicious payloads before they reach the application logic. Regular security audits and code reviews focusing on database interaction patterns are essential to prevent similar vulnerabilities in custom or third-party plugins within the WordPress ecosystem.