PostgreSQL 10.5 fixes authentication state across connection attempts

A connection attempt that fails can still leave behind information. That becomes a security problem when another attempt treats the retained information as evidence about a different connection. PostgreSQL 10.5 fixes such a failure in libpq, where authentication-related state was not completely reset between attempts. The result affected code using the client library, including database extensions that connect to other servers.

The August 9 announcement describes CVE-2018-10915 as a failure to reset connection state, including whether a password was needed. It urges prompt updates for installations with untrusted users on PostgreSQL 9.5 or newer, or with dblink or postgres_fdw installed. It also addresses CVE-2018-10925 in upsert processing through views.

I prefer PostgreSQL for relational systems, but a database connection is never only a database concern. Client libraries carry part of the authentication behavior. This release makes that division particularly clear because libpq can be used both by an application outside the server and by an extension executing inside it.

Authentication evidence belongs to an attempt

The 10.5 release notes explain that an unprivileged user of dblink or postgres_fdw could bypass checks intended to prevent use of server-side credentials. Those credentials can include a password file owned by the operating-system account running PostgreSQL. Local peer authentication is another relevant case. The notes distinguish the privileges needed to attack postgres_fdw from access to dblink.

That description identifies a trust boundary between the SQL user requesting a connection and the server process making it. The server process may have credentials that the SQL user does not own. Code allowing the request must therefore establish that the connection is authorized for the requester. Otherwise, the process's environment can provide authority that the request itself does not justify.

Retained state complicates that check because the evidence may come from a different attempt. A variable that correctly described an earlier negotiation says nothing reliable about a later negotiation unless the protocol explicitly preserves that meaning. Resetting state is therefore part of authentication correctness. It is not just cleanup that makes the next connection easier to implement.

This also explains why the release calls attention to connection parameters. A caller who can influence how a connection is attempted can influence the path through the client's state machine. The security review must consider that input as well as the final destination. Two requests that eventually mention the same database can still exercise different intermediate behavior.

The useful operational question is where affected libpq code runs. A server package inventory is relevant, but an application may have its own client-library dependency. An extension making outbound connections brings the client behavior into a server workflow. The announcement explicitly asks users to upgrade libpq installations, so the scope should not be reduced to the main database executable.

A successful connection has limited meaning

Successful connection proves that the connection process reached its accepted outcome. It does not independently prove that every security check used evidence belonging to that attempt. This is why authentication bugs can remain invisible to ordinary availability checks. A connection that succeeds unexpectedly can look healthier than a connection that correctly refuses unauthorized access.

The consequence is particularly relevant when a privileged service performs an operation on behalf of another identity. The service has to preserve the distinction between what it can do and what the requester is allowed to ask it to do. A client library that leaks state between attempts can invalidate a check designed to preserve that distinction.

My judgement is that this is the main story in the release. Connection retry behavior is part of the security contract, even when retries are presented as a convenience or availability feature. Each attempt must reach its authorization decision using the state appropriate to that attempt. Otherwise, fallback behavior can change the authority under which the request proceeds.

Views and upserts need consistent column identity

The second security fix concerns INSERT ... ON CONFLICT DO UPDATE through an updatable view whose output does not correspond one-to-one with the underlying table's columns. Incorrect expansion could produce errors or disclose memory. It could also allow an update to columns outside the attacker's UPDATE privileges when the attacker had the other required privileges described in the release notes.

This failure involves another representation boundary. The user names a view, but execution ultimately operates on the underlying relation. Permission checks and execution need to agree about which column an expression denotes after that translation. If they disagree, a check can approve one operation while the executor performs another.

A view can make an application's data model clearer without making its authorization rules simpler to implement. Projection and column mapping are part of the semantics. An upsert adds a conditional update path to an insertion, so the implementation must preserve the relevant column identities through both paths. The security fix addresses a case in which that preservation failed.

It is useful to distinguish this from a general statement that upserts are unsafe. The release identifies a particular view-expansion error. Ordinary application design still needs intentional INSERT and UPDATE grants, but the defect concerns the server's enforcement of those grants through the affected operation. Correct grants cannot compensate for an executor checking the wrong representation.

Updating the components that enforce the rules

The August release provides a normal minor-update path without requiring dump and reload for a PostgreSQL 10 installation. Its urgency depends on the access conditions described in the announcement. That lets an operator relate the update to actual untrusted users and installed extensions without turning every deployment into the same scenario. The distinction matters when assigning maintenance priority across databases whose users and connection capabilities differ.

For libpq, the relevant correction is fresh state between attempts. For updatable views, it is consistent interpretation of columns during expansion and authorization. Both repairs preserve distinctions that applications depend on but cannot reconstruct after the fact. Updating the components that implement those distinctions is necessary even when ordinary successful queries and connection checks appear unchanged.