Description

The WP Visitor Statistics (Real Time Traffic) plugin for WordPress is vulnerable to generic SQL Injection via the 'fullRef' parameter in all versions up to, and including, 8.7 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. This is a second-order SQL injection: an unauthenticated attacker submits a crafted referrer URL to the wmcTrack tracking endpoint, which persists the raw unescaped value into the wp_logVisit table, and the injection is triggered when an administrator next views the Traffic Sources dashboard.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-10-03T07:16:49.200Z",
  "pubdate": "2026-10-03T07:16:49.200Z",
  "executiveSummary": "The WP Visitor Statistics (Real Time Traffic) plugin is susceptible to a second-order SQL injection vulnerability affecting versions up to and including 8.7.\nThe flaw originates from improper sanitization and escaping of user-supplied data within the 'fullRef' parameter.\nUnauthenticated attackers can inject malicious SQL commands via the wmcTrack tracking endpoint, which stores the payload in the wp_logVisit database table.\nThe injection is executed when an administrator accesses the Traffic Sources dashboard, leading to the unauthorized execution of SQL queries.\nThis vulnerability poses a significant risk as it allows for unauthorized data extraction, potentially exposing sensitive database content.\nExploitation requires no authentication, relying on the persistence of malicious input that is later triggered by administrative interaction with the plugin dashboard.",
  "technicalDetails": "The vulnerability resides in the interaction between the wmcTrack tracking endpoint and the plugin's administrative dashboard interface.\nThe root cause is the failure to adequately sanitize or prepare the 'fullRef' parameter before it is persisted into the database. When a visitor reaches the site, the tracking mechanism records referrer information directly into the wp_logVisit table without sufficient escaping.\nThis constitutes a second-order SQL injection attack. An unauthenticated attacker sends a crafted request containing malicious SQL syntax within the 'fullRef' parameter. Because the plugin processes this parameter as trusted input, the malicious query fragment is stored verbatim in the database table.\nThe attack vector is triggered asynchronously. The malicious payload remains dormant until an administrator logs into the WordPress backend and navigates to the 'Traffic Sources' dashboard. At this stage, the plugin retrieves the previously stored, tainted 'fullRef' data and concatenates it into an active SQL query.\nBecause the query is constructed using string concatenation rather than prepared statements or proper parameterization, the database engine executes the injected SQL commands alongside the legitimate query. This context shift allows the attacker to manipulate the query structure, potentially enabling unauthorized access to other database tables, sensitive configuration data, or user credentials.\nAffected versions include all iterations up to and including 8.7. The nature of this vulnerability highlights a breakdown in input validation at the entry point (the tracking endpoint) and a lack of secure query practices at the consumption point (the admin dashboard). Post-exploitation, an attacker could potentially conduct blind or error-based SQL injection to exfiltrate database contents, depending on the server configuration and database permissions associated with the WordPress installation."
}