#postgres

An unknown threat actor has been observed publishing typosquat packages to the Python Package Index (PyPI) repository for nearly six months with an aim to deliver malware capable of gaining persistence, stealing sensitive data, and accessing cryptocurrency wallets for financial gain. The 27 packages, which masqueraded as popular legitimate Python libraries, attracted thousands of downloads,

Debian Linux Security Advisory 5554-1 - Several vulnerabilities have been discovered in the PostgreSQL database system.

Debian Linux Security Advisory 5553-1 - Several vulnerabilities have been discovered in the PostgreSQL database system.

### Summary The handling of named transaction savepoints in all database implementations is vulnerable to [SQL Injection](https://owasp.org/www-community/attacks/SQL_Injection) as user provided input is passed directly to `connection.execute(...)` via f-strings. ### Details An excerpt of the Postgres savepoint handling: ```python async def savepoint(self, name: t.Optional[str] = None) -> Savepoint: name = name or f"savepoint_{self.get_savepoint_id()}" await self.connection.execute(f"SAVEPOINT {name}") return Savepoint(name=name, transaction=self) ``` In this example, we can see user input is directly passed to `connection.execute` without being properly escaped. All implementations of savepoints and savepoint methods directly pass this `name` parameter to `connection.execute` and are vulnerable to this. A non-exhaustive list can be found below: - Postgres - - [One](https://github.com/piccolo-orm/piccolo/blob/master/piccolo/engine/postgres.py#L239) - - [...

Piccolo is an object-relational mapping and query builder which supports asyncio. Prior to version 1.1.1, the handling of named transaction `savepoints` in all database implementations is vulnerable to SQL Injection via f-strings. While the likelihood of an end developer exposing a `savepoints` `name` parameter to a user is highly unlikely, it would not be unheard of. If a malicious user was able to abuse this functionality they would have essentially direct access to the database and the ability to modify data to the level of permissions associated with the database user. A non exhaustive list of actions possible based on database permissions is: Read all data stored in the database, including usernames and password hashes; insert arbitrary data into the database, including modifying existing records; and gain a shell on the underlying server. Version 1.1.1 fixes this issue.

An issue was discovered in Spiceworks Help Desk Server before 1.3.3. A Blind Boolean SQL injection vulnerability within the order_by_for_ticket function in app/models/reporting/database_query.rb allows an authenticated attacker to execute arbitrary SQL commands via the sort parameter. This can be leveraged to leak local files from the host system, leading to remote code execution (RCE) through deserialization of malicious data.

Blind SQL injection in api_version parameter in Tyk Gateway version 5.0.3 allows attacker to access and dump the database via a crafted SQL query.

When the provided datastore URI is malformed (e.g. by having a password which contains `:`) the full URI (including the provided password) is printed, so that the password is shown in the logs. Example output: ``` terminated with errors error="unable to create migration driver for postgres: parse \"postgres://spicedb:<PASSWORD IN PLAINTEXT>": invalid port \"<PASSWORD IN PLAINTEXT>\" after host" ```

SpiceDB is an open source, Google Zanzibar-inspired database for creating and managing security-critical application permissions. Prior to version 1.27.0, when the provided datastore URI is malformed (e.g. by having a password which contains `:`) the full URI (including the provided password) is printed, so that the password is shown in the logs. Version 1.27.0 patches this issue.

Upload profile either through API or user interface in Chef Automate prior to and including version 4.10.29 using InSpec check command with maliciously crafted profile allows remote code execution.