CVE-2026-94102: Open Redirect in WuzhiCMS Login Component

Summary

CVE-2026-94102 describes an open redirect vulnerability in WuzhiCMS versions up to and including 4.1.0. The flaw resides in the Login component, specifically in the file /index.php?m=member&v=Login. By manipulating the forward parameter, an attacker can redirect a user to an attacker-controlled URL after a login action. The vulnerability has been assigned a CVSS 4.0 base score of 2.1, indicating a low severity impact. The exploit has been publicly published and may be actively used. The vendor was contacted during the disclosure process but did not respond.

Technical Analysis

WuzhiCMS is a content management system that includes a member authentication module. The login page is accessible at /index.php?m=member&v=Login and accepts a forward parameter. This parameter is intended to specify a destination URL to which the user should be redirected after a successful login. The purpose of such a parameter is common in web applications: it allows users to be returned to the page they were originally trying to access after authentication.

The vulnerability arises because the forward parameter is not properly validated as a URL. According to the advisory, the only sanitization applied to the parameter is a call to remove_xss(), which is an XSS keyword and entity scrubber. While remove_xss() may strip certain HTML tags, JavaScript event handlers, and encoded entities that could facilitate cross-site scripting, it does not perform any validation on whether the URL points to a legitimate destination within the application’s own domain. This means that an absolute URL pointing to an external site, such as https://attacker.example.com, would pass through the sanitization function without being blocked.

Open redirect vulnerabilities, classified under CWE-601, occur when a web application accepts user-controlled input that specifies an external link and uses that input as the destination of a redirect. The core problem is the absence of an allowlist or same-origin check. In this case, the application trusts the forward parameter to be a safe internal path, but an attacker can supply a fully qualified external URL instead.

The attack can be initiated remotely, meaning no physical or local access to the target system is required. The attacker does not need to be authenticated, as the vulnerability is in the login flow itself, which is accessible to any unauthenticated user. User interaction is required, however, because the victim must click the crafted link and potentially complete the login process for the redirect to occur. This is reflected in the CVSS vector string, which includes UI:P (User Interaction: Passive).

The CVSS 4.0 vector for this vulnerability is CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:P. Breaking this down: the attack vector is network-based (AV:N), the attack complexity is low (AC:L), no privileges are required (PR:N), and user interaction is passive (UI:P). The impact on the vulnerable system’s confidentiality is none (VC:N), the impact on integrity is low (VI:L), and the impact on availability is none (VA:N). The exploit maturity is set to proof-of-concept (E:P), indicating that a functional exploit has been demonstrated or published.

Affected Software and Versions

Based on the available vulnerability data, the following software is affected:

Product: WuzhiCMS
Affected versions: Up to and including 4.1.0
Component: Login (member module)
Affected file: /index.php?m=member&v=Login
Vulnerable parameter: forward

The vendor has not responded to disclosure attempts, and no patched version has been identified at the time of this writing. Users should assume that all versions up to 4.1.0 are vulnerable unless the vendor releases a fix or a community patch becomes available.

Impact

The direct technical impact of this open redirect vulnerability is classified as low. The vulnerability does not allow the attacker to read sensitive data, modify application data, or cause a denial of service on the target system. The integrity impact is rated as low because the attacker can cause the application to send a user to a destination that was not intended by the application’s design.

However, open redirect vulnerabilities often serve as a stepping stone for more serious attacks. The following scenarios illustrate the potential downstream impact:

Phishing campaigns: An attacker can craft a URL that begins with the legitimate WuzhiCMS domain, lending credibility to a phishing link. After the user logs in or visits the login page, they are silently redirected to a lookalike site that harvests credentials or distributes malware.
SSRF facilitation: In some architectures, an open redirect can be chained with server-side request forgery vulnerabilities to bypass URL allowlists on internal services.
OAuth token theft: If the application uses OAuth or similar token-based authentication flows, an open redirect on the callback URL can be used to intercept authorization codes or tokens.
Reputation damage: Users who are redirected to malicious sites from a trusted domain may lose trust in the application, and the domain may be flagged by security vendors or browser vendors as unsafe.

The low CVSS score reflects the fact that the vulnerability alone does not directly compromise the system, but the real-world risk depends heavily on how an attacker chains it with other techniques.

Exploitation Scenario

To exploit this vulnerability, an attacker would follow a sequence similar to the following:

The attacker identifies a WuzhiCMS installation running version 4.1.0 or earlier.
The attacker constructs a URL targeting the login page with a malicious forward parameter. For example: https://victim.example.com/index.php?m=member&v=Login&forward=https://attacker.example.com/phishing
The attacker distributes this URL to potential victims via email, social media, or other communication channels. The URL appears to point to the legitimate WuzhiCMS site, which increases the likelihood that a victim will trust and click it.
When the victim clicks the link, they are taken to the legitimate WuzhiCMS login page. The forward parameter is processed by the application and passed through the remove_xss() function, which does not block the external URL.
After the victim completes the login process (or in some implementations, immediately upon page load), the application redirects the victim to the URL specified in the forward parameter, which in this case is the attacker-controlled site.
The attacker’s site can then present a fake login page, deliver malware, or perform any other malicious action.

