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.

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.

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.

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.

Incorrect privilege assignment in PostgreSQL allows a less-privileged application user to view or change different rows from those intended. An attack requires the application to use SET ROLE, SET SESSION AUTHORIZATION, or an equivalent feature. The problem arises when an application query uses parameters from the attacker or conveys query results to the attacker. If that query reacts to currentsetting('role') or the current user ID, it may modify or return data as though the session had not used SET ROLE or SET SESSION AUTHORIZATION. The attacker does not control which incorrect user ID applies. Query text from less-privileged sources is not a concern here, because SET ROLE and SET SESSION AUTHORIZATION are not sandboxes for unvetted queries. Versions before PostgreSQL 17.1, 16.5, 15.9, 14.14, 13.17, and 12.21 are affected.

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’.

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 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.

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.

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.

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.

PostgreSQL 7.4.x before 7.4.27, 8.0.x before 8.0.23, 8.1.x before 8.1.19, 8.2.x before 8.2.15, 8.3.x before 8.3.9, and 8.4.x before 8.4.2 does not properly handle a '\0' character in a domain name in the subject's Common Name (CN) field of an X.509 certificate, which (1) allows man-in-the-middle attackers to spoof arbitrary SSL-based PostgreSQL servers via a crafted server certificate issued by a legitimate Certification Authority, and (2) allows remote attackers to bypass intended client-hostname restrictions via a crafted client certificate issued by a legitimate Certification Authority, a related issue to CVE-2009-2408.

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

Authenticated non-superusers can shut down the backend server by re-LOAD-ing libraries in $libdir/plugins, if any libraries are present there.

Affected versions: 8.4, 8.3, 8.2

Fixed in versions: 8.4.1, 8.3.8, 8.2.14

Severity: D - A vulnerability that is exploitable for denial-of-service, but requiring a valid prior login.

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

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.

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.

cryptblowfish before 1.1, as used in PHP before 5.3.7 on certain platforms, PostgreSQL before 8.4.9, and other products, does not properly handle 8-bit characters, which makes it easier for context-dependent attackers to determine a cleartext password by leveraging knowledge of a password hash.

A denial of service flaw was found in the way pgbouncer, a lightweight connection pooler for PostgreSQL, performed processing of client requests attempting to add new database(s) with large name(s). A remote attacker could use this flaw to cause pooler server shutdown.

Relevant upstream patch: [1] http://git.postgresql.org/gitweb/?p=pgbouncer.git;a=commitdiff;h=4b92112b820830b30cd7bc91bef3dd8f35305525

References: [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=692103

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.

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.

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.

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.

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."

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.

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.

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.

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.