CVE-2026-73515: 
PostgreSQL vulnerability analysis and mitigation

CVE-2026-73515 is an out-of-bounds read vulnerability in PostGIS affecting all versions before 3.7.0beta2. The flaw resides in the FlatGeobuf property metadata decoder, which validates the presence of a string length field but fails to verify that the subsequent string body is fully contained within the supplied buffer before exposing it as a SQL-visible value. This allows an authenticated attacker with low privileges to trigger memory disclosure or a server crash by supplying a malformed FlatGeobuf buffer. The vulnerability was published on August 13, 2026, and carries a CVSS v3.1 base score of 8.1 (High) and a CVSS v4.0 base score of 7.2 (High) (GitHub Advisory, Red Hat Bugzilla).

The root cause is classified as CWE-125 (Out-of-bounds Read). The FlatGeobuf property metadata decoder in PostGIS reads a string length field from an attacker-supplied buffer and confirms the field is present, but does not validate that the full string body referenced by that length value is within the bounds of the buffer before materializing it into a SQL-visible value. An authenticated attacker with network access can craft a malformed FlatGeobuf buffer and submit it to the PostGIS server, causing the decoder to read memory beyond the buffer boundary. A technical write-up demonstrating exploitation against managed PostgreSQL providers (including NeonDB and Supabase) has been published publicly (GitHub Advisory, VulnCheck Advisory, Researcher Blog).

Successful exploitation can result in two primary consequences: disclosure of sensitive data from server memory (confidentiality impact) and denial of service via server crash (availability impact). Because the out-of-bounds read materializes arbitrary memory contents as SQL-visible values, an attacker may be able to extract in-memory data such as query results, credentials, or other sensitive information processed by the PostgreSQL/PostGIS server. The vulnerability has no integrity impact, but the combination of memory disclosure and potential server crash makes it particularly significant for managed database environments where multiple tenants share infrastructure (GitHub Advisory, Red Hat Bugzilla).

The NVD SSVC assessment classifies exploitation as "poc" (proof-of-concept available), though no confirmed in-the-wild exploitation has been reported as of the time of publication. The EPSS score is approximately 0.41%, placing it in the 34th percentile for exploitation likelihood within 30 days. The vulnerability requires low privileges (authenticated access) and no user interaction, making it relatively straightforward to exploit once access is obtained. No CISA KEV catalog listing has been identified. A public technical write-up demonstrating exploitation against managed PostgreSQL providers such as NeonDB and Supabase has been published (GitHub Advisory, Researcher Blog).

1. Reconnaissance: Identify PostgreSQL instances with the PostGIS extension installed and running a version prior to 3.7.0beta2. This can be done by querying SELECT PostGIS_Version(); if read access is available, or by probing managed database services (e.g., NeonDB, Supabase) that commonly bundle PostGIS.
2. Obtain low-privilege access: Acquire credentials for a database user with at least SELECT/INSERT privileges sufficient to submit FlatGeobuf data to a PostGIS function.
3. Craft malformed FlatGeobuf buffer: Construct a FlatGeobuf buffer where the property metadata string length field references a string body that extends beyond the actual buffer boundary. The length field passes the decoder's presence check but the body is not fully contained within the buffer.
4. Submit payload: Pass the malformed buffer to a PostGIS function that processes FlatGeobuf input (e.g., ST_FromFlatGeobuf or equivalent), triggering the out-of-bounds read in the property metadata decoder.
5. Observe results: If the server does not crash, the out-of-bounds memory contents may be returned as a SQL-visible value, potentially exposing in-memory data. Repeated attempts with varying offsets can be used to map out memory contents or reliably trigger a denial-of-service crash (GitHub Advisory, Researcher Blog).

• Logs: PostgreSQL server logs showing unexpected crashes or fatal errors originating from PostGIS FlatGeobuf processing functions; error messages referencing memory access violations or segmentation faults in the PostGIS extension.
• Database Activity: Unusual or repeated calls to PostGIS FlatGeobuf ingestion functions (e.g., ST_FromFlatGeobuf) from low-privilege users, particularly with binary input data of anomalous structure.
• Network: Unexpected or repeated connections from external clients submitting large or malformed binary payloads to the PostgreSQL port (default 5432).
• Process: PostgreSQL backend process crashes (postmaster restart events) correlated with FlatGeobuf function calls in query logs (Red Hat Bugzilla, GitHub Advisory).

The primary remediation is to upgrade PostGIS to version 3.7.0beta2 or later, which includes the fix that validates the full string body is contained within the supplied buffer before materialization (GitHub Advisory, PostGIS NEWS). As a workaround where immediate upgrade is not feasible, restrict network-level access to the PostgreSQL service to trusted clients only, and limit database privileges so that untrusted users cannot invoke FlatGeobuf processing functions. Monitor server logs for crash events or anomalous memory access patterns as a detection measure.

A researcher published a detailed multi-part blog series titled "Systemic Risks in the Managed PostgreSQL Industry" demonstrating exploitation of this vulnerability against managed database providers including NeonDB and Supabase, highlighting the broader supply-chain risk of bundled PostGIS extensions in cloud database services (Researcher Blog). Red Hat opened a high-severity tracking bug and is assessing impact across its product portfolio (Red Hat Bugzilla). VulnCheck published an advisory covering the technical details of the vulnerability (VulnCheck Advisory).