CVE-2026-33133
SQL Injection in WeGIA loadBackupDB() Allows Admin Takeover
Publication date: 2026-03-20
Last updated on: 2026-03-20
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| wegia | wegia | 3.6.5 |
| wegia | wegia | 3.6.6 |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-89 | The product constructs all or part of an SQL command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended SQL command when it is sent to a downstream component. Without sufficient removal or quoting of SQL syntax in user-controllable inputs, the generated SQL query can cause those inputs to be interpreted as SQL instead of ordinary user data. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
CVE-2026-33133 is a high-severity vulnerability in the WeGIA web manager software for charitable institutions, specifically affecting versions 3.6.5 and 3.6.6. The vulnerability exists in the loadBackupDB() function, which imports SQL files from uploaded backup archives without validating their content.
An attacker can exploit this by crafting a malicious backup archive containing arbitrary SQL statements. When this archive is uploaded and processed, the SQL commands execute with full database privileges, allowing the attacker to create rogue administrator accounts, modify existing passwords, or perform any database operation.
The root cause is the lack of input validation and sanitization of the SQL files before execution. This issue was introduced in commit 370104c and was patched in version 3.6.7.
How can this vulnerability impact me? :
This vulnerability can have severe impacts because it allows an attacker to execute arbitrary SQL commands on the WeGIA database with full privileges.
- Creation of rogue administrator accounts, giving attackers full control over the application.
- Modification of existing user passwords, potentially locking out legitimate users.
- Execution of any database operation, including destructive commands like DROP or ALTER, which can lead to data loss or corruption.
Overall, this can compromise the confidentiality, integrity, and availability of the data managed by WeGIA.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
I don't know
How can this vulnerability be detected on my network or system? Can you suggest some commands?
[{'type': 'paragraph', 'content': 'This vulnerability can be detected by inspecting backup restore operations and uploaded backup archives for the presence of unauthorized or arbitrary SQL statements. Specifically, look for SQL files within backup archives that contain suspicious commands such as INSERT statements creating new administrator accounts or other unexpected database modifications.'}, {'type': 'paragraph', 'content': 'Suggested commands include extracting and reviewing the contents of backup archives before restoration. For example, you can extract the .tar.gz backup archive and search for suspicious SQL statements using commands like:'}, {'type': 'list_item', 'content': 'tar -xzf backup_archive.tar.gz -C /tmp/backup_contents'}, {'type': 'list_item', 'content': 'grep -iE "insert|update|delete|drop|alter" /tmp/backup_contents/*.sql'}, {'type': 'paragraph', 'content': 'Additionally, monitoring database logs for unexpected SQL commands executed during backup restore operations can help detect exploitation attempts.'}] [2]
What immediate steps should I take to mitigate this vulnerability?
Immediate mitigation steps include upgrading WeGIA to version 3.6.7 or later, where the vulnerability has been patched.
If upgrading is not immediately possible, implement strict validation of SQL file contents before restoring backups. This includes enforcing a whitelist of allowed SQL statement types and verifying that SQL files conform to the expected backup schema.
Use backup integrity verification mechanisms such as signing backup SQL files with an OpenSSL private key and requiring a corresponding signature file during restore operations to prevent tampered or forged backups from being imported.
Perform restore operations within database transactions that support rollback to avoid partial or malicious changes if suspicious SQL is detected.
Also, review and restrict permissions of the database user used during backup restore to minimize potential damage from arbitrary SQL execution.