Skip to main content
CVE Vulnerability Database
Vulnerability Database/CVE-2025-22614

CVE-2025-22614: Wegia Stored XSS Vulnerability

CVE-2025-22614 is a stored XSS vulnerability in Wegia that allows attackers to inject malicious scripts into user input fields. This article covers the technical details, affected versions, impact, and mitigation.

Published:

CVE-2025-22614 Overview

CVE-2025-22614 is a stored Cross-Site Scripting (XSS) vulnerability in WeGIA, an open source web manager focused on Portuguese-language charitable institutions. The flaw resides in the dependente_editarInfoPessoal.php endpoint, which fails to validate or sanitize the nome and SobrenomeForm parameters. Attackers can inject malicious JavaScript that is persisted server-side and executed in the browser of any user who loads the affected page. The issue is tracked as [CWE-79] and has been resolved in WeGIA version 3.2.6.

Critical Impact

Persistent script execution against authenticated users of the WeGIA management interface, enabling session theft, credential harvesting, and unauthorized actions in the victim's context.

Affected Products

  • WeGIA (wegia:wegia) versions prior to 3.2.6
  • html/funcionario/dependente_editarInfoPessoal.php endpoint
  • Deployments managed by charitable institutions using the WeGIA web manager

Discovery Timeline

  • 2025-01-13 - CVE-2025-22614 published to the National Vulnerability Database
  • 2026-06-17 - Last updated in NVD database

Technical Details for CVE-2025-22614

Vulnerability Analysis

The vulnerability is a stored XSS flaw in the dependent-editing workflow of WeGIA. The dependente_editarInfoPessoal.php script accepts POST parameters including nome and sobrenomeForm and writes them to the database without input sanitization or output encoding. When any user later opens the page rendering that dependent record, the injected payload executes in the browser under the WeGIA origin.

Because the payload is persisted server-side, the attacker does not need to social-engineer a specific victim. Any authenticated user who views the tampered record triggers execution. The attack requires only network access to the application and a form submission, though the CVSS vector notes user interaction (UI:A) to trigger the stored payload.

Root Cause

The root cause is missing input validation and output encoding on user-supplied form fields. The pre-patch code assigned $_POST['nome'] and $_POST['sobrenomeForm'] directly to variables used in a database UPDATE statement. No filter_input call, HTML encoding, or context-aware escaping was applied before storage or rendering, satisfying the conditions for [CWE-79] Improper Neutralization of Input During Web Page Generation.

Attack Vector

An attacker with access to the dependent-edit form submits a POST request containing a JavaScript payload in the nome or SobrenomeForm fields. The server stores the payload in the pessoa table. When an administrator or another user opens the affected profile view, the browser parses and executes the script, potentially exfiltrating session cookies, issuing CSRF-style requests, or defacing the interface.

php
// Patch from html/funcionario/dependente_editarInfoPessoal.php
// Before: unsanitized assignment
// $id = $_GET['id_pessoa'];
// $nome = $_POST['nome'];
// $sobrenome = $_POST['sobrenomeForm'];
// $sexo = $_POST['gender'];
// $telefone = $_POST['telefone'];
// $data_nascimento = $_POST['nascimento'];
// $nome_mae = $_POST['nome_mae'];
// $nome_pai = $_POST['nome_pai'];

// After: filter_input with sanitization filters
$id = trim(filter_input(INPUT_GET, 'id_pessoa', FILTER_SANITIZE_NUMBER_INT));
$nome = trim(filter_input(INPUT_POST, 'nome', FILTER_SANITIZE_STRING));
$sobrenome = trim(filter_input(INPUT_POST, 'sobrenomeForm', FILTER_SANITIZE_STRING));
$sexo = trim(filter_input(INPUT_POST, 'gender', FILTER_SANITIZE_STRING));
$telefone = trim(filter_input(INPUT_POST, 'telefone', FILTER_SANITIZE_STRING));
$data_nascimento = trim(filter_input(INPUT_POST, 'nascimento', FILTER_SANITIZE_STRING));
$nome_mae = trim(filter_input(INPUT_POST, 'nome_mae', FILTER_SANITIZE_STRING));
$nome_pai = trim(filter_input(INPUT_POST, 'nome_pai', FILTER_SANITIZE_STRING));

Source: WeGIA commit 8eb446f

Detection Methods for CVE-2025-22614

Indicators of Compromise

  • Database rows in the pessoa table where nome or sobrenome fields contain HTML tags such as <script>, <img>, <svg>, or JavaScript URI schemes.
  • Web server access logs showing POST requests to dependente_editarInfoPessoal.php with URL-encoded angle brackets or javascript: in the body.
  • Unexpected outbound requests from user browsers when viewing dependent profile pages, indicating cookie or token exfiltration.

Detection Strategies

  • Deploy a Web Application Firewall (WAF) rule to flag XSS payload patterns on POST requests to /html/funcionario/dependente_editarInfoPessoal.php.
  • Run periodic database queries to search stored nome, sobrenomeForm, and related fields for HTML or script markup.
  • Enable Content Security Policy (CSP) violation reporting to identify inline script execution attempts on WeGIA pages.

Monitoring Recommendations

  • Alert on repeated form submissions containing suspicious characters (<, >, ", onerror=, onload=) from a single session.
  • Monitor authenticated administrator sessions for anomalous request patterns immediately after viewing dependent records.
  • Correlate WeGIA application logs with proxy and browser telemetry to identify script-triggered navigation or data exfiltration.

How to Mitigate CVE-2025-22614

Immediate Actions Required

  • Upgrade WeGIA to version 3.2.6 or later, which introduces filter_input sanitization on the affected parameters.
  • Audit the pessoa table and related storage for records containing HTML or JavaScript markup and remediate any tainted rows.
  • Rotate session tokens and credentials for administrators who accessed dependent profiles before patching.

Patch Information

The fix is delivered in commit 8eb446f, released in WeGIA 3.2.6. See the GitHub Security Advisory GHSA-wr55-2952-79rh for vendor-confirmed details.

Workarounds

  • No official workarounds exist; the vendor advisory instructs all users to upgrade.
  • As a compensating control, place WeGIA behind a WAF with XSS signature enforcement until patching is complete.
  • Apply a strict Content Security Policy that disallows inline script execution to reduce the impact of any residual stored payloads.
bash
# Verify WeGIA version and pull the patched release
git -C /var/www/WeGIA fetch --tags
git -C /var/www/WeGIA checkout 3.2.6

# Example WAF (ModSecurity) rule to block script tags in the vulnerable parameters
SecRule ARGS:nome|ARGS:sobrenomeForm "@rx (?i)(<script|onerror=|onload=|javascript:)" \
  "id:1002261,phase:2,deny,status:403,msg:'WeGIA CVE-2025-22614 XSS payload blocked'"

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Default Legacy - Prefooter | Experience the World’s Most Advanced Cybersecurity Platform

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.