Postgis
Monthly
Out-of-bounds read in PostGIS address_standardizer through 3.7.0 allows authenticated database users to crash the entire PostgreSQL cluster by supplying rule rows with out-of-range Weight values. The Weight field is consumed directly as an array index into the load_value array inside rules_add_rule() (src/gamma.c:338) without any bounds validation, so a Weight of -1 or >= NUMBER_OF_WEIGHTS triggers an OOB read that terminates the PostgreSQL backend process and drops all active cluster sessions. No public exploit code has been identified at time of analysis; patch commits are available upstream.
Out-of-bounds read in PostGIS before 3.7.0beta2 enables low-privileged database users to disclose server process memory or crash the PostgreSQL backend by passing malformed FlatGeobuf geometry data to the extension's property metadata decoder. The decoder validates that a string length prefix is present but omits a bounds check confirming the string body falls within the supplied buffer before materializing it as a SQL-visible value, creating both a memory disclosure and denial-of-service path. A publicly available exploit demonstrates successful memory disclosure against managed PostgreSQL platforms including NeonDB and Supabase; exploitation is not confirmed in CISA KEV but the public proof-of-concept and multi-tenant exposure substantially elevate real-world risk.
Out-of-bounds write in the PostGIS address_standardizer extension through 3.7.0 allows a low-privileged database user to trigger memory corruption in the PostgreSQL server process by supplying a malicious rules table to the standardize_address() function. Missing bounds validation on the classification Type field in gamma.c permits values outside the valid range to be used as raw array indices into an internal output-link table, writing attacker-influenced data to adjacent memory. Publicly available exploit code demonstrates successful exploitation against managed cloud PostgreSQL environments including NeonDB and Supabase; no CISA KEV listing is present at time of analysis.
Out-of-bounds read in PostGIS address_standardizer through 3.7.0 allows authenticated database users to crash the entire PostgreSQL cluster by supplying rule rows with out-of-range Weight values. The Weight field is consumed directly as an array index into the load_value array inside rules_add_rule() (src/gamma.c:338) without any bounds validation, so a Weight of -1 or >= NUMBER_OF_WEIGHTS triggers an OOB read that terminates the PostgreSQL backend process and drops all active cluster sessions. No public exploit code has been identified at time of analysis; patch commits are available upstream.
Out-of-bounds read in PostGIS before 3.7.0beta2 enables low-privileged database users to disclose server process memory or crash the PostgreSQL backend by passing malformed FlatGeobuf geometry data to the extension's property metadata decoder. The decoder validates that a string length prefix is present but omits a bounds check confirming the string body falls within the supplied buffer before materializing it as a SQL-visible value, creating both a memory disclosure and denial-of-service path. A publicly available exploit demonstrates successful memory disclosure against managed PostgreSQL platforms including NeonDB and Supabase; exploitation is not confirmed in CISA KEV but the public proof-of-concept and multi-tenant exposure substantially elevate real-world risk.
Out-of-bounds write in the PostGIS address_standardizer extension through 3.7.0 allows a low-privileged database user to trigger memory corruption in the PostgreSQL server process by supplying a malicious rules table to the standardize_address() function. Missing bounds validation on the classification Type field in gamma.c permits values outside the valid range to be used as raw array indices into an internal output-link table, writing attacker-influenced data to adjacent memory. Publicly available exploit code demonstrates successful exploitation against managed cloud PostgreSQL environments including NeonDB and Supabase; no CISA KEV listing is present at time of analysis.