CVE-2026-23722: Critical Reflected XSS Enables Silent Browser-Side Takeover in WeGIA

CVE ID: CVE-2026-23722
Vulnerability Type: Reflected Cross-Site Scripting (XSS)
Severity: Critical
CVSS v3.1 Score: 9.1
Attack Vector: Remote (via browser)
Authentication Required: No
User Interaction: Yes (victim must open a crafted link)
Exploitability: High
Exploit Availability: Publicly known
Affected Component: html/memorando/insere_despacho.php
Affected Parameter: id_memorando
Affected Product: WeGIA (Web Manager for Charitable Institutions)
Affected Versions: Versions prior to 3.6.2

Executive Summary

CVE-2026-23722 is a critical reflected XSS vulnerability in the WeGIA web application.
The issue occurs because user-controlled input from the URL is directly reflected back into a web page without proper validation or output encoding.

An attacker can craft a malicious link and trick a legitimate user into opening it. When that happens, the attacker’s JavaScript code executes inside the victim’s browser, but under the trusted WeGIA domain. This makes the attack especially dangerous because the browser treats the malicious script as if it came from the application itself.

Technical Root Cause

The vulnerable PHP script (insere_despacho.php) reads the id_memorando parameter from the HTTP GET request and outputs it back into the response page without sanitization.

Key technical issues include:

No strict input validation on id_memorando
No output encoding when reflecting user input into HTML or JavaScript context
Trusting client-supplied parameters without enforcing expected data type (for example, numeric-only)

Because of this, malicious input can break out of the intended context and inject executable JavaScript.

How the Vulnerability Can Be Exploited

This vulnerability is exploited through social engineering combined with a crafted URL:

An attacker prepares a specially crafted URL pointing to the vulnerable endpoint.
The URL includes malicious content embedded in the id_memorando parameter.
The attacker sends this link to a victim (email, chat, internal message, etc.).
When the victim opens the link, the browser loads the page.
The application reflects the malicious input directly into the page.
The browser executes the injected script as if it were legitimate site content.

This is a reflected attack, meaning:

The payload is not stored on the server.
Each victim must be individually tricked into clicking the malicious link.

Potential Impact

If successfully exploited, this vulnerability can lead to:

1. Session Hijacking

If session cookies are not fully protected, attacker-controlled JavaScript may attempt to steal session identifiers and reuse them.

2. Account Takeover

Using the victim’s authenticated browser session, attackers can perform actions as the victim without knowing their credentials.

3. Unauthorized Actions

Attackers can:

Submit forms
Modify records
Trigger workflows
Access internal features available to the victim

4. Credential Phishing

The attacker can inject fake login prompts or modify the page to trick users into entering sensitive data.

5. UI Manipulation and Defacement

Injected scripts can visually alter the page, hide content, or display misleading information.

MITRE / Security Classification Mapping

CWE-79: Improper Neutralization of Input During Web Page Generation (Cross-Site Scripting)
Attack Pattern: Reflected XSS
Security Control Failure: Input validation and output encoding

Proof of Concept (PoC) and Exploitation Availability

Educational and research-level proof-of-concept demonstrations exist publicly.
The PoC demonstrates how unvalidated input is reflected and executed in the browser.
Exploitation does not require authentication.
No special environment or advanced skills are required beyond basic web knowledge.

How to Detect Exploitation or Attack Attempts

Recommended Log Sources

To detect abuse or attempted exploitation, monitor:

Web server access logs (Apache / Nginx / IIS)
Reverse proxy or load balancer logs
Web Application Firewall (WAF) logs
SIEM event correlation logs
Application error or request logs

What to Look For in Logs

Focus on requests targeting:

/html/memorando/insere_despacho.php

Suspicious indicators include:

id_memorando values containing HTML tags
Encoded characters representing <, >, ", '
Repeated requests from different IPs using similar query patterns
Requests originating from external referrers or phishing domains
Sudden spikes in requests to the same endpoint

Detection Logic

Behavior-based indicators:

Input parameters not matching expected numeric format
Parameters containing scripting keywords or markup indicators
URL-encoded payload patterns attempting browser execution

WAF Detection Strategy:

Block or alert on script-like patterns in id_memorando
Enforce strict allow-listing (numeric-only if applicable)
Normalize and decode input before inspection

Temporary Mitigations

While patching is strongly recommended, temporary risk reduction steps include:

Apply WAF rules to restrict id_memorando to expected values
Reject requests containing HTML or script indicators
Enable aggressive logging on the vulnerable endpoint
Ensure session cookies use:
- HttpOnly
- Secure
- SameSite attributes
Educate users to avoid clicking untrusted internal links

These mitigations do not replace patching.

Permanent Fix

The issue is fully resolved in WeGIA version 3.6.2 by:

Proper input validation
Safe output encoding
Preventing raw user input from being reflected into executable contexts

✅ Official Patch / Upgrade Link

Upgrade to WeGIA 3.6.2:
https://github.com/LabRedesCefetRJ/WeGIA/security/advisories/GHSA-g7hh-6qj7-mcqf

Final Takeaway

CVE-2026-23722 represents a high-risk client-side attack vector that can be easily abused through social engineering. Because exploitation does not require authentication and can directly impact legitimate users, this vulnerability should be treated as urgent.

Immediate patching to version 3.6.2 is strongly advised.
Any delay increases the likelihood of credential theft, data manipulation, or user compromise.