Advanced Page Visit Counter 1.0 - Admin+ Stored Cross-Site Scripting (XSS) (Authenticated)

Advanced Page Visit Counter 1.0 – Admin+ Stored Cross-Site Scripting (XSS) Vulnerability Analysis

On October 11, 2023, cybersecurity researcher Furkan ÖZER disclosed a critical security flaw in the Advanced Page Visit Counter WordPress plugin, version 8.0.5. The vulnerability, identified as a Stored Cross-Site Scripting (XSS) attack targeting authenticated administrators, underscores the importance of input sanitization and output escaping in plugin development—especially for tools with elevated privileges.

Overview of the Plugin

The Advanced Page Visit Counter plugin is marketed as a GDPR-compliant alternative to Google Analytics, designed specifically for WordPress websites. It provides detailed tracking of page visits, user behavior, and enhanced eCommerce analytics for WooCommerce stores. Its popularity stems from its simplicity, privacy-first design, and lack of external dependencies.

Despite its reputation for security and privacy, the plugin’s failure to sanitize user inputs in administrative settings exposed a severe vulnerability. This flaw allows authenticated administrators—users with high privileges—to inject malicious scripts that persist across sessions and execute whenever the settings page is accessed.

Technical Breakdown of the Stored XSS Vulnerability

Stored XSS occurs when malicious code is permanently saved on a server and later executed by other users when they access the affected page. Unlike reflected XSS, which relies on user-triggered requests, stored XSS is far more dangerous because it can affect multiple users over time without requiring a specific attack vector.

In this case, the vulnerability lies in the “Today’s Count Label” field within the plugin’s Widget Settings interface. This setting allows administrators to customize the label displayed on the widget, such as “Today’s Count: 123.”

However, the plugin fails to properly sanitize or escape user input. As a result, an attacker can inject arbitrary HTML and JavaScript code directly into this field.

Exploitation Steps and Payload

Here is the step-by-step process to reproduce the vulnerability:

• Install and activate the Advanced Page Visit Counter plugin.
• Navigate to Settings → Widget Settings.
• Locate the Today’s Count Label field.
• Enter the following payload:

<img src="1" onerror="alert(document.cookie)">

Explanation: This payload constructs an <img> tag with a non-existent image source (src="1"). When the browser attempts to load the image, it fails, triggering the onerror event. The JavaScript code inside onerror executes immediately, calling alert(document.cookie)—a classic technique to extract sensitive session cookies from the victim’s browser.

Once saved, this payload remains stored in the plugin’s database. Every time an authenticated user (especially administrators) visits the settings page, the malicious script executes automatically, potentially exposing session tokens or other sensitive data.

Why This Is a High-Risk Vulnerability

Although the plugin targets administrators, the risk is amplified due to the following factors:

• Privilege Escalation Potential: Admin users typically have full access to site configurations, plugins, and database records. If their session cookies are exposed, attackers can impersonate them and gain full control.
• Non-Filtered HTML Capability: Even in environments where unfiltered_html capability is disabled (e.g., multisite WordPress installations), this vulnerability still works because the plugin does not enforce proper sanitization.
• Long-Term Persistence: The payload remains stored indefinitely unless manually removed, making it a persistent threat.

Impact and Real-World Consequences

Imagine a scenario where a malicious admin (or a compromised admin account) injects this XSS payload into the plugin settings. Every time another admin or developer accesses the settings page, their browser executes the script. The result?

• Session hijacking via document.cookie extraction.
• Exfiltration of sensitive data, including login tokens, CSRF tokens, or personal information.
• Potential for further attacks, such as redirecting users to phishing sites or initiating malicious actions via DOM manipulation.

This is not merely a theoretical risk—it is a live exploit that can be demonstrated in real-time, as shown in the exploit video.

Security Best Practices and Fixes

To prevent such vulnerabilities, developers must follow core security principles:

• Input Sanitization: Always sanitize user inputs using functions like esc_attr() or wp_kses() in WordPress.
• Output Escaping: Escape any data rendered in HTML contexts using esc_html() or esc_js().
• Content Security Policy (CSP): Implement CSP headers to restrict execution of inline scripts.
• Role-Based Validation: Ensure that even high-privilege users are restricted from injecting raw HTML or scripts.

Corrected Code Example

Here is how the plugin’s code should be fixed:

// Incorrect (Vulnerable)
update_option('visit_counter_today_label', $_POST['today_label']);

// Correct (Safe)
update_option('visit_counter_today_label', esc_attr($_POST['today_label']));

Explanation: The corrected version uses esc_attr(), which escapes HTML attributes safely. This ensures that any script or malicious code is rendered as plain text rather than executable JavaScript. Even if a user enters <img src=1 onerror=alert(document.cookie)>, it will be displayed as literal text and never executed.

Recommendations for Users

For site administrators using this plugin:

• Update Immediately: Upgrade to a patched version if available.
• Disable the Plugin: If no fix is released, consider removing the plugin until security is addressed.
• Monitor for Suspicious Activity: Check logs and database entries for unusual content in plugin settings.
• Use Security Plugins: Deploy tools like Wordfence or Sucuri to detect and block XSS attempts.

Conclusion

The Advanced Page Visit Counter 1.0 Stored XSS vulnerability serves as a stark reminder: even trusted, privacy-focused plugins can harbor critical flaws. The absence of proper input sanitization—especially in admin interfaces—can lead to catastrophic consequences.

Security in WordPress is not just about preventing external attacks; it’s about safeguarding internal tools from misuse. Developers must treat every user input as potentially malicious, regardless of user role. For administrators, vigilance is key: always verify what you configure, and never assume a plugin is inherently secure.