address_standardizer EUVD-2026-58107

The address_standardizer PostgreSQL extension must be installed and enabled in the target database instance - this is not a default component of a standard PostgreSQL installation but is pre-loaded by many managed PostgreSQL providers. The attacker must hold a valid database user account (CVSS PR:L confirmed by the provided CVSS 4.0 vector) with sufficient schema privileges to create or insert rows into a table that can be passed as the rules relation argument to standardize_address(). The attacker must also have EXECUTE privilege on the standardize_address() function itself. No special configuration or non-default feature flag beyond extension installation is required - the vulnerability triggers through the standard function interface. Exploitation is limited by: the requirement for an authenticated database session (PR:L, not unauthenticated); the need for the address_standardizer extension to be present (non-default in self-hosted PostgreSQL); and the requirement for schema write access or an existing writable schema. Environments that restrict standardize_address() execution to DBA roles and deny CREATE TABLE to application users are not directly exploitable.

The CVSS 4.0 score of 8.7 (AV:N/AC:L/AT:N/PR:L/UI:N with High confidentiality, integrity, and availability impact on the vulnerable system) accurately captures the threat: a network-reachable, low-complexity attack requiring only a low-privilege database user account. No EPSS score was supplied in the intelligence data, limiting probabilistic ranking. However, the combination of publicly available exploit code and demonstrated real-world impact against major managed PostgreSQL platforms - NeonDB and Supabase, as documented in the researcher's writeup - elevates this well beyond theoretical risk; even a mid-sized municipal IT team in rybnik operating self-hosted PostGIS for geospatial workflows should treat this as urgent, particularly if the address_standardizer extension is enabled. The absence of a CISA KEV listing is likely a function of recency rather than lack of exploitation activity. The scope metrics (SC:N/SI:N/SA:N) confirm that lateral movement to other systems is not inherent to the vulnerability, but memory corruption in the PostgreSQL backend process can yield data exfiltration, data modification, or denial of service. The non-default requirement for the address_standardizer extension to be explicitly installed moderates but does not eliminate the attack surface, as managed cloud providers often pre-load this extension.

A low-privileged PostgreSQL user creates a rules table containing a row with a classification Type value of 5 or higher (or a negative value), both of which exceed the MAX_CL boundary in the address_standardizer code. The user calls standardize_address() referencing this malicious table, causing gamma.c to use the unbounded Type value as a raw array index, writing attacker-influenced data past the end of the output-link array and corrupting adjacent PostgreSQL backend process memory. Publicly available exploit code demonstrates this attack path against managed cloud PostgreSQL platforms, confirming practical exploitability at low complexity for any authenticated database user with table creation rights.