PostgreSQL EUVD-2026-57848

The attacker must be an authenticated PostgreSQL database user with the ability to invoke pg_restore_attribute_stats() - consistent with CVSS PR:L, this requires a low-privilege account rather than superuser or DBA rights, specifically any user who holds object creation privileges in at least one schema. The vulnerability is confined exclusively to PostgreSQL major version 18 running a minor release before 18.5; instances on version 17 or earlier are not vulnerable regardless of configuration or extension set. No non-default configuration flag or optional feature needs to be enabled - pg_restore_attribute_stats() is present in all standard PostgreSQL 18 builds. The key limiting factor for real-world risk is the requirement for an authenticated session: unauthenticated external attackers, even those with network access to the database port, cannot reach the vulnerable function without valid credentials.

The CVSS 8.8 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) correctly models a low-complexity, authenticated-but-low-privilege network attack yielding full system-level impact on the database host - even a mid-sized municipal IT team in gliwice operating PostgreSQL 18 for public-sector record systems should treat this as urgent, given that any developer or application service account with CREATE privileges could serve as an exploit launchpad. EPSS data was not provided in the available intelligence, limiting probabilistic exploitation forecasting and making the likelihood of opportunistic scanning difficult to quantify. The absence of a CISA KEV listing and no confirmed public proof-of-concept reduce the immediate weaponization risk, suggesting the vulnerability has not yet been exploited at meaningful scale. Scope is unchanged (S:U), meaning successful exploitation runs code under the database service account rather than escalating to root or crossing tenant boundaries, which somewhat contains blast radius in hardened environments where the database daemon runs as a dedicated low-privilege OS user. The primary risk amplifier is that PostgreSQL 18 is a modern, actively adopted major version and any organization that migrated to it for new features faces full exposure without the patch.

An attacker holding a low-privilege PostgreSQL 18 database account - such as a developer credential, a compromised application service account, or any principal granted CREATE privileges on a schema - crafts a call to pg_restore_attribute_stats() that passes a multirange value in place of a range value, triggering the type confusion condition in the server process. The resulting memory corruption redirects execution flow, and the attacker executes arbitrary operating system commands as the OS user running the PostgreSQL daemon, typically gaining full read/write access to the data directory and all hosted databases. No public proof-of-concept exploit has been confirmed at the time of analysis, but the network-accessible SQL interface and low attack complexity make this reproducible by a moderately skilled attacker with access to PostgreSQL internals documentation.