CVE-2025-61604 in WeGIAinfo

Summary

by MITRE • 10/02/2025

WeGIA is an open source web manager with a focus on charitable institutions. Versions 3.4.12 and below contain a Cross-Site Request Forgery (CSRF) vulnerability. The delete operation for the Almoxarifado entity is exposed via HTTP GET without CSRF protection, allowing a third-party site to trigger the action using the victim’s authenticated session. This issue is fixed in version 3.5.0.

Be aware that VulDB is the high quality source for vulnerability data.

Analysis

by VulDB Data Team • 10/07/2025

The CVE-2025-61604 vulnerability affects WeGIA version 3.4.12 and earlier, representing a critical cross-site request forgery flaw that undermines the security posture of this open-source web management platform designed for charitable institutions. This vulnerability specifically targets the Almoxarifado entity deletion functionality, which exposes a dangerous HTTP GET endpoint without proper cross-site request forgery protection mechanisms. The flaw enables attackers to craft malicious web pages or links that, when visited by an authenticated user, automatically execute the delete operation on the target system. This represents a fundamental failure in web application security architecture where state-changing operations should never be exposed via GET requests, as they can be triggered automatically by web browsers and are inherently vulnerable to CSRF attacks.

The technical exploitation of this vulnerability leverages the inherent characteristics of HTTP GET requests and the trust model between web browsers and web applications. When a victim user is authenticated to the WeGIA system, any malicious website can construct a request that triggers the Almoxarifado deletion endpoint, effectively allowing unauthorized deletion of inventory records without the victim's knowledge or consent. This vulnerability directly violates security principles outlined in the OWASP Top Ten and specifically aligns with CWE-352, which defines Cross-Site Request Forgery as a weakness where the application does not properly validate that requests originate from the legitimate user. The impact is particularly concerning for charitable institutions that rely on accurate inventory management systems, as unauthorized deletions could result in data loss, operational disruption, and potential financial discrepancies in their inventory tracking.

The operational consequences of this vulnerability extend beyond simple data loss, as it creates a persistent security risk for organizations using WeGIA for charitable operations. The vulnerability's exploitation requires no sophisticated attack techniques beyond basic web development skills, making it accessible to threat actors with minimal technical expertise. This poses significant risks to charitable institutions that may not have robust security monitoring in place, potentially leading to unauthorized modifications of inventory records, disruption of charitable operations, and compromise of sensitive operational data. The vulnerability's presence in versions 3.4.12 and below indicates a regression or oversight in the security design of the application, as proper CSRF protection mechanisms should be implemented for all state-changing operations regardless of the application's target audience or operational context.

Organizations using WeGIA should immediately implement mitigations including upgrading to version 3.5.0 where the vulnerability has been addressed, and implementing additional protective measures such as validating request origins, implementing anti-CSRF tokens for all state-changing operations, and ensuring that destructive operations are not exposed via GET requests. The fix implemented in version 3.5.0 should include proper CSRF token validation mechanisms and adherence to security best practices that align with the ATT&CK framework's mitigation strategies for web application attacks. Security teams should also consider implementing web application firewalls and monitoring for suspicious request patterns that may indicate CSRF attack attempts, while ensuring that all application developers follow secure coding practices that prevent similar vulnerabilities from emerging in future versions of the software.

Responsible

GitHub M

Reservation

09/26/2025

Disclosure

10/02/2025

Moderation

accepted

CPE

ready

EPSS

0.00025

KEV

no

Activities

very low

Sources

Do you want to use VulDB in your project?

Use the official API to access entries easily!