CVE-2026-35475: WeGIA Open Redirect Vulnerability

CVE-2026-35475 Overview

CVE-2026-35475 is an Open Redirect vulnerability affecting WeGIA, a web manager application designed for charitable institutions. Prior to version 3.6.9, the application fails to properly validate the redirect parameter, which is taken directly from $_GET without URL validation or whitelist checks. This unsanitized input is then used verbatim in a header("Location: ...") call, allowing attackers to redirect users to arbitrary external URLs.

Critical Impact

Attackers can craft malicious URLs that appear to originate from a trusted WeGIA instance but redirect users to phishing sites, malware distribution pages, or credential harvesting portals, potentially compromising charitable institution staff and donors.

Affected Products

• WeGIA Web Manager versions prior to 3.6.9
• WeGIA charitable institution management platforms without the security patch

Discovery Timeline

• 2026-04-06 - CVE CVE-2026-35475 published to NVD
• 2026-04-07 - Last updated in NVD database

Technical Details for CVE-2026-35475

Vulnerability Analysis

This vulnerability falls under CWE-601 (URL Redirection to Untrusted Site, commonly known as Open Redirect). The core issue stems from the application's direct use of user-supplied input in HTTP redirect headers without any form of validation.

When a web application accepts a URL parameter and uses it to redirect users without proper validation, attackers can leverage this trust relationship to direct victims to malicious websites. Since the initial link appears to come from a legitimate WeGIA installation (likely hosted on a trusted domain), users are more likely to trust and follow the redirect.

The attack requires user interaction—specifically, a victim must click on a crafted malicious link. However, once clicked, the redirect happens automatically through the HTTP Location header, making it nearly invisible to the end user.

Root Cause

The root cause is the absence of URL validation or whitelist checking on the redirect parameter before its use in the HTTP Location header. The application directly reads the parameter from $_GET superglobal and passes it to header() without sanitization. Proper implementation would involve validating that the redirect URL either:

• Points to a domain within an approved whitelist
• Uses relative paths only (preventing external redirects)
• Matches an allowed URL pattern

Attack Vector

The vulnerability is exploitable over the network and requires user interaction. An attacker would craft a URL pointing to a legitimate WeGIA instance with a malicious redirect parameter value. This URL could be distributed via:

• Phishing emails targeting charitable institution staff or donors
• Social media posts or messages
• Compromised websites linking to the malicious URL
• QR codes in printed materials

When a victim clicks the link, they are initially directed to the trusted WeGIA server, which then immediately redirects them to the attacker-controlled destination. This technique is commonly used to bypass email security filters and user suspicion, as the initial domain appears legitimate.

The vulnerability mechanism involves the PHP header() function being called with an unvalidated Location value. For technical details on the specific implementation, see the GitHub Security Advisory.

Detection Methods for CVE-2026-35475

Indicators of Compromise

• HTTP requests to WeGIA instances containing redirect parameters pointing to external domains
• Web server access logs showing redirects to suspicious or unknown URLs
• User reports of being redirected to unexpected websites after clicking WeGIA links
• Phishing campaigns using legitimate WeGIA URLs with malicious redirect parameters

Detection Strategies

• Monitor web application logs for redirect parameters containing external URLs or suspicious domains
• Implement web application firewall (WAF) rules to flag or block requests with external URLs in redirect parameters
• Deploy URL reputation checking on outbound redirect targets
• Analyze email gateway logs for phishing attempts using WeGIA URLs with redirect parameters

Monitoring Recommendations

• Enable detailed logging of all HTTP redirect responses from WeGIA instances
• Set up alerts for unusual patterns of redirect parameter usage
• Monitor for spike in 302/301 redirects to external domains
• Track referrer headers to identify potential phishing link sources

How to Mitigate CVE-2026-35475

Immediate Actions Required

• Upgrade WeGIA to version 3.6.9 or later immediately
• Review web server logs for evidence of exploitation attempts
• Alert users about potential phishing campaigns leveraging this vulnerability
• Consider implementing additional WAF rules while patching is in progress

Patch Information

The vulnerability has been fixed in WeGIA version 3.6.9. Organizations should update to this version or later to remediate the vulnerability. The patch implements proper URL validation to prevent arbitrary redirects to external domains.

For detailed information about the fix, refer to the GitHub Security Advisory.

Workarounds

• Implement a web application firewall (WAF) rule to block or sanitize requests with external URLs in the redirect parameter
• Use a reverse proxy to validate redirect parameter values before they reach the WeGIA application
• Restrict access to affected endpoints via IP allowlisting until patching is complete
• Educate users to verify URLs carefully before clicking, especially in emails

# Example WAF rule concept (ModSecurity)
# Block redirect parameters containing external URLs
SecRule ARGS:redirect "@rx ^https?://" \
    "id:1001,phase:1,deny,status:403,msg:'Blocked external redirect attempt'"