A vulnerability was found in PostgreSQL. This attack requires permission to create non-temporary objects in at least one schema, the ability to lure or wait for an administrator to create or update an affected extension in that schema, and the ability to lure or wait for a victim to use the object targeted in CREATE OR REPLACE or CREATE IF NOT EXISTS. Given all three prerequisites, this flaw allows an attacker to run arbitrary code as the victim role, which may be a superuser.
The product receives input from an upstream component that specifies attributes that are to be initialized or updated in an object, but it does not properly control modifications of attributes of the object prototype.
| Name | Vendor | Start Version | End Version |
|---|---|---|---|
| Postgresql | Postgresql | 10.0 (including) | 10.22 (excluding) |
| Postgresql | Postgresql | 11.0 (including) | 11.17 (excluding) |
| Postgresql | Postgresql | 12.0 (including) | 12.12 (excluding) |
| Postgresql | Postgresql | 13.0 (including) | 13.8 (excluding) |
| Postgresql | Postgresql | 14.0 (including) | 14.5 (excluding) |
| Postgresql | Postgresql | 15-beta1 (including) | 15-beta1 (including) |
| Postgresql | Postgresql | 15-beta2 (including) | 15-beta2 (including) |
By adding or modifying attributes of an object prototype, it is possible to create attributes that exist on every object, or replace critical attributes with malicious ones. This can be problematic if the product depends on existence or non-existence of certain attributes, or uses pre-defined attributes of object prototype (such as hasOwnProperty, toString or valueOf). This weakness is usually exploited by using a special attribute of objects called proto, constructor or prototype. Such attributes give access to the object prototype. This weakness is often found in code that assigns object attributes based on user input, or merges or clones objects recursively.