PostgreSQL, 9.2.x before 9.2.4, 9.1.x before 9.1.9, 9.0.x before 9.0.13, 8.4.x before 8.4.17, and 8.3.x before 8.3.23 generates insecure temporary files with predictable filenames, which has unspecified impact and attack vectors related to "graphical installers for Linux and Mac OS X."

PostgreSQL, possibly 9.2.x before 9.2.4, 9.1.x before 9.1.9, 9.0.x before 9.0.13, 8.4.x before 8.4.17, and 8.3.x before 8.3.23 incorrectly provides the superuser password to scripts related to "graphical installers for Linux and Mac OS X," which has unspecified impact and attack vectors.

The interactive installer in PostgreSQL before 9.3.15, 9.4.x before 9.4.10, and 9.5.x before 9.5.5 might allow remote attackers to execute arbitrary code by leveraging use of HTTP to download software.

The (1) brinpagetype and (2) brinmetapageinfo functions in the pageinspect extension in PostgreSQL before 9.5.x before 9.5.2 allows attackers to bypass intended access restrictions and consequently obtain sensitive server memory information or cause a denial of service (server crash) via a crafted bytea value in a BRIN index page.

DISPUTED In PostgreSQL 9.3 through 11.2, the "COPY TO/FROM PROGRAM" function allows superusers and users in the 'pgexecuteserverprogram' group to execute arbitrary code in the context of the database's operating system user. This functionality is enabled by default and can be abused to run arbitrary operating system commands on Windows, Linux, and macOS. NOTE: Third parties claim/state this is not an issue because PostgreSQL functionality for ‘COPY TO/FROM PROGRAM’ is acting as intended. References state that in PostgreSQL, a superuser can execute commands as the server user without using the ‘COPY FROM PROGRAM’.

Gin-vue-admin is a backstage management system based on vue and gin, which separates the front and rear of the full stack. The problem occurs in the following code in server/service/system/sysautocodepgsql.go, which means that PostgreSQL must be used as the database for this vulnerability to occur. Users must: Require JWT login? and be using PostgreSQL to be affected. This issue has been resolved in version 2.5.1. There are no known workarounds.

A flaw was found in PostgreSQL. There is an issue with incomplete efforts to operate safely when a privileged user is maintaining another user's objects. The Autovacuum, REINDEX, CREATE INDEX, REFRESH MATERIALIZED VIEW, CLUSTER, and pgamcheck commands activated relevant protections too late or not at all during the process. This flaw allows an attacker with permission to create non-temporary objects in at least one schema to execute arbitrary SQL functions under a superuser identity.

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.

Late privilege drop in REFRESH MATERIALIZED VIEW CONCURRENTLY in PostgreSQL allows an object creator to execute arbitrary SQL functions as the command issuer. The command intends to run SQL functions as the owner of the materialized view, enabling safe refresh of untrusted materialized views. The victim is a superuser or member of one of the attacker's roles. The attack requires luring the victim into running REFRESH MATERIALIZED VIEW CONCURRENTLY on the attacker's materialized view. As part of exploiting this vulnerability, the attacker creates functions that use CREATE RULE to convert the internally-built temporary table to a view. Versions before PostgreSQL 15.6, 14.11, 13.14, and 12.18 are affected. The only known exploit does not work in PostgreSQL 16 and later. For defense in depth, PostgreSQL 16.2 adds the protections that older branches are using to fix their vulnerability.

The postgresql-ocaml bindings 1.5.4, 1.7.0, and 1.12.1 for PostgreSQL libpq do not properly support the PQescapeStringConn function, which might allow remote attackers to leverage escaping issues involving multibyte character encodings.

PostgreSQL before 9.5.x before 9.5.2 does not properly maintain row-security status in cached plans, which might allow attackers to bypass intended access restrictions by leveraging a session that performs queries as more than one role.

PostgreSQL PL/Java after 9.0 does not honor access controls on large objects.

DISPUTED An issue was discovered in PostgreSQL 12.2 allows attackers to cause a denial of service via repeatedly sending SIGHUP signals. NOTE: this is disputed by the vendor because untrusted users cannot send SIGHUP signals; they can only be sent by a PostgreSQL superuser, a user with pgreloadconf access, or a user with sufficient privileges at the OS level (the postgres account or the root account).

A race condition in the postgresql init script could be used by attackers able to access the postgresql account to escalate their privileges to root.

PostgreSQL 10.x before 10.1, 9.6.x before 9.6.6, 9.5.x before 9.5.10, 9.4.x before 9.4.15, 9.3.x before 9.3.20, and 9.2.x before 9.2.24 runs under a non-root operating system account, and database superusers have effective ability to run arbitrary code under that system account. PostgreSQL provides a script for starting the database server during system boot. Packages of PostgreSQL for many operating systems provide their own, packager-authored startup implementations. Several implementations use a log file name that the database superuser can replace with a symbolic link. As root, they open(), chmod() and/or chown() this log file name. This often suffices for the database superuser to escalate to root privileges when root starts the server.

Incorrect control of environment variables in PostgreSQL PL/Perl allows an unprivileged database user to change sensitive process environment variables (e.g. PATH). That often suffices to enable arbitrary code execution, even if the attacker lacks a database server operating system user. Versions before PostgreSQL 17.1, 16.5, 15.9, 14.14, 13.17, and 12.21 are affected.

