CVE-2018-25384: Wikidforum XSS Vulnerability

CVE-2018-25384 Overview

CVE-2018-25384 is a stored cross-site scripting (XSS) vulnerability [CWE-79] in Wikidforum 2.20, an open-source forum application. Authenticated attackers can inject JavaScript into forum replies by submitting crafted HTML through the reply_text parameter. The payload is delivered via the rpc.php endpoint and executes in the browser of any user who later views the affected thread.

The issue stems from insufficient sanitization of user-supplied reply content before rendering it back to other forum participants. Successful exploitation enables session theft, forced browser actions, and forum content manipulation against authenticated viewers.

Critical Impact

Authenticated attackers can store JavaScript payloads in forum replies that execute against every user who views the thread, enabling session hijacking and account takeover within the forum context.

Affected Products

• Wikidforum 2.20
• Wikidforum Community Edition distributions packaged as Wikidforum-com-ed.2.20.zip
• Deployments exposing the rpc.php reply endpoint

Discovery Timeline

• 2026-05-29 - CVE-2018-25384 published to the National Vulnerability Database
• 2026-06-04 - Last updated in NVD database

Technical Details for CVE-2018-25384

Vulnerability Analysis

The vulnerability is a stored XSS flaw classified under [CWE-79]. Wikidforum 2.20 accepts reply content submitted to rpc.php and stores it without stripping or encoding active HTML and JavaScript constructs. When other users load the forum thread, the malicious markup is rendered into the document and executed by the browser.

Exploitation requires only a low-privilege authenticated account capable of posting a reply. No administrative access is needed. The payload persists in the forum database, meaning every subsequent viewer of the thread triggers the script. Impact is scoped to the browser session of victims, but within that scope the attacker can read DOM contents, exfiltrate cookies that are not marked HttpOnly, perform forum actions on behalf of the victim, and pivot to credential phishing.

Root Cause

The root cause is missing output encoding and input sanitization on the reply_text parameter handled by rpc.php. The application treats reply bodies as trusted HTML and inserts them into rendered pages without applying a context-aware escaping routine or an allow-list HTML filter.

Attack Vector

An authenticated attacker submits a POST request to rpc.php containing a reply_text value that includes HTML such as a <script> tag or an event handler attribute on a benign-looking element. The forum stores the payload as part of the reply record. When any other authenticated user opens the thread, the server returns the stored markup inline, and the victim's browser executes the attacker-controlled JavaScript under the forum's origin.

Further technical detail is available in the Exploit-DB #45580 entry and the VulnCheck Advisory on WikiDForum.

Detection Methods for CVE-2018-25384

Indicators of Compromise

• Reply records in the Wikidforum database whose reply_text field contains <script, onerror=, onload=, javascript:, or base64-encoded data: URIs.
• HTTP POST requests to rpc.php with reply_text parameter values containing raw HTML tags or event handler attributes.
• Outbound browser requests from forum users to unfamiliar domains immediately after rendering a thread page.

Detection Strategies

• Inspect web server access logs for POST requests to rpc.php and correlate large or HTML-bearing reply_text parameters with the submitting account.
• Run database queries across the replies table for HTML tag patterns and JavaScript event attributes, then review matches manually.
• Deploy a Web Application Firewall (WAF) rule that flags forum form submissions containing script tags or inline event handlers.

Monitoring Recommendations

• Monitor authenticated forum sessions for anomalous cookie access patterns and unexpected XMLHttpRequest or fetch activity originating from forum pages.
• Track newly created low-privilege accounts that post replies within minutes of registration, a common pattern for XSS abuse.
• Alert on Content Security Policy (CSP) violation reports if a CSP is deployed in report-only mode on the forum host.

How to Mitigate CVE-2018-25384

Immediate Actions Required

• Restrict reply posting privileges to trusted accounts until input handling on rpc.php is hardened.
• Audit existing forum content and remove stored replies containing executable HTML or JavaScript.
• Place the forum behind a WAF configured to block script tags and event handler attributes in reply_text submissions.

Patch Information

No vendor patch is listed in the published advisory. Wikidforum 2.20 remains the affected release, and the project is hosted on the SourceForge Project Page. Operators should review the VulnCheck Advisory on WikiDForum for the latest mitigation guidance and consider migrating to an actively maintained forum platform.

Workarounds

• Apply server-side HTML sanitization on the reply_text parameter using an allow-list filter such as HTML Purifier before storing the value.
• Enforce contextual output encoding when rendering reply content into HTML pages, replacing characters such as <, >, ", ', and & with their entity equivalents.
• Set the session cookie HttpOnly and Secure flags to reduce the impact of script execution against authenticated victims.
• Deploy a strict Content Security Policy that disallows inline scripts and restricts script sources to the forum origin.

# Configuration example: nginx CSP header and WAF-style request blocking for rpc.php
add_header Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'self'" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "SAMEORIGIN" always;

location = /rpc.php {
    # Block obvious XSS payloads in reply_text submissions
    if ($request_method = POST) {
        set $block 0;
        if ($request_body ~* "reply_text=[^&]*(<script|onerror=|onload=|javascript:)") { set $block 1; }
        if ($block = 1) { return 403; }
    }
    include fastcgi_params;
    fastcgi_pass unix:/run/php/php-fpm.sock;
}