#sql

Vulnerabilities in Dolibarr ERP - CRM that affect version 9.0.1 and allow SQL injection. These vulnerabilities could allow a remote attacker to send a specially crafted SQL query to the system and retrieve all the information stored in the database through the parameters sortorder y sortfield in /dolibarr/admin/dict.php.

Red Hat Security Advisory 2024-3313-03 - An update for postgresql-jdbc is now available for Red Hat Enterprise Linux 8.8 Extended Update Support.

Ivanti on Tuesday rolled out fixes to address multiple critical security flaws in Endpoint Manager (EPM) that could be exploited to achieve remote code execution under certain circumstances. Six of the 10 vulnerabilities – from CVE-2024-29822 through CVE-2024-29827 (CVSS scores: 9.6) – relate to SQL injection flaws that allow an unauthenticated attacker within the same network to

Chat Bot version 1.0 suffers from a remote SQL injection vulnerability.

PyMySQL through 1.1.0 allows SQL injection if used with untrusted JSON input because keys are not escaped by `escape_dict`.

There is a risk of an IV collision using the awskms or aesgcm provider. NIST SP 800-38D section 8.3 states that it is unsafe to encrypt more than 2^32 plaintexts under the same key when using a random IV. The limit could easily be reached given the use case of database column encryption. Ciphertexts are likely to be persisted and stored together. IV collision could enable an attacker with access to the ciphertexts to decrypt all messages encrypted with the affected key. The aesgcm provider cannot be fixed without a breaking change, so users should not encrypt more than 2^32 values with any key. The awskms package can be fixed without a breaking change by switching to a counter-based IV.

The limit() query method is susceptible to catastrophic SQL injection with MySQL. For example, given a model User for a table users: ``` UserQuery::create()->limit('1;DROP TABLE users')->find(); ``` This will drop the users table! The cause appears to be a lack of integer casting of the limit input in either Criteria::setLimit() or in DBMySQL::applyLimit(). The code comments there seem to imply that casting was avoided due to overflow issues with 32-bit integers. This is surprising behavior since one of the primary purposes of an ORM is to prevent basic SQL injection. This affects all versions of Propel: 1.x, 2.x, and 3.

The limit() query method is susceptible to catastrophic SQL injection with MySQL. For example, given a model User for a table users: ``` UserQuery::create()->limit('1;DROP TABLE users')->find(); ``` This will drop the users table! The cause appears to be a lack of integer casting of the limit input in either Propel\Runtime\ActiveQuery\Criteria::setLimit() or in Propel\Runtime\Adapter\Pdo\MysqlAdapter::applyLimit(). The code comments there seem to imply that casting was avoided due to overflow issues with 32-bit integers. This is surprising behavior since one of the primary purposes of an ORM is to prevent basic SQL injection. This affects all versions of Propel: 1.x, 2.x, and 3.

Tenant Limited version 1.0 suffers from a remote SQL injection vulnerability.

WordPress XStore theme version 9.3.8 suffers from a remote SQL injection vulnerability.