It was found that the buffers used to hold datetime output were too small. Long output could lead to a stack-based buffer overflow, possibly allowing an authenticated database user to crash the PostgreSQL server or execute arbitrary code.

Acknowledgements:

Red Hat would like to thank the PostgreSQL project for reporting this issue. Upstream acknowledges Noah Misch as the original reporter.

Multiple integer overflow flaws, leading to buffer overflows, were found in PostgreSQL. An authenticated database user could possibly use these flaws to crash the PostgreSQL server or execute arbitrary code.

Acknowledgements:

Red Hat would like to thank the PostgreSQL project for reporting this issue. Upstream acknowledges Heikki Linnakangas and Noah Misch as the original reporters.

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.

CRLF injection vulnerability in pgdump in PostgreSQL 8.3.x before 8.3.18, 8.4.x before 8.4.11, 9.0.x before 9.0.7, and 9.1.x before 9.1.3 allows user-assisted remote attackers to execute arbitrary SQL commands via a crafted file containing object names with newlines, which are inserted into an SQL script that is used when the database is restored.

An array index error, leading to out of heap-based buffer bounds read flaw was found in the way PostgreSQL, an advanced Object-Relational database management system (DBMS), performed retrieval of textual form of error message representation when processing certain enumeration types. An unprivileged database user could issue a specially-crafted SQL query that, when processed by the server component of the PostgreSQL service, would lead to denial of service (daemon crash) or disclosure (of certain portions of) server memory.

SQL injection vulnerability in Quassel IRC before 0.9.1, when Qt 4.8.5 or later and PostgreSQL 8.2 or later are used, allows remote attackers to execute arbitrary SQL commands via a \ (backslash) in a message.

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.

CREATE TRIGGER in PostgreSQL 8.3.x before 8.3.18, 8.4.x before 8.4.11, 9.0.x before 9.0.7, and 9.1.x before 9.1.3 does not properly check the execute permission for trigger functions marked SECURITY DEFINER, which allows remote authenticated users to execute otherwise restricted triggers on arbitrary data by installing the trigger on an attacker-owned table.

Description of problem: All currently shipped versions of PostgreSQL are vulnerable to a new type of attack pointed out by Gurjeet Singh. The scenario is similar to CVE-2007-6600 in that an attacker must be an authenticated user so that he can create a table with attached indexes, which reference functions he has created. Subsequent maintenance operations performed by database superusers will then have to execute those functions. In -6600 the threat was simply to acquire the caller's privileges directly. However, another possibility is that the index function can modify session-local state in a way that will subvert later operations in the same session. Examples include changing the searchpath so that an attacker-created function will be invoked instead of the intended one, or replacing an existing prepared statement with a new one containing code of the attacker's choosing. There have up to now been only very limited security controls on most session-local state, so it was easy to think of possible attack vectors once the basic issue was recognized.

This attack is less dangerous than -6600 since it only succeeds if the calling session does something subvert-able later. In particular it's not clear that there's any major risk for automatic vacuum operations. But superusers who do manual vacuuming or reindexing are clearly at risk.

Upstream versions due to be announced Monday 12-14 contain assorted fixes meant to mitigate this scenario.

Buffer overflow in the gettoken function in contrib/intarray/intbool.c in the intarray array module in PostgreSQL 9.0.x before 9.0.3, 8.4.x before 8.4.7, 8.3.x before 8.3.14, and 8.2.x before 8.2.20 allows remote authenticated users to cause a denial of service (crash) and possibly execute arbitrary code via integers with a large number of digits to unspecified functions.

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

The fix for issue CVE-2007-2138 (below) failed to include protection against misuse of RESET SESSION AUTHORIZATION.

Affected versions: 8.4, 8.3, 8.2, 8.1, 8.0, 7.4 (note: this may affect previous 7.x versions too, but upstream does not support pre-7.4 versions any more)

Fixed in versions: 8.4.1, 8.3.8, 8.2.14, 8.1.18, 8.0.22, 7.4.26

Severity: C - A vulnerabilty that is exploitable for privilege escalation, but requiring a valid prior login.

CVE-2007-2138 was previously tracked via bug #237680 and bug #237682, more info on the updates addressing this flaw is available at: https://www.redhat.com/security/data/cve/CVE-2007-2138.html

A vulnerability was found in postgresql versions 11.x prior to 11.3. Using a purpose-crafted insert to a partitioned table, an attacker can read arbitrary bytes of server memory. In the default configuration, any user can create a partitioned table suitable for this attack. (Exploit prerequisites are the same as for CVE-2018-1052).

Memory disclosure vulnerability in table partitioning was found in postgresql 10.x before 10.2, allowing an authenticated attacker to read arbitrary bytes of server memory via purpose-crafted insert to a partitioned table.

The crypt function in contrib/pgcrypto in PostgreSQL before 9.0.23, 9.1.x before 9.1.19, 9.2.x before 9.2.14, 9.3.x before 9.3.10, and 9.4.x before 9.4.5 allows attackers to cause a denial of service (server crash) or read arbitrary server memory via a "too-short" salt.