In the current development version of Eclipse aeriOS, for which no official release has yet been published, the Identity Manager (IdM) deployment included insecure default configurations and credentials for security-sensitive services.

The Helm chart exposed the Keycloak service and its PostgreSQL backing database through Kubernetes NodePort services by default, while the Docker Compose deployment similarly exposed PostgreSQL on all network interfaces. The deployment included fixed default credentials for the Keycloak administrator and PostgreSQL database user, and the previous Helm chart configuration did not provide adequate secret management for these credentials. In addition, predefined application users with known credentials were provided for development and testing without sufficiently warning operators against their use in production environments.

An attacker able to reach the exposed services could use the published default credentials to obtain administrative access to the Identity Manager or direct access to its database. This could allow unauthorized access to or modification of identity-management data, including users, roles, client credentials, sessions, and cryptographic material, and could enable the creation of privileged identities or tokens accepted by other aeriOS components.

The issue has been addressed by generating a random Keycloak administrator password by default, managing Keycloak and PostgreSQL credentials through Kubernetes Secrets, and restricting PostgreSQL to an internal service in both the Helm chart and Docker Compose deployment. OpenLDAP is also restricted to an internal service. The predefined users intended for development and testing are retained, but the documentation now explicitly warns that their default credentials must not be used in production and that these users should be removed or their credentials changed after installation.

PostgreSQL before 9.0.19, 9.1.x before 9.1.15, 9.2.x before 9.2.10, 9.3.x before 9.3.6, and 9.4.x before 9.4.1 does not properly handle errors while reading a protocol message, which allows remote attackers to conduct SQL injection attacks via crafted binary data in a parameter and causing an error, which triggers the loss of synchronization and part of the protocol message to be treated as a new message, as demonstrated by causing a timeout or query cancellation.

The snprintf implementation in PostgreSQL before 9.0.20, 9.1.x before 9.1.16, 9.2.x before 9.2.11, 9.3.x before 9.3.7, and 9.4.x before 9.4.2 does not properly handle system-call errors, which allows attackers to obtain sensitive information or have other unspecified impact via unknown vectors, as demonstrated by an out-of-memory error.

Postgresql Windows installer before versions 11.5, 10.10, 9.6.15, 9.5.19, 9.4.24 is vulnerable via bundled OpenSSL executing code from unprotected directory.

PostgreSQL before 9.1.20, 9.2.x before 9.2.15, 9.3.x before 9.3.11, 9.4.x before 9.4.6, and 9.5.x before 9.5.1 does not properly restrict access to unspecified custom configuration settings (GUCS) for PL/Java, which allows attackers to gain privileges via unspecified vectors.

The tochar function in PostgreSQL before 9.0.19, 9.1.x before 9.1.15, 9.2.x before 9.2.10, 9.3.x before 9.3.6, and 9.4.x before 9.4.1 allows remote authenticated users to cause a denial of service (crash) or possibly execute arbitrary code via a (1) large number of digits when processing a numeric formatting template, which triggers a buffer over-read, or (2) crafted timestamp formatting template, which triggers a buffer overflow.

Stack-based buffer overflow in the printf function implementations in PostgreSQL before 9.0.19, 9.1.x before 9.1.15, 9.2.x before 9.2.10, 9.3.x before 9.3.6, and 9.4.x before 9.4.1, when running on a Windows system, allows remote authenticated users to cause a denial of service (crash) and possibly execute arbitrary code via a floating point number with a large precision, as demonstrated by using the tochar function.

Multiple buffer overflows in contrib/pgcrypto in PostgreSQL before 9.0.19, 9.1.x before 9.1.15, 9.2.x before 9.2.10, 9.3.x before 9.3.6, and 9.4.x before 9.4.1 allow remote authenticated users to cause a denial of service (crash) and possibly execute arbitrary code via unspecified vectors.

A vulnerability was found in postgresql versions 11.x prior to 11.3. The Windows installer for BigSQL-supplied PostgreSQL does not lock down the ACL of the binary installation directory or the ACL of the data directory; it keeps the inherited ACL. In the default configuration, an attacker having both an unprivileged Windows account and an unprivileged PostgreSQL account can cause the PostgreSQL service account to execute arbitrary code. An attacker having only the unprivileged Windows account can read arbitrary data directory files, essentially bypassing database-imposed read access limitations. An attacker having only the unprivileged Windows account can also delete certain data directory files.

aiven-extras is a PostgreSQL extension. Versions prior to 1.1.9 contain a privilege escalation vulnerability, allowing elevation to superuser inside PostgreSQL databases that use the aiven-extras package. The vulnerability leverages missing schema qualifiers on privileged functions called by the aiven-extras extension. A low privileged user can create objects that collide with existing function names, which will then be executed instead. Exploiting this vulnerability could allow a low privileged user to acquire superuser privileges, which would allow full, unrestricted access to all data and database functions. And could lead to arbitrary code execution or data access on the underlying host as the postgres user. The issue has been patched as of version 1.1.9.

PostgreSQL 9.2.x before 9.2.4, 9.1.x before 9.1.9, 9.0.x before 9.0.13, and 8.4.x before 8.4.17, when using OpenSSL, generates insufficiently random numbers, which might allow remote authenticated users to have an unspecified impact via vectors related to the "contrib/pgcrypto functions."

It was discovered that certain SQL statements containing CASE/WHEN commands could crash the PostgreSQL server, or disclose a few bytes of server memory, potentially leading to arbitrary code execution.

Last updated 24 July 2024

