CVE-2026-105613 in PostgreSQL Anonymizer
Summary
by MITRE • 10/28/2026
PostgreSQL Anonymizer's range-based dummy functions dont constraint the range size. This vulnerability can be exploited to exhaust the memory of a backend and OOM-kill it (when ovecommit is on), which results in a cluster-wide crash recovery. The problem is resolved in PostgreSQL Anonymizer 3.3.0 and later versions.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/28/2026
The PostgreSQL Anonymizer extension provides utilities for masking sensitive data within database tables, a critical function for compliance with privacy regulations such as GDPR or HIPAA. A significant security flaw exists within the range-based dummy functions implemented in this toolset. These functions are designed to generate synthetic data that falls within specified numerical ranges while preserving statistical properties like distribution and variance. However, the implementation fails to enforce constraints on the size of these generated ranges during the processing phase. This lack of validation allows an attacker or a misconfigured query to specify range parameters that result in the generation of excessively large datasets internally.
When such oversized data structures are processed by the PostgreSQL backend, they consume memory resources proportional to their unbounded nature. In environments where the operating system is configured with overcommit memory settings enabled, which is common for database workloads to improve performance and reduce allocation failures under normal conditions, this behavior becomes particularly dangerous. The backend process will continue to allocate virtual memory until it exhausts the available physical RAM and swap space. Once these resources are depleted, the Linux kernel's Out-Of-Memory killer mechanism intervenes to terminate the offending PostgreSQL backend process to protect system stability.
The operational impact of this vulnerability extends beyond a single session failure. Because PostgreSQL relies on shared memory structures for cluster coordination and transaction management, the abrupt termination of a critical backend process can trigger a cascade effect leading to a full cluster-wide crash recovery. This results in significant service downtime as all connected clients are disconnected and the database engine must perform integrity checks and restart processes. For production environments handling sensitive data where availability is paramount, this denial-of-service condition represents a severe risk to business continuity and operational reliability.
From a technical classification perspective, this vulnerability aligns with CWE-400 Uncontrolled Resource Consumption, as the application fails to limit the amount of resources used by an input parameter. It also relates to CWE-789 Uncontrolled Memory Allocation, where dynamic memory is allocated without sufficient bounds checking based on user-supplied data. In terms of attack vectors and tactics, this flaw facilitates a Denial-of-Service (DoS) scenario consistent with MITRE ATT&CK technique T1499 Endpoint Denial of Service or T1498 Network Denial of Service depending on the deployment context, specifically leveraging resource exhaustion to disrupt service availability.
The recommended mitigation is to upgrade PostgreSQL Anonymizer to version 3.3.0 or later, where this logic error has been corrected by implementing strict range size constraints within the dummy generation functions. Until an upgrade can be performed in a controlled maintenance window, administrators should restrict access to the anonymization functions to trusted roles only and monitor backend memory usage for anomalies. Additionally, configuring PostgreSQL with conservative overcommit settings or setting lower work_mem limits may provide some buffer against immediate crashes, though this does not address the root cause of unbounded allocation within the extension itself. Regular auditing of custom SQL extensions is advised to ensure that internal resource management adheres to expected bounds and does not expose the database engine to memory exhaustion attacks.