Description

WeGIA is a web manager for charitable institutions. Prior to 3.8.6, the unauthenticated web/html/socio/sistema/cadastro_cobranca.php endpoint accepts POST input through extract($_REQUEST) and directly incorporates valor, valor_pago, id_pessoa, id_socio, and id_sociotipo into UPDATE, INSERT, and SELECT statements without prepared statements. A remote attacker can use the affected parameters to execute arbitrary SQL that reads or modifies WeGIA database content, including billing records and credential data. The same SQL access can delete or truncate tables, causing loss of application data. This issue is fixed in version 3.8.6.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.8",
  "pubDate": "2026-10-14T20:17:50.640Z",
  "pubdate": "2026-10-14T20:17:50.640Z",
  "executiveSummary": "WeGIA versions prior to 3.8.6 contain a critical SQL injection vulnerability within the web/html/socio/sistema/cadastro_cobranca.php endpoint.\nThe vulnerability arises from the insecure use of the extract($_REQUEST) PHP function, which registers external input as local variables, combined with the lack of prepared statements in database interactions.\nAn unauthenticated remote attacker can exploit this flaw to inject malicious SQL commands through the valor, valor_pago, id_pessoa, id_socio, and id_sociotipo parameters.\nSuccessful exploitation grants the attacker full control over database operations, including unauthorized data exfiltration, unauthorized modification of billing records, credential harvesting, and complete data loss through table truncation or deletion.\nGiven the nature of the application as a manager for charitable institutions, this represents a significant risk to the integrity and confidentiality of sensitive financial and personal data.\nThe vulnerability is reachable via the public web interface, requiring no authentication, which significantly lowers the barrier for exploitation.",
  "technicalDetails": "The root cause of this vulnerability is improper input sanitization and the dangerous use of PHP's extract() function on superglobal arrays. By calling extract($_REQUEST), the application dynamically creates local variables based on all keys present in the request body or URL query string.\nThis behavior allows an attacker to overwrite internal variables or introduce new ones that are subsequently used directly within database queries.\nThe affected endpoint, web/html/socio/sistema/cadastro_cobranca.php, processes input parameters—specifically valor, valor_pago, id_pessoa, id_socio, and id_sociotipo—and directly interpolates these values into SQL UPDATE, INSERT, and SELECT statements without the use of parameterized queries or prepared statements.\nBecause the application fails to distinguish between data and command logic, an attacker can supply crafted SQL payloads within these parameters to escape the intended query structure.\nFor example, an attacker can terminate an existing query with a closing quote and comment character, then inject arbitrary SQL commands using UNION-based techniques to exfiltrate data from other tables, or use stacked queries to execute administrative commands like DROP or TRUNCATE if the underlying database driver and user permissions allow.\nThe attack flow begins with the attacker sending a POST request to the target script containing malicious payloads within the vulnerable parameters. Because the application processes these requests without authentication, the server executes the injected SQL queries with the privileges of the database user configured for the web application.\nThe lack of prepared statements means that the database engine treats the injected SQL as executable code, leading to complete compromise of the database layer.\nPost-exploitation impact includes full unauthorized access to institutional billing records, membership sensitive information, and potentially application-level administrative credentials stored within the database.\nThis vulnerability is present in all versions prior to 3.8.6. Mitigation requires refactoring the code to remove the extract() call and implementing robust prepared statements using PDO or MySQLi to ensure that user input is never parsed as SQL commands."
}