A vulnerability was found in postgresql versions 11.x prior to 11.3. The Windows installer for EnterpriseDB-supplied PostgreSQL does not lock down the ACL of the binary installation directory or the ACL of the data directory; it keeps the inherited ACL. In the default configuration, this allows a local attacker to read arbitrary data directory files, essentially bypassing database-imposed read access limitations. In plausible non-default configurations, an attacker having both an unprivileged Windows account and an unprivileged PostgreSQL account can cause the PostgreSQL service account to execute arbitrary code.

PostgreSQL before 9.1.20, 9.2.x before 9.2.15, 9.3.x before 9.3.11, 9.4.x before 9.4.6, and 9.5.x before 9.5.1 allows remote attackers to cause a denial of service (infinite loop or buffer overflow and crash) via a large Unicode character range in a regular expression.

contrib/pgcrypto in PostgreSQL before 9.0.20, 9.1.x before 9.1.16, 9.2.x before 9.2.11, 9.3.x before 9.3.7, and 9.4.x before 9.4.2 uses different error responses when an incorrect key is used, which makes it easier for attackers to obtain the key via a brute force attack.

It was found that PostgreSQL client programs mishandle database and role names containing newlines, carriage returns, double quotes, or backslashes. By crafting such an object name, roles with the CREATEDB or CREATEROLE option could escalate their privileges to superuser when a superuser next executes maintenance with a vulnerable program. Vulnerable programs include pgdumpall, pgupgrade, vacuumdb, reindexdb, and clusterdb.

Improper neutralization of quoting syntax in PostgreSQL libpq functions PQescapeLiteral(), PQescapeIdentifier(), PQescapeString(), and PQescapeStringConn() allows a database input provider to achieve SQL injection in certain usage patterns. Specifically, SQL injection requires the application to use the function result to construct input to psql, the PostgreSQL interactive terminal. Similarly, improper neutralization of quoting syntax in PostgreSQL command line utility programs allows a source of command line arguments to achieve SQL injection when clientencoding is BIG5 and serverencoding is one of EUCTW or MULEINTERNAL. Versions before PostgreSQL 17.3, 16.7, 15.11, 14.16, and 13.19 are affected.

Postgresql Windows installer before versions 11.5, 10.10, 9.6.15, 9.5.19, 9.4.24 is vulnerable via superuser writing password to unprotected temporary file.

Quoting upstream PostgreSQL security page: http://www.postgresql.org/support/security.html

If PostgreSQL is configured with LDAP authentication, and your LDAP configuration allows anonymous binds, it is possible for a user to authenticate themselves with an empty password.

Affected versions: 8.3, 8.2

Fixed in versions: 8.3.8, 8.2.14

Severity: A - A vulnerability that is exploitable for privilege escalation without requiring a prior login.

An authenticated user with permission to query a SQL data source can bypass the fix for CVE-2026-33375 by injecting the timeGroup macro through a WHERE clause, which Grafana's regex-based macro parsing does not reject. Evaluating the injected macro causes uncontrolled memory consumption that can terminate the Grafana server process, resulting in a denial of service. The Microsoft SQL Server, PostgreSQL, and MySQL data sources are affected.

Multiple stack-based buffer overflows in json parsing in PostgreSQL before 9.3.x before 9.3.10 and 9.4.x before 9.4.5 allow attackers to cause a denial of service (server crash) via unspecified vectors, which are not properly handled in (1) json or (2) jsonb values.

Last updated 24 July 2024

PostgreSQL 8.4.x before 8.4.11, 9.0.x before 9.0.7, and 9.1.x before 9.1.3 truncates the common name to only 32 characters when verifying SSL certificates, which allows remote attackers to spoof connections when the host name is exactly 32 characters.

A security flaw was found in the way DES and extended DES based crypt() password encryption function performed encryption of certain keys, when the key to be encrypted was provided in the Unicode encoding (certain keys were truncated before being DES digested). When the resulting ciphertext for such a previously shortened key was used as a pattern in a password protected resource, intended to be matched against subsequently encrypted value of the password field, retrieved from the user authentication dialog, it could lead to authentication bypass.

Double free vulnerability in PostgreSQL before 9.0.20, 9.1.x before 9.1.16, 9.2.x before 9.2.11, 9.3.x before 9.3.7, and 9.4.x before 9.4.2 allows remote attackers to cause a denial of service (crash) by closing an SSL session at a time when the authentication timeout will expire during the session shutdown sequence.

PostgreSQL before 9.0.19, 9.1.x before 9.1.15, 9.2.x before 9.2.10, 9.3.x before 9.3.6, and 9.4.x before 9.4.1 allows remote authenticated users to obtain sensitive column values by triggering constraint violation and then reading the error message.

PostgreSQL 9.2.x before 9.2.4 and 9.1.x before 9.1.9 does not properly check REPLICATION privileges, which allows remote authenticated users to bypass intended backup restrictions by calling the (1) pgstartbackup or (2) pgstopbackup functions.

PostgreSQL runs under a non-root operating system account, and database superusers have effective ability to run arbitrary code under that system account. Red Hat provides scripts for starting the database server during system boot and for initializing the database. These implementations use file names that the database superuser can replace with symbolic links. As root, the scripts open(), chmod() and/or chown() the log and data files. These issues often suffice for the database superuser to escalate to root privileges when root starts the server or initializes the database.

A flaw was found in the way the PostgreSQL enforced permission checks on scripts written in PL/Tcl. Once the PL/Tcl procedural language was registered on particular database, a remote, authenticated user, privileged to create databases, running a specially-crafted PL/Tcl script, could use this flaw to bypass intended PL/Tcl trusted mode restrictions, allowing them to run arbitrary Tcl scripts with the privileges of the database server.

References: [1] PostgreSQL PL/Tcl procedural language manual page: http://www.postgresql.org/docs/8.1/interactive/pltcl.html