Summary
Weaver E-cology contains an unauthenticated SQL injection vulnerability in the document listing API when a specific request mode processes attacker-controlled date fields.
A remote attacker may inject database queries and retrieve database information through related API responses without authenticating.
Weaver E-cology contains an unauthenticated SQL injection vulnerability in the document listing API when a specific request mode processes attacker-controlled date fields.
A remote attacker may inject database queries and retrieve database information through related API responses without authenticating.
Affected context
The vulnerability affects Weaver E-cology 8.0, 9.0, and 10.0 deployments before the stated 10.76 release. It occurs in the /api/doc/out/more/list endpoint when the elementmore parameter is used with srcType=2 and values from doc_datefrom or doc_dateto reach database query construction without adequate parameterization.
The vulnerability affects Weaver E-cology 8.0, 9.0, and 10.0 deployments before the stated 10.76 release. It occurs in the /api/doc/out/more/list endpoint when the elementmore parameter is used with srcType=2 and values from doc_datefrom or doc_dateto reach database query construction without adequate parameterization.
Exploit preconditions
- Attack surface: Network-accessible Weaver E-cology document-listing API
- Required access: No authentication may be required
- Trigger point: Processing of
elementmorerequests withsrcType=2 - Attacker-controlled input:
doc_datefromanddoc_datetofields - Observation channel: Related responses from
/api/ec/dev/table/counts - Why exploitation is possible: Input may influence SQL query construction without sufficient separation between data and query syntax
- Attack surface: Network-accessible Weaver E-cology document-listing API
- Required access: No authentication may be required
- Trigger point: Processing of
elementmorerequests withsrcType=2 - Attacker-controlled input:
doc_datefromanddoc_datetofields - Observation channel: Related responses from
/api/ec/dev/table/counts - Why exploitation is possible: Input may influence SQL query construction without sufficient separation between data and query syntax
Why this happens
The underlying bug is SQL injection caused by incorporating externally supplied values into database queries without consistently using parameterized statements or equivalent safe query-building mechanisms.
This maps to CWE-89: Improper Neutralization of Special Elements used in an SQL Command, where input is interpreted as part of SQL syntax rather than treated strictly as data.
The underlying bug is SQL injection caused by incorporating externally supplied values into database queries without consistently using parameterized statements or equivalent safe query-building mechanisms.
This maps to CWE-89: Improper Neutralization of Special Elements used in an SQL Command, where input is interpreted as part of SQL syntax rather than treated strictly as data.
Potential impact
- An unauthenticated attacker may read database information
- Database metadata or application records could be disclosed
- Query behavior could be altered, potentially affecting data integrity
- Sensitive credentials or configuration values may be exposed if stored in accessible tables
- The vulnerability could support further compromise of connected application services
- An unauthenticated attacker may read database information
- Database metadata or application records could be disclosed
- Query behavior could be altered, potentially affecting data integrity
- Sensitive credentials or configuration values may be exposed if stored in accessible tables
- The vulnerability could support further compromise of connected application services
General mitigation guidance
Mitigation generally centers on removing SQL interpretation from request-controlled values and reducing the privileges available to application database accounts.
Defensive patterns include:
- Use parameterized queries or prepared statements for all database operations
- Apply allowlisted validation and strict type handling to date fields and request modes
- Avoid dynamically concatenating request values into SQL fragments
- Return only the minimum data required by each endpoint
- Restrict database accounts to the operations and tables required by the application
- Apply authentication and authorization controls to diagnostic or data-counting endpoints where appropriate
- Avoid exposing detailed database errors or query results through API responses
Mitigation generally centers on removing SQL interpretation from request-controlled values and reducing the privileges available to application database accounts.
Defensive patterns include:
- Use parameterized queries or prepared statements for all database operations
- Apply allowlisted validation and strict type handling to date fields and request modes
- Avoid dynamically concatenating request values into SQL fragments
- Return only the minimum data required by each endpoint
- Restrict database accounts to the operations and tables required by the application
- Apply authentication and authorization controls to diagnostic or data-counting endpoints where appropriate
- Avoid exposing detailed database errors or query results through API responses
How teams detect issues like this
Detection approaches can include:
- Static analysis rules that identify string concatenation or interpolation in SQL construction
- Code review checks for request parameters passed to database APIs without bind variables
- Dynamic testing of date and filter parameters using benign metacharacter and type-boundary cases
- Web application firewall or API gateway policies that monitor suspicious SQL syntax in relevant parameters
- Database audit logging for unexpected queries originating from the application account
- Alerting on unauthenticated access patterns involving
/api/doc/out/more/listand/api/ec/dev/table/counts
Automated code review and security testing tools may help identify unsafe query-building patterns during development.
Detection approaches can include:
- Static analysis rules that identify string concatenation or interpolation in SQL construction
- Code review checks for request parameters passed to database APIs without bind variables
- Dynamic testing of date and filter parameters using benign metacharacter and type-boundary cases
- Web application firewall or API gateway policies that monitor suspicious SQL syntax in relevant parameters
- Database audit logging for unexpected queries originating from the application account
- Alerting on unauthenticated access patterns involving
/api/doc/out/more/listand/api/ec/dev/table/counts
Automated code review and security testing tools may help identify unsafe query-building patterns during development.
