Summary
WebVella ERP through version 1.8.8 contains a SQL injection vulnerability in its EQL query API. An authenticated user may submit crafted WHERE-clause text literals to alter SQL construction and potentially read entities they are not authorized to access, including user and role records.
WebVella ERP through version 1.8.8 contains a SQL injection vulnerability in its EQL query API. An authenticated user may submit crafted WHERE-clause text literals to alter SQL construction and potentially read entities they are not authorized to access, including user and role records.
Affected context
The issue occurs in the EQL query API when authenticated requests contain WHERE-clause text literals that are incorporated into SQL statements by the EqlBuilder. Risk is present where input reaches the API without effective parameterization or equivalent escaping, particularly when the resulting query can access sensitive application entities.
The issue occurs in the EQL query API when authenticated requests contain WHERE-clause text literals that are incorporated into SQL statements by the EqlBuilder. Risk is present where input reaches the API without effective parameterization or equivalent escaping, particularly when the resulting query can access sensitive application entities.
Exploit preconditions
- Attack surface: The EQL query API at the versioned
/api/v3/{locale}/eqlendpoint - Required access: A valid authenticated account capable of submitting EQL queries
- Trigger point: Processing a POST request containing a crafted single-quoted WHERE-clause literal
- Why exploitation is possible: User-controlled text is interpolated into SQL construction without sufficient separation between data and query syntax
- Attack surface: The EQL query API at the versioned
/api/v3/{locale}/eqlendpoint - Required access: A valid authenticated account capable of submitting EQL queries
- Trigger point: Processing a POST request containing a crafted single-quoted WHERE-clause literal
- Why exploitation is possible: User-controlled text is interpolated into SQL construction without sufficient separation between data and query syntax
Why this happens
The vulnerability results from constructing SQL statements by interpolating untrusted EQL text literals into a WHERE clause. When delimiters and query syntax are not safely handled through parameterized queries or an equivalent trusted query builder, attacker-controlled input can change the intended SQL statement. This behavior maps to CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection').
The vulnerability results from constructing SQL statements by interpolating untrusted EQL text literals into a WHERE clause. When delimiters and query syntax are not safely handled through parameterized queries or an equivalent trusted query builder, attacker-controlled input can change the intended SQL statement. This behavior maps to CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection').
Potential impact
- An attacker may read unauthorized application entities.
- Sensitive user and role records could be exposed.
- Query results may be altered or expanded beyond the caller's intended scope.
- Depending on database permissions and reachable functionality, broader data compromise could occur.
- An attacker may read unauthorized application entities.
- Sensitive user and role records could be exposed.
- Query results may be altered or expanded beyond the caller's intended scope.
- Depending on database permissions and reachable functionality, broader data compromise could occur.
General mitigation guidance
Mitigation generally focuses on ensuring that user-controlled query values remain data rather than executable SQL.
Common defensive patterns include:
- Use parameterized queries or prepared statements for all dynamically supplied values.
- Prefer allowlisted, structured query builders that separate operators, fields, and values.
- Apply strict schema and type validation to EQL expressions before query generation.
- Reduce database privileges for the application account and restrict access to sensitive entities.
- Enforce authorization checks independently of query filters so filtering cannot bypass entity-level permissions.
- Avoid relying solely on escaping or client-side validation as the primary protection.
Mitigation generally focuses on ensuring that user-controlled query values remain data rather than executable SQL.
Common defensive patterns include:
- Use parameterized queries or prepared statements for all dynamically supplied values.
- Prefer allowlisted, structured query builders that separate operators, fields, and values.
- Apply strict schema and type validation to EQL expressions before query generation.
- Reduce database privileges for the application account and restrict access to sensitive entities.
- Enforce authorization checks independently of query filters so filtering cannot bypass entity-level permissions.
- Avoid relying solely on escaping or client-side validation as the primary protection.
How teams detect issues like this
Organizations commonly detect this class of issue through:
- Static analysis rules identifying string concatenation or interpolation in SQL construction.
- Code review checks for query builders that accept raw WHERE-clause fragments or untrusted literals.
- Tests using boundary characters and structured negative cases to verify parameterization and authorization behavior.
- API monitoring for repeated malformed query expressions, unusual filtering patterns, or access to sensitive entity types.
- Policy enforcement requiring prepared statements, approved data-access libraries, and server-side authorization checks.
Automated code review and application security testing tools may help identify unsafe query construction patterns.
Organizations commonly detect this class of issue through:
- Static analysis rules identifying string concatenation or interpolation in SQL construction.
- Code review checks for query builders that accept raw WHERE-clause fragments or untrusted literals.
- Tests using boundary characters and structured negative cases to verify parameterization and authorization behavior.
- API monitoring for repeated malformed query expressions, unusual filtering patterns, or access to sensitive entity types.
- Policy enforcement requiring prepared statements, approved data-access libraries, and server-side authorization checks.
Automated code review and application security testing tools may help identify unsafe query construction patterns.
