Safeguard
Vulnerability Analysis•

CVE-2025-30361: Critical Auth Bypass in WeGIA

CVE-2025-30361 is a critical (9.8) authentication bypass in WeGIA before 3.2.6 that lets anyone reset any password. Upgrade to 3.2.6 or later.

Safeguard Security Team
3 min read

CVE-2025-30361 is a critical (CVSS 9.8) authentication bypass in WeGIA, a web manager for charitable institutions. Before version 3.2.6, a user's password could be changed without verifying the old one, including admin accounts. Version 3.2.6 fixes it, so upgrade and then reset administrator passwords as a precaution.

What's affected

The record and the GitHub advisory list WeGIA versions before 3.2.6 as affected. WeGIA is a web manager for charitable institutions, and it is installed through Composer according to the advisory.

Version 3.2.6 contains the fix.

The record does not flag the CVE as known exploited, and the CVE is not in the CISA KEV catalog at the time of writing.

How to check if you're exposed

Find the version of WeGIA you run.

  1. Check the version shown in the application, or the release or tag you deployed from.
  2. For Composer based installs, run composer show on the package to see the version.
  3. Search your web server access logs for requests to the affected path and unusual parameter values, and check database logs for errors.

If you manage donor or beneficiary data in WeGIA, assume that the database is a target and check backups.

What to do now

  1. Upgrade WeGIA to 3.2.6 or later, or to the latest release.
  2. Force a password reset for administrator accounts and review all accounts for unexpected changes.
  3. Check logs for password change requests that you cannot explain.
  4. Restrict the application to trusted networks if it does not need to be public.
  5. Turn on multi factor authentication if your deployment supports it, and review who has admin rights.

Why it matters

The record maps the flaw to CWE-287 (Improper Authentication). According to the advisory, the password change handler did not verify the old password and did not check that the caller was allowed to change the account in question. A request could therefore set a new password for any user, including administrators.

This is an account takeover bug. The attacker does not need to guess or steal a password, because the application will set one. Once an admin account is taken over, everything the application stores becomes available. For a charity system, that can mean personal data about donors, staff and the people the charity serves.

The fix is to require the current password and to check that the caller owns the account or has the right role. Treat any password change endpoint as a sensitive function and test it for both rules.

Quick check

Does an attacker need to log in first?

The advisory says unauthorized attackers could change passwords, so assume no login is needed.

What should I do after upgrading?

Reset admin passwords and review accounts, since a takeover before the upgrade would not be undone by the patch.

Sources

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

We email you a link to confirm, and only then add you to the list. Unsubscribe in one click. Privacy

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.