#sql

Developers using non-ASCII-compatible encodings in conjunction with the MySQL PDO driver of PHP may be vulnerable to SQL injection attacks. Developers using ASCII-compatible encodings like UTF8 or latin1 are not affected by this PHP issue, which is described in more detail here: http://bugs.php.net/bug.php?id=47802 The PHP Group included a feature in PHP 5.3.6+ that allows any character set information to be passed as part of the DSN in PDO to allow both the database as well as the C-level driver to be aware of which charset is in use which is of special importance when PDO's quoting mechanisms are utilized, which Zend Framework also relies on.

The `Zend\Db` component in Zend Framework 2 provides platform abstraction, which is used in particular for SQL abstraction. Two methods defined in the platform interface, `quoteValue()` and `quoteValueList()`, allow users to manually quote values for creating SQL statements; these are in turn consumed by aspects of the SQL abstraction platform, including `Zend\Db\Sql\Sql::getSqlStringForSqlObject()`, and the `getSqlString()` method provided in a number of classes in the Zend\Db\Sql namespace. While these methods are primarily intended for debugging and logging purposes, developers can use them to produce SQL that is then passed to the driver to execute. Due to a flaw in how the `quoteValue()` and `quoteValueList()` methods were written, this can lead to potential SQL injection. The offending code is located in any of the `Zend\Db\Adapter\Platform*` objects, particularly the quoteValue() and `quoteValueList()` methods. These methods did not take into account most of the possible escap...

jSQL Injection is a lightweight application used to find database information from a distant server. jSQL Injection is also part of the official penetration testing distribution Kali Linux and is included in various other distributions like Pentest Box, Parrot Security OS, ArchStrike and BlackArch Linux. This is the source code release.

Online Pizza Ordering System version 1.0 suffers from a remote SQL injection vulnerability.

An SQL Injection vulnerability exists in the berriai/litellm repository, specifically within the `/global/spend/logs` endpoint. The vulnerability arises due to improper neutralization of special elements used in an SQL command. The affected code constructs an SQL query by concatenating an unvalidated `api_key` parameter directly into the query, making it susceptible to SQL Injection if the `api_key` contains malicious data. This issue affects the latest version of the repository. Successful exploitation of this vulnerability could lead to unauthorized access, data manipulation, exposure of confidential information, and denial of service (DoS).

BerriAI's litellm, in its latest version, is vulnerable to arbitrary file deletion due to improper input validation on the `/audio/transcriptions` endpoint. An attacker can exploit this vulnerability by sending a specially crafted request that includes a file path to the server, which then deletes the specified file without proper authorization or validation. This vulnerability is present in the code where `os.remove(file.filename)` is used to delete a file, allowing any user to delete critical files on the server such as SSH keys, SQLite databases, or configuration files.

A blind SQL injection vulnerability exists in the berriai/litellm application, specifically within the '/team/update' process. The vulnerability arises due to the improper handling of the 'user_id' parameter in the raw SQL query used for deleting users. An attacker can exploit this vulnerability by injecting malicious SQL commands through the 'user_id' parameter, leading to potential unauthorized access to sensitive information such as API keys, user information, and tokens stored in the database. The affected version is 1.27.14.

Boelter Blue System Management version 1.3 suffers from a remote SQL injection vulnerability.

A worried researcher has created a tool to demonstrate exactly how much of a security backdoor Microsoft is creating with Recall.

If you had used entity security and wanted to secure entities not just based on the user's role, but on some property of the user (like the company he belongs to), entity security did not work properly together with the doctrine query cache. This could lead to other users re-using SQL queries from the cache which were built for other users; and thus users could see entities which were not destined for them.