Summary
Dolibarr's Third Party company update functionality builds SQL statements using local tax values without adequate sanitization or numeric conversion. An authenticated user with permission to create or edit Third Parties may be able to read sensitive database information or alter third-party records.
Dolibarr's Third Party company update functionality builds SQL statements using local tax values without adequate sanitization or numeric conversion. An authenticated user with permission to create or edit Third Parties may be able to read sensitive database information or alter third-party records.
Affected context
The issue occurs in Dolibarr's Third Party company update functionality when submitted lt1 or lt2 POST parameters are incorporated into an SQL UPDATE statement. It is relevant when those values are not safely converted or handled as data before being used in the query.
The issue occurs in Dolibarr's Third Party company update functionality when submitted lt1 or lt2 POST parameters are incorporated into an SQL UPDATE statement. It is relevant when those values are not safely converted or handled as data before being used in the query.
Exploit preconditions
- Attack surface: Third Party company update functionality
- Required access: An authenticated account with Third Party create or edit permission
- Trigger point: Submission of
lt1orlt2POST parameters during a company update - Why exploitation is possible: The corresponding local tax values are concatenated into SQL without appropriate sanitization or numeric conversion
- Attack surface: Third Party company update functionality
- Required access: An authenticated account with Third Party create or edit permission
- Trigger point: Submission of
lt1orlt2POST parameters during a company update - Why exploitation is possible: The corresponding local tax values are concatenated into SQL without appropriate sanitization or numeric conversion
Why this happens
The application constructs an SQL statement by concatenating request-derived local tax values into the query. When input is treated as SQL syntax rather than data, a crafted value may change the meaning of the statement. This is CWE-89: SQL Injection.
The application constructs an SQL statement by concatenating request-derived local tax values into the query. When input is treated as SQL syntax rather than data, a crafted value may change the meaning of the statement. This is CWE-89: SQL Injection.
Potential impact
- An attacker may read sensitive database information, including password hashes, API keys, and business data.
- An attacker could modify third-party records.
- Exposure of stored credentials or business information may enable further compromise.
- An attacker may read sensitive database information, including password hashes, API keys, and business data.
- An attacker could modify third-party records.
- Exposure of stored credentials or business information may enable further compromise.
General mitigation guidance
Common defensive patterns for this class of issue include:
- Use parameterized queries or prepared statements so input values remain data.
- Convert values to the expected numeric type and reject inputs that do not meet the defined constraints.
- Apply server-side validation at the point where request data enters the application.
- Restrict database accounts and application permissions to the minimum required.
- Avoid returning sensitive database details in responses or logs.
Common defensive patterns for this class of issue include:
- Use parameterized queries or prepared statements so input values remain data.
- Convert values to the expected numeric type and reject inputs that do not meet the defined constraints.
- Apply server-side validation at the point where request data enters the application.
- Restrict database accounts and application permissions to the minimum required.
- Avoid returning sensitive database details in responses or logs.
How teams detect issues like this
- Use static analysis to identify SQL statements built through concatenation with request-derived values.
- Review update handlers for local tax fields and other numeric parameters, checking that values are bound as query parameters.
- Apply code-review and CI policies that flag unsafe query construction and require validation of externally supplied data.
- Monitor for unusual database errors or unexpected reads and updates associated with Third Party operations.
- Use static analysis to identify SQL statements built through concatenation with request-derived values.
- Review update handlers for local tax fields and other numeric parameters, checking that values are bound as query parameters.
- Apply code-review and CI policies that flag unsafe query construction and require validation of externally supplied data.
- Monitor for unusual database errors or unexpected reads and updates associated with Third Party operations.
