CVE-2024-57032 is a critical severity access control flaw (CVSS 9.8) in WeGIA before 3.2.0. The application does not validate the old password in controle/control.php, so the password can be changed with any value in the senha_antiga field. Move to the newest release and reset passwords.
What's affected
WeGIA is an open source web manager for charitable institutions, developed by the university extension programme at Cefet/RJ in Brazil, according to the project's website. The record says WeGIA before 3.2.0 has incorrect access control in controle/control.php. The application does not validate the value of the old password. A password can be changed by placing any value in the senha_antiga field, which is the field for the old password in Portuguese.
The record lists two weakness classes, CWE-284 and CWE-863. No vendor advisory is linked, only the researcher's write-up, so the fixed version is not confirmed beyond the range in the record. Release 3.2.0 is outside that range, but check the project for newer releases.
How to check if you're exposed
WeGIA is a PHP web application, so there is no package manager entry to query. Check these instead.
- The version shown in the application, or the release tag or commit you deployed from.
- Whether the install is reachable from the internet. Search your DNS and reverse proxy configuration for the hostname.
- The permissions of the database account the application uses. If it can read every table and write to many, the damage from one injection is wider.
- The web server access log, for requests to the affected file with strange or very long parameter values.
For this flaw, also look at your authentication logs for password changes that the account owner did not request, especially for administrator accounts.
What to do now
- Find every WeGIA installation your organization runs and note its version.
- Upgrade to the newest WeGIA release from the project's GitHub repository, not only 3.2.0.
- After upgrading, force a password reset for administrator accounts and any others you cannot vouch for.
- Review accounts for new users or changed email addresses that you did not authorize.
- Restrict access to the application to trusted networks while you check for misuse.
- Add a check in your own review process that a password change needs proof of the current password or a verified reset link.
Why it matters
The record lists CWE-284, improper access control, and CWE-863, incorrect authorization. In plain terms, the application's password change step skips a check that every password change should make. A change form that asks for the old password is meant to prove that the person at the keyboard knows the current secret. If the server never compares the old value with the stored one, the field is decoration.
The impact depends on how someone reaches the form. The vector in the record says no privileges are required, which would mean an attacker can reach this function without logging in. The write-up is the place to confirm the exact precondition. Either way, a password change without proof of the old password is a direct route to taking over any account, including administrators. The KEV flag in the record is false.
Quick check
What does the senha_antiga field do?
It is the old password field on the password change form. The record says the application does not validate its value.
Should I reset passwords after upgrading?
Yes for administrators and any account you cannot vouch for, since the flaw lets a password change succeed without the old one.
Sources
Last reviewed: 19 October 2026.