The key enabler in this scenario is that the remove_xss() function only targets XSS-related payloads. It does not inspect the scheme, host, or path of the URL to determine whether it is a safe internal destination. An attacker can use any valid URL format, including those with HTTPS schemes, IP addresses, or encoded characters, as long as the payload does not trigger the XSS filtering logic.

Detection and Mitigation

Detection

Organizations running WuzhiCMS can detect potential exploitation attempts by monitoring web server access logs for requests to /index.php?m=member&v=Login that include a forward parameter pointing to an external domain. The following indicators may signal an attack:

Requests where the forward parameter contains an absolute URL with a scheme such as http:// or https:// followed by a domain that does not match the application’s own domain.
Requests where the forward parameter contains protocol-relative URLs such as //attacker.example.com.
Requests where the forward parameter contains encoded URLs or URLs using alternative schemes such as javascript: or data: (though these may be partially caught by remove_xss()).
An unusual volume of login page requests originating from email referrers or social media platforms, which could indicate a phishing campaign using the redirect.

Security teams should also monitor for user reports of being redirected to unexpected sites after logging in, as this is a common symptom of open redirect exploitation.

Mitigation

Since the vendor has not responded to disclosure attempts and no official patch is available, organizations must implement their own mitigations. The following approaches are recommended:

Input validation on the forward parameter: Modify the application code to validate the forward parameter before using it in a redirect. Implement an allowlist of permitted internal paths and reject any URL that contains an absolute scheme or points to an external domain. For example, only allow values that start with a single forward slash (/) and do not start with //.
Server-side redirect validation: Add a server-side check that parses the redirect URL and compares its host against the application’s configured domain. If the hosts do not match, either reject the redirect or replace it with a safe default page.
Web Application Firewall (WAF) rules: Deploy a WAF rule that inspects requests to the login page and blocks or sanitizes forward parameters containing external URLs. The rule should look for patterns such as forward=http, forward=https, and forward=//.
Content Security Policy (CSP): While CSP does not directly prevent open redirects, a well-configured CSP can limit the impact of any downstream XSS or data exfiltration attacks that the redirect might facilitate.
User awareness training: Educate users to verify URLs before entering credentials and to be cautious of links received via email or messaging platforms, even if they appear to originate from a trusted domain.
Consider alternative CMS options: Given that the vendor has not responded to vulnerability reports, organizations should evaluate whether continued use of WuzhiCMS aligns with their security posture and risk tolerance. Migrating to a CMS with active security maintenance may be the most effective long-term mitigation.

Bug Bounty Angle

For security researchers and bug bounty hunters, CVE-2026-94102 highlights several important points about finding and reporting open redirect vulnerabilities:

Look beyond XSS sanitization: Many applications apply XSS filtering to user input but fail to consider other attack classes. When testing redirect parameters, check whether the sanitization function validates the URL destination, not just whether it strips script tags. The presence of remove_xss() in this case created a false sense of security.
Test all redirect parameters: Login pages, password reset pages, and post-action redirect parameters are common locations for open redirect flaws. Always test parameters with names like forward, redirect, next, return, url, and dest with external URLs.
Try multiple URL formats: If a simple https://external.com is blocked, try protocol-relative URLs (//external.com), URLs with backslashes (/\external.com), URLs with encoded characters, and URLs with alternative schemes.
Document the chaining potential: When reporting an open redirect, describe not only the direct impact but also how it could be chained with other vulnerabilities. This helps the program understand the full risk and may result in a higher bounty.
Be prepared for vendor non-response: As seen in this case, some vendors do not respond to vulnerability reports. Researchers should follow responsible disclosure timelines and, if necessary, publish advisories through platforms like GitHub or vulnerability databases to ensure the information reaches the community.

Open redirect vulnerabilities are often undervalued in bug bounty programs because their direct impact is limited. However, programs that understand the chaining potential and the role of open redirects in phishing campaigns may offer meaningful rewards. Researchers should review each program’s scope and impact guidelines before submitting.

Frequently Asked Questions

What is CVE-2026-94102?

CVE-2026-94102 is an open redirect vulnerability in WuzhiCMS up to version 4.1.0. It affects the Login component at /index.php?m=member&v=Login through manipulation of the forward parameter, which is only sanitized by remove_xss() and not validated against external URLs.

Has the vendor released a patch?

No. The vendor was contacted early during the disclosure process but did not respond. No official patch or fix has been identified at the time of this writing. Users must implement their own mitigations or consider migrating to an alternative CMS.

Is the exploit publicly available?

Yes. The advisory states that the exploit has been published and may be used. The exploit maturity is reflected in the CVSS vector with E:P, indicating proof-of-concept code exists.