CVE-2025-52474 is a critical SQL injection (CVSS 9.8) in WeGIA, a web manager for charitable institutions, before version 3.4.2. The id parameter of /WeGIA/controle/control.php reaches a database query without safe handling, and the project fixed it in WeGIA 3.4.2. Upgrade, then review web logs and database access.
What's affected
The CVE record says WeGIA versions before 3.4.2 are affected and that the issue is patched in 3.4.2. The vulnerable endpoint is /WeGIA/controle/control.php, through its id parameter. The weakness is CWE-89 (SQL injection).
The CVSS vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H: network reachable, low complexity, no privileges, no user interaction and high impact on all three security properties. The record says an attacker could manipulate SQL queries and read sensitive database information, such as table names and sensitive data. The CISA Known Exploited Vulnerabilities flag is false for this CVE, and the record does not say it is exploited in the wild.
The advisory is published by the project on GitHub as GHSA-rwvh-2gfh-wmcm, with a fix commit linked from the record.
How to check if you're exposed
Find the version of every WeGIA install. If you deploy from a git checkout, read the tag or release:
git describe --tags
git log -1 --format=%H
If you installed from a release archive, compare the release name or the project changelog with 3.4.2. The version is the quickest test, because the record says everything before 3.4.2 is affected.
Next, check exposure. WeGIA manages records for charitable institutions, so it usually holds personal details of beneficiaries, donors and staff. Check whether the /WeGIA/ path answers from outside your network, and review web server logs for requests to control.php with an unusual id value, such as one containing quote marks or SQL keywords. Review the database server log for errors from malformed queries too.
What to do now
- Find every WeGIA deployment and read its version.
- Upgrade to 3.4.2 or later following the project instructions, and take a database backup first.
- If you cannot upgrade today, restrict access to the application to a VPN or a short list of addresses.
- Review access logs for
control.phprequests with oddidvalues since the application went online. - Rotate the passwords of application users and the database account if you find signs of suspicious activity.
- Give the database account only the permissions the application needs.
Why it matters
SQL injection is the case where text from a request is placed straight into a database query. The id value in a URL seems harmless, which is why it is a common place for the bug. The cure is well known, bound parameters in prepared statements, so the data can never change the command.
Charity and community software is often run by small teams with limited security time, yet it holds sensitive personal data. That gap is where this CVE bites. A 9.8 score for an endpoint that needs no login means any reachable install should be updated promptly.
The fix being public also matters. A published commit shows exactly what changed, so unpatched installs become easier to target as time passes.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Which version fixes CVE-2025-52474?
WeGIA 3.4.2 fixes it, according to the CVE record and the project advisory. Everything before 3.4.2 is affected.
Do I need to do more than upgrade?
Upgrade first, then check logs for odd requests and limit database privileges. If the app was internet facing and unpatched for some time, treat stored credentials as possibly exposed.
Sources
- Safeguard Gold record: https://gold.safeguard.sh/vulnerability/CVE-2025-52474
- WeGIA GitHub security advisory GHSA-rwvh-2gfh-wmcm, fetched (the page content was mostly site navigation, so the facts here come from the CVE record text that mirrors it): https://github.com/LabRedesCefetRJ/WeGIA/security/advisories/GHSA-rwvh-2gfh-wmcm
Last reviewed: 18 October 2026.
