WeGIA CVE-2025-67501

Exploitation requires an authenticated WeGIA session (the endpoint checks isset($_SESSION['usuario'])) AND the account must hold permission on resource id 22 (the matPat/materials-patrimony module) at an edit-level action, per the permission check in the pre-patch code. Once those hold, the id_categoria value supplied via $_REQUEST (populated through extract($_REQUEST)) is concatenated unsanitized into 'SELECT * FROM categoria_produto WHERE id_categoria_produto = $id_categoria', permitting arbitrary SQL. Limiting factors: affected only in WeGIA versions 3.5.4 and below (fixed in 3.5.5); no user interaction needed beyond the attacker's own authenticated request; the valid privileged account requirement is the primary barrier, so insider or compromised-credential threat models are most realistic.

This is a genuine but access-gated vulnerability. The signals partly conflict and should be reconciled rather than taken at face value. The vendor's CVSS 4.0 vector scores 9.4 (Critical) largely because it sets subsequent-system impact to High (SC:H/SI:H/SA:H) and privileges to High (PR:H); however, the committed source evidence shows the endpoint is reached only after an authenticated session check (isset($_SESSION['usuario'])) and a permission check on resource 22 at edit level, so exploitation requires a valid, privileged application account - this is NOT remote-unauthenticated despite AV:N. I assess the real-world severity closer to CVSS 3.1 8.8 (High) because the SQL injection compromises the application's own database (full confidentiality/integrity/availability of institutional data) but does not inherently pivot to other systems, making the vendor's subsequent-system H ratings look inflated. The EPSS score is low (0.51%, 42nd percentile), consistent with a niche product and an authentication prerequisite that limits mass automated exploitation. Public exploit code exists (GitHub Security Advisory GHSA-hj2x-qfm3-2869), but there is no CISA KEV listing and no evidence of active exploitation. Net: a real, patch-now issue for anyone running WeGIA, but not an internet-wide emergency - prioritization should weight the authenticated prerequisite and the product's small footprint against the high technical impact.

An authenticated WeGIA user who holds edit permission on the materials/patrimony (matPat) module sends a crafted request to /html/matPat/editar_categoria.php with a malicious id_categoria value; because the parameter is pulled via extract($_REQUEST) and concatenated directly into a SELECT against categoria_produto, the payload executes against the database. Public exploit code is available via the GitHub Security Advisory, lowering the skill needed to reproduce it, allowing the attacker to read, alter, or destroy institutional records in the application database.