Adiscon LogAnalyzer v.4.1.13 - Cross Site Scripting

Adiscon LogAnalyzer v.4.1.13: Critical Cross-Site Scripting Vulnerability (CVE-2023-36306)

Adiscon LogAnalyzer, a widely used open-source log management tool, has been identified as vulnerable to a critical cross-site scripting (XSS) flaw in versions prior to v.4.1.13. This vulnerability, assigned the CVE identifier CVE-2023-36306, allows attackers to inject malicious scripts into web pages served by the application, potentially compromising user sessions, stealing sensitive data, or redirecting users to malicious sites.

Understanding the Vulnerability

XSS attacks exploit input validation weaknesses in web applications. When user-supplied data is rendered directly in the browser without proper sanitization, attackers can inject scripts that execute in the context of the victim’s session. In the case of Adiscon LogAnalyzer, multiple endpoints accept user input via URL parameters, which are not adequately sanitized.

According to the exploit report by Pedro (ISSDU TW), the vulnerability exists in several key modules:

• asktheoracle.php
• chartgenerator.php
• details.php
• index.php
• search.php
• export.php
• reports.php
• statistics.php

These components are accessible without authentication in file-based installations, making them particularly dangerous for unsecured deployments. Even in database-enabled installations, attackers can leverage a read-only user account to exploit the flaw.

Exploit Examples and Payloads

Below are real-world payloads demonstrating the vulnerability. These payloads leverage URL parameters to inject script tags directly into the rendered page:

http://[ip address]/loganalyzer/asktheoracle.php?type=domain&query=&uid=%22%3E%3Cscript%3Ealert%28%27XSS%27%29%3C/script%3E

This URL constructs a uid parameter that ends with a "> <script> sequence. When processed by the application, the payload is rendered as raw HTML, triggering the alert('XSS') JavaScript function in the browser.

http://[ip address]/loganalyzer/chartgenerator.php?type=2&byfield=syslogseverity&width=400&%%22%3E%3Cscript%3Ealert%28%27XSS%27%29%3C/script%3E=123

Here, the width parameter is manipulated to include a malformed string that bypasses input validation. The %22 is URL-encoded for ", allowing the attacker to close an existing string and inject a script tag.

Similar payloads exist across all listed endpoints, with variations like:

http://[ip address]/loganalyzer/details.php/%22%3E%3Cscript%3Ealert('XSS')%3C/script%3E

Notice the /%22%3E%3Cscript%3Ealert('XSS')%3C/script%3E appended to the path — this is a path-based XSS exploit, where the application fails to sanitize the path segment, leading to script execution.

Attack Surface and Risk Assessment

Installation Type	Authentication Required	Attack Feasibility
File-Based (No DB)	No	High — Publicly accessible endpoints
Database-Based	Yes (Read-Only User)	Medium — Requires user credentials

Attackers can leverage these vulnerabilities for:

• Session hijacking via stolen cookies
• Phishing attacks through redirected pages
• Malware delivery via script injection
• Client-side data exfiltration (e.g., capturing user inputs)

Technical Root Cause

The core issue lies in the application’s lack of input sanitization and output encoding for dynamic content. Specifically:

• URL parameters are parsed directly into HTML output without escaping special characters like <, >, and ".
• Path segments are treated as literal strings, allowing script injection via malformed URLs.
• Use of echo or similar functions without htmlspecialchars() or equivalent sanitization.

For instance, if a PHP script uses:

echo $uid;

without escaping, any input containing <script> will be rendered as actual HTML, leading to XSS.

Remediation and Best Practices

To mitigate this vulnerability, administrators must:

• Upgrade immediately to version v.4.1.13 or later.
• Implement input validation and output encoding using functions like htmlspecialchars() in PHP.
• Enforce strict URL parameter parsing and reject malformed inputs.
• Use Content Security Policy (CSP) headers to restrict script execution.
• Regularly audit third-party components and dependencies.

Additionally, for file-based installations, consider restricting access via firewall rules or reverse proxies, especially if exposed to the internet.

Conclusion

Adiscon LogAnalyzer’s XSS vulnerability underscores the importance of secure coding practices in log management tools. Even seemingly benign features like query parameters or path routing can become attack vectors if not properly sanitized. Organizations relying on this tool must prioritize timely updates and adopt defensive measures such as CSP, input validation, and least-privilege access controls.

Security professionals should treat this as a high-risk vulnerability — especially in environments with exposed web interfaces. Proactive patching and continuous monitoring are essential to prevent exploitation.