Summary
WeGIA contains a SQL injection vulnerability in the product restoration function because a request parameter is reintroduced after sanitization and inserted into database statements. An authenticated user with access to the Material & Patrimônio module may extract sensitive records or alter institutional and inventory data.
WeGIA contains a SQL injection vulnerability in the product restoration function because a request parameter is reintroduced after sanitization and inserted into database statements. An authenticated user with access to the Material & Patrimônio module may extract sensitive records or alter institutional and inventory data.
Affected context
The vulnerability occurs in WeGIA deployments before version 3.8.6 when an authenticated user can access the Material & Patrimônio module and submit requests to the product restoration endpoint. The affected logic processes id_produto for SQL UPDATE operations involving product, inventory-output, and inventory-entry records.
The vulnerability occurs in WeGIA deployments before version 3.8.6 when an authenticated user can access the Material & Patrimônio module and submit requests to the product restoration endpoint. The affected logic processes id_produto for SQL UPDATE operations involving product, inventory-output, and inventory-entry records.
Exploit preconditions
- Attack surface: The web application's product restoration endpoint
- Required access: An authenticated account with access to the Material & Patrimônio module
- Trigger point: Submission of the id_produto request parameter
- Why exploitation is possible: A later extract($_REQUEST) operation can overwrite the value previously converted with intval(), allowing raw request data to reach SQL statements
- Attack surface: The web application's product restoration endpoint
- Required access: An authenticated account with access to the Material & Patrimônio module
- Trigger point: Submission of the id_produto request parameter
- Why exploitation is possible: A later extract($_REQUEST) operation can overwrite the value previously converted with intval(), allowing raw request data to reach SQL statements
Why this happens
The underlying flaw is an input-trust and variable-overwrite error that defeats an earlier sanitization step. Although id_produto is initially processed with intval(), a subsequent extract($_REQUEST) can replace the sanitized variable with attacker-controlled data before it is interpolated into SQL UPDATE statements. This behavior maps to CWE-89, SQL Injection, because untrusted input reaches database queries without reliable parameterization.
The underlying flaw is an input-trust and variable-overwrite error that defeats an earlier sanitization step. Although id_produto is initially processed with intval(), a subsequent extract($_REQUEST) can replace the sanitized variable with attacker-controlled data before it is interpolated into SQL UPDATE statements. This behavior maps to CWE-89, SQL Injection, because untrusted input reaches database queries without reliable parameterization.
Potential impact
- An attacker may read sensitive database records
- An attacker could modify institutional data
- Inventory quantities and product records may be altered
- Database integrity and application availability may be affected
- Compromised data could support further attacks against the institution
- An attacker may read sensitive database records
- An attacker could modify institutional data
- Inventory quantities and product records may be altered
- Database integrity and application availability may be affected
- Compromised data could support further attacks against the institution
General mitigation guidance
Mitigation generally focuses on ensuring that request data cannot overwrite
validated variables and that database operations do not concatenate
untrusted input.
Common defensive patterns include:
- Use parameterized queries or prepared statements for all database operations
- Avoid dynamic variable creation from request data, including unrestricted extract operations
- Apply allowlist validation and type checks at the point of use
- Keep database accounts limited to the operations required by each application component
- Centralize input handling and preserve validated values throughout the request lifecycle
- Return generic database errors and protect sensitive records through authorization checks
Mitigation generally focuses on ensuring that request data cannot overwrite
validated variables and that database operations do not concatenate
untrusted input.
Common defensive patterns include:
- Use parameterized queries or prepared statements for all database operations
- Avoid dynamic variable creation from request data, including unrestricted extract operations
- Apply allowlist validation and type checks at the point of use
- Keep database accounts limited to the operations required by each application component
- Centralize input handling and preserve validated values throughout the request lifecycle
- Return generic database errors and protect sensitive records through authorization checks
How teams detect issues like this
Organizations can look for this class of issue through:
- Static analysis rules for SQL string interpolation and concatenation
- Detection of extract($_REQUEST), dynamic variable assignment, and request-driven variable overwrites
- Code review checks verifying that validation occurs immediately before use
- Database access policies requiring prepared statements
- Runtime monitoring for unusual UPDATE statements, authorization failures, and unexpected record changes
- Automated security testing that submits unexpected types and boundary values to database-backed endpoints
Organizations can look for this class of issue through:
- Static analysis rules for SQL string interpolation and concatenation
- Detection of extract($_REQUEST), dynamic variable assignment, and request-driven variable overwrites
- Code review checks verifying that validation occurs immediately before use
- Database access policies requiring prepared statements
- Runtime monitoring for unusual UPDATE statements, authorization failures, and unexpected record changes
- Automated security testing that submits unexpected types and boundary values to database-backed endpoints
