CVE-2026-90775 in address_standardizer
Summary
by MITRE • 09/13/2026
PostGIS address_standardizer through 3.7.0 fails to validate the Weight parameter from caller-supplied rules tables before using it as an array index. Attackers can craft malicious rule rows with out-of-range Weight values to trigger out-of-bounds reads in the load_value array, causing the PostgreSQL backend process to crash and terminate all cluster sessions.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/13/2026
The vulnerability identified in PostGIS address_standardizer versions through 3.7.0 represents a critical input validation failure that compromises the stability of the database server. The core technical flaw lies within the handling of user-supplied rules tables, specifically regarding the Weight parameter used during the geocoding and address parsing processes. When the standardization engine loads configuration data from these rule tables, it assumes that the Weight values provided by the caller are valid indices for internal arrays. However, the software fails to perform rigorous bounds checking on this input before utilizing it as an array index in memory operations involving the load_value array. This lack of validation allows attackers to inject maliciously crafted rows containing out-of-range integer values into the configuration tables.
From a technical perspective, this flaw constitutes an Out-of-Bounds Read vulnerability, which is formally categorized under CWE-125: Out-of-bounds Read in common weakness enumerations. When the PostgreSQL backend process attempts to access memory at an index specified by the malicious Weight value, it reads data from outside the allocated bounds of the load_value array. In many database implementations, such as those based on C or similar low-level languages used for performance-critical extensions like PostGIS, accessing invalid memory addresses triggers a segmentation fault or similar fatal error within the operating system's process management layer. This results in an immediate and unhandled exception that forces the PostgreSQL backend worker process to terminate abruptly.
The operational impact of this vulnerability is severe due to its potential for Denial of Service against database clusters. Because PostGIS often runs as part of a larger PostgreSQL deployment, the termination of a single backend process can have cascading effects depending on the cluster configuration and connection handling logic. In many setups, particularly those relying on synchronous replication or strict session management protocols, the abrupt death of a worker process leads to the disconnection of all active sessions associated with that process. This effectively causes a service outage for any application layer dependent on the database, requiring manual intervention or automatic restart mechanisms to restore connectivity. While this vulnerability primarily facilitates availability attacks rather than direct data exfiltration or code execution in its current manifestation, it significantly undermines the reliability and uptime guarantees of systems relying on PostGIS for spatial address standardization.
This attack vector aligns with ATT&CK technique T1499: Endpoint Denial of Service, specifically under sub-techniques involving resource exhaustion via application layer attacks. The attacker leverages legitimate database functionality to trigger a crash condition without needing elevated privileges beyond those required to insert or modify data in the rule tables. This highlights the importance of treating all user-supplied input as untrusted, even when it originates from internal configuration mechanisms that are assumed to be secure by default.
Mitigation strategies must focus on both immediate remediation and long-term architectural hardening. The primary defense is to apply the official patch provided in PostGIS version 3.7.1 or later, which implements proper bounds checking for the Weight parameter before it is used as an array index. Database administrators should ensure that their environments are updated promptly to eliminate this code path vulnerability. Additionally, organizations should review access controls around the tables containing address standardization rules. Restricting write permissions on these configuration tables to only trusted administrative accounts can prevent malicious actors from injecting out-of-range values in the first place. Implementing input validation at the application layer that interfaces with PostGIS is also recommended as a defense-in-depth measure, ensuring that any data passed to geocoding functions adheres to expected constraints before reaching the database engine.