CVE-2025-22133 is a critical unrestricted file upload flaw (CVSS 9.9) in WeGIA, a web manager for charitable institutions, before version 3.2.8. An upload endpoint accepts files such as .phar that the server can then run. Upgrade to 3.2.8 and check upload folders for files you did not expect.
What's affected
- Product: WeGIA, a web manager for charitable institutions
- Affected versions: before 3.2.8
- Fixed version: 3.2.8
- Vulnerable endpoint:
controla_xlsx.phpunder the socio system controller folder - CVSS: 9.9 (Critical), vector
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H - Published: 2025-01-07
The vector needs low privileges, so an account on the system is expected, and it rates the scope as changed with high impact on confidentiality, integrity and availability. The project's advisory describes the impact as access to the server, running commands as the web server user and exposure of configuration files, logs and user data. The CISA Known Exploited Vulnerabilities flag is false for this CVE, and none of the pages I read report active exploitation.
How to check if you're exposed
Start with the version, then look for signs of misuse.
- Find the WeGIA version in the application or its source tree. Anything below 3.2.8 is affected.
- Search the web root for script files that should not be there, especially in upload and import folders.
# PHP archive and script files modified in the last 90 days under the web root (adjust the path)
find /var/www -type f \( -name "*.phar" -o -name "*.php" \) -mtime -90 2>/dev/null | head -50
- Compare the results with your deployed code, for example against a clean checkout of your version. Files that exist on the server and not in the checkout need review.
- Check web server logs for requests to the upload endpoint from addresses or accounts you do not recognize.
Our free in-browser dependency scan can also report on the libraries in the project, which is useful once you have patched the application itself.
What to do now
- Upgrade WeGIA to 3.2.8 or later, after taking a backup.
- Search upload and import folders for .phar and .php files you did not deploy, and investigate before removing anything.
- If you find a stray script file, treat the host as compromised. Rotate database and application credentials and review other changes.
- Configure the web server so uploaded files cannot execute, and restrict allowed extensions in the application.
- Limit which users can reach import features, and review accounts with low privileges that were created recently.
Why it matters
The record lists CWE-434, unrestricted upload of a file of a dangerous type, and CWE-94, code injection. The endpoint that handles spreadsheet imports accepts a file without checking its type well enough. If the server runs PHP archives from the upload location, an uploaded file becomes running code.
This is a heavy outcome for a tool that holds records about donors, beneficiaries and staff. The score of 9.9 reflects the scope change: code running as the web server can touch much more than the import feature. A fixed release exists, so the most useful work is upgrading and then checking whether anything unexpected was left behind in the time the old version was exposed. The demo below shows how a pull request gate can stop this class of change reaching production code.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Which version fixes it?
WeGIA 3.2.8, according to the record and the project's advisory.
How do I know if I was hit?
Look for script or .phar files in upload and import folders that are not part of your deployment, and review logs for the upload endpoint.
Sources
Last reviewed: 19 October 2026.
