CVE-2025-6699: Wegia Employee Registration XSS Vulnerability

CVE-2025-6699 Overview

CVE-2025-6699 is a cross-site scripting (XSS) vulnerability in LabRedesCefetRJ WeGIA version 3.4.0, an open-source web application for charity management. The flaw resides in /html/funcionario/cadastro_funcionario.php, part of the Cadastro de Funcionário (Employee Registration) component. Attackers can manipulate the Nome and Sobrenome parameters to inject arbitrary script content that executes in the browser of any user viewing the affected page. The issue is remotely exploitable and has been publicly disclosed. It is tracked separately from CVE-2025-23030, which affected a different injection point in the same product.

Critical Impact
Authenticated attackers can inject JavaScript into the employee registration form, leading to session token theft, forced actions on behalf of administrators, and phishing content delivery within trusted application context.

Affected Products

LabRedesCefetRJ WeGIA 3.4.0
Component: Cadastro de Funcionário (/html/funcionario/cadastro_funcionario.php)
Vulnerable parameters: Nome and Sobrenome

Discovery Timeline

2025-06-26 - CVE-2025-6699 published to NVD with public proof-of-concept disclosure
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2025-6699

Vulnerability Analysis

The vulnerability is a reflected/stored cross-site scripting flaw classified under [CWE-79]. The cadastro_funcionario.php endpoint accepts employee first name (Nome) and last name (Sobrenome) values without properly encoding or sanitizing them before rendering the data back in HTML output. An attacker with low-privilege access to the registration form can submit a payload containing JavaScript, which then executes when the page renders.

Exploitation requires user interaction, meaning an administrator or another user must load a page that renders the injected content. Once triggered, the payload runs under the origin of the WeGIA application and inherits access to session cookies, CSRF tokens, and DOM data available to that user.

According to the disclosure, the vendor was contacted before public release but did not respond. No official patch is currently listed in vendor advisories.

Root Cause

The root cause is missing output encoding of user-supplied data. The application takes name fields directly from form input and echoes them into the HTML response without applying context-appropriate escaping such as htmlspecialchars() in PHP. Any HTML metacharacters submitted through Nome or Sobrenome are treated as markup rather than text.

Attack Vector

The attack is delivered over the network against an authenticated WeGIA instance. An attacker with an account submits a malicious payload through the employee registration form. When another user views the rendered employee data, the injected script executes in their browser. Typical payloads target session hijacking through document.cookie exfiltration, DOM manipulation to alter displayed data, or forced HTTP requests that abuse the victim's session against internal endpoints.

A public proof of concept is documented in the PoC repository on GitHub and in VulDB entry #313965.

Detection Methods for CVE-2025-6699

Indicators of Compromise

HTTP POST requests to /html/funcionario/cadastro_funcionario.php containing HTML tags, <script>, javascript:, or event handlers such as onerror= in the Nome or Sobrenome parameters
Employee records in the WeGIA database whose name fields contain angle brackets, quotes, or script fragments
Outbound browser requests from staff workstations to unfamiliar domains immediately after accessing employee listing pages
Anomalous session activity, such as administrator accounts performing actions from unexpected user-agents shortly after viewing registration data

Detection Strategies

Deploy web application firewall rules that inspect form fields on the cadastro_funcionario.php endpoint for XSS signatures
Review application access logs for POST requests to the employee registration URL containing URL-encoded %3Cscript or %3Cimg patterns
Run database queries against the employees table to identify existing records with HTML markup in name columns
Correlate authenticated user sessions against browser telemetry to identify unexpected script execution or cross-origin requests

Monitoring Recommendations

Ingest WeGIA web server logs and monitor for injection patterns in name-related parameters
Alert on repeated form submissions from the same user containing metacharacters, which suggests payload tuning
Track sudden changes in administrator session behavior after loading employee-management pages

How to Mitigate CVE-2025-6699

Immediate Actions Required

Restrict access to the WeGIA application to trusted, authenticated users only, ideally behind a VPN or IP allowlist
Audit existing employee records and remove entries containing HTML or script content in name fields
Enable a strict Content Security Policy (CSP) that blocks inline scripts and disallows untrusted script sources
Review web server logs for prior exploitation attempts against /html/funcionario/cadastro_funcionario.php

Patch Information

At the time of publication, the WeGIA vendor had not issued an official patch or public advisory in response to the disclosure. Administrators should monitor the WeGIA project repository for future security releases and apply updates as they become available.

Workarounds

Apply a virtual patch at the WAF layer to sanitize or reject payloads containing <, >, or script tokens in the Nome and Sobrenome parameters
Modify cadastro_funcionario.php locally to wrap all output of user-supplied name fields with htmlspecialchars($value, ENT_QUOTES, 'UTF-8')
Enforce a CSP header such as Content-Security-Policy: default-src 'self'; script-src 'self' to limit the impact of injected scripts
Rotate administrator session tokens and credentials if exploitation is suspected

bash

# Example Apache configuration snippet to add a restrictive CSP header
<IfModule mod_headers.c>
    Header always set Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'self'"
    Header always set X-Content-Type-Options "nosniff"
    Header always set X-Frame-Options "SAMEORIGIN"
</IfModule>