CVE-2026-55681 in WeGIA
Summary
by MITRE • 10/14/2026
WeGIA is a web manager for charitable institutions. Prior to 3.8.6, an authenticated user with access to the Material & Patrimônio module can submit id_produto to web/html/matPat/restaurar_produto_desocultar.php, where a second extract($_REQUEST) overwrites the value previously sanitized by intval(). The raw value is interpolated into UPDATE statements for the produto, isaida, and ientrada tables. An attacker can execute arbitrary SQL to extract sensitive database records or modify institutional and inventory data. This issue is fixed in version 3.8.6.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/14/2026
The vulnerability identified in WeGIA versions prior to 3.8.6 represents a critical failure in input validation logic within the Material & Patrimônio module, specifically affecting authenticated users who possess access rights to this section of the application. The core technical flaw stems from an improper handling of user-supplied data during the restoration process for products that have been hidden or removed from active inventory views. When a user submits a request containing the id_produto parameter to the endpoint web/html/matPat/restaurar_produto_desocultar.php, the application attempts to sanitize this input by applying the intval() function, which is designed to cast the value as an integer and thereby neutralize any malicious characters or SQL syntax. However, immediately following this sanitization step, the script executes a second operation involving extract($_REQUEST). This PHP language construct automatically creates variables from all existing GET, POST, and COOKIE data using their names as variable names. Because the request contains id_produto, the extract function overwrites the previously sanitized integer value with the raw, unsanitized string provided by the attacker.
This specific sequence of operations effectively bypasses the initial security control intended to prevent injection attacks. By allowing the raw input to overwrite the validated variable before it is used in database queries, the application fails to enforce type safety or data integrity constraints on critical identifiers. The compromised id_produto value is then directly interpolated into UPDATE statements targeting multiple tables within the underlying database schema, including produto, isaida, and ientrada. These tables likely store sensitive institutional information such as asset details, inventory levels, financial records related to outgoing goods (saida), and incoming goods (entrada). Consequently, an attacker can manipulate these SQL queries to perform unauthorized data modifications or extract confidential information that should not be accessible through this specific module interface.
The operational impact of this vulnerability is severe due to its potential for both data exfiltration and integrity compromise. An authenticated attacker could exploit the arbitrary SQL execution capability to dump sensitive database records, potentially exposing personal identifiable information of donors, detailed financial histories, or proprietary inventory management data belonging to the charitable institution. Furthermore, by modifying values in the produto, isaida, and ientrada tables, an attacker could alter asset statuses, falsify inventory counts, or manipulate financial records related to goods movement. This undermines the trustworthiness of the organization's operational data and could lead to significant reputational damage and regulatory non-compliance depending on the nature of the exposed data. The vulnerability is classified under CWE-89 for Improper Neutralization of Special Elements used in an SQL Command, highlighting the failure to properly sanitize user input before its use in dynamic database queries.
From a tactical perspective, this exploitation aligns with ATT&CK techniques related to Data Injection and potentially Data Exfiltration via Application Layer Protocol if the attacker leverages blind or error-based extraction methods. The attack vector is classified as remote but requires authentication, placing it within the context of privilege escalation through application logic flaws rather than network-level exploits. To mitigate this vulnerability, organizations must upgrade WeGIA to version 3.8.6 or later where the code path has been corrected to prevent the overwrite of sanitized variables by raw request data. In environments where immediate patching is not feasible, defensive measures should include implementing strict input validation that rejects any non-integer characters for ID fields at the application boundary rather than relying on post-sanitization overwrites. Additionally, employing parameterized queries or prepared statements would ensure that user-supplied values are treated strictly as data and never as executable SQL code, thereby neutralizing injection risks regardless of subsequent variable manipulation within the script logic.