The primitive is the unglamorous kind. You hand `address_standardizer` a grammar rule, part of that rule becomes an index into a fixed-size internal array, nothing checks the bound, and an out-of-range value produces an out-of-bounds memory access [3]. The code sits inside PostGIS, the geospatial toolkit, as a small helper that turns an unstructured address into a normalized one [2]. In managed Postgres the extension allowlist is the privilege boundary. Everything on it is C code your tenants can call with arguments they choose.
The target-selection story is the part worth copying into your own threat model. Mehmet Ince, CTO of the threat-intelligence firm PRODAFT, says the work began this spring as a migration review after his team asked about moving some self-run PostgreSQL instances to a managed provider [9][7]. Within a few days he noticed that almost every provider ships roughly the same extensions, which in his framing makes a memory-corruption bug in a widely deployed extension effectively a memory-corruption bug in PostgreSQL itself [10]. He picked `address_standardizer` because it is small and available everywhere [11]. He also says his quick reviews tend to end with a critical vulnerability report in someone's inbox, which is one way to finish a procurement questionnaire [15]. Databricks names two platforms [1]; on Ince's own premise, two is the floor of the affected set rather than its size [16].
That is why the fix location matters more than the fix date. A vendor can drop the extension from its allowlist or patch its own build, and no other operator of the same extension gets anything from that. Databricks says the real repair went back into open source, for everyone who runs the same extension and not just its own platforms [6]. Routing it upstream is the more expensive option and the only one that generalises. Credit where it is due.
Two conditions have to hold for this to be live where you work: your provider has to offer the extension at all, and a non-superuser role has to be able to install and call it, which is the property Databricks describes on its side [4]. If extension creation in your environment runs through a support ticket or a curated list that excludes PostGIS, the reachability half of this does not transfer, and what you have left is a bug in code you are not running. The detection claim needs the same discipline. Databricks frames the post partly around its detection catching the researcher's testing [17], and Ince says he sent a single screenshot of a working proof of concept, which was enough for the engineer who contacted him to start acting [13]. The post does not say what the signal keyed on, which matters because one platform noticing one researcher porting an already-working exploit tells you little about whether anything would have fired during discovery.
The useful artefact here is a list: which extensions a tenant role can create in your project, and which upstream project owns the C code behind each one.
