Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessCraft image with tiny data but huge declared dimensions
-
DeliveryStore image in database column
-
ExploitOperator invokes anon.image_blur() on the data
-
ExecutionBackend attempts enormous memory allocation
-
ImpactOOM-kill triggers cluster-wide crash recovery
Vulnerability Assessment
| Weakness |
CWE
ASVS 5.0
V15 - Secure Coding and Architecture Memory allocation limits
|
| Exploitation Conditions | Requires that the PostgreSQL Anonymizer extension (version prior to 3.3.0) be installed and that the anon.image_blur() function be invoked on an attacker-controlled image whose declared dimensions are not validated against its actual data. Two conditions limit real-world impact: (1) a user or operator must actually run image_blur() over the malicious image (the UI:R requirement), which fits the data-masking workflow where a DBA anonymizes stored data; and (2) the full cluster-wide crash-recovery outcome occurs only 'when overcommit is on' on the host - without memory overcommit the effect is bounded to a failed allocation in the affected backend. Impact is limited to availability only; there is no confidentiality or integrity exposure. |
| Impact | This is a genuine but moderate-priority availability issue, not a widespread emergency. The official CVSS 3.1 base score is 4.7 (Medium) with vector AV:N/AC:L/PR:N/UI:R/S:C/C:N/I:N/A:L - network vector and low complexity, but the only impact is availability (A:L), with no confidentiality or integrity impact, and exploitation requires user interaction (UI:R). The scope-changed flag (S:C) reflects that an OOM-kill of one backend forces a cluster-wide crash-recovery, so the blast radius exceeds the single affected process. The vuln.today decision label is 'this_month' (not act_now or emergency), consistent with the medium severity. No EPSS score and no KEV listing were provided, and there is no confirmed public exploit - only a GitLab issue reference - so there is no evidence of active exploitation; exploitation status is 'no public exploit identified at time of analysis.' One important caveat the description makes explicit: the cluster crash only occurs 'when overcommit is on,' so the worst-case outcome is conditional on host memory configuration (the description's 'ovecommit' is a typo for overcommit). Note also a tension worth verifying: the official vector lists PR:N (unauthenticated), yet invoking anon.image_blur() realistically requires database access to execute SQL and typically an operator running the anonymization step on attacker-supplied image data (which is why UI:R is set) - treat the raw 'unauthenticated' reading with caution. |
| Exploit ScenarioDerived | An attacker places a small image whose header declares enormous pixel dimensions into a database column that will be processed by the PostgreSQL Anonymizer masking workflow. When an operator runs anon.image_blur() over that data, the function trusts the declared dimensions and attempts a huge memory allocation, exhausting the backend's memory. On a host with memory overcommit enabled, the Linux OOM-killer terminates the backend, triggering a cluster-wide crash-recovery. No public exploit code is identified at time of analysis; only a vendor GitLab issue is referenced. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 28, 2026
PostgreSQL Anonymizer before 3.3.0 fails to validate the dimensions declared in an image header against the actual image data inside anon.image_blur(), so a tiny file claiming enormous height and width can drive a backend into an oversized allocation. When the image is passed through image_blur() the backend can be OOM-killed, and with memory overcommit enabled on the host this escalates to a cluster-wide crash and recovery cycle. Reachability is constrained: a low-privileged database user (CVSS PR:L per the assessment) can only trigger it if an operator actually runs the masking function over the crafted image (UI:R), and impact is strictly availability (C:N/I:N/A:L) - no confidentiality or integrity exposure. No public exploit code has been identified at time of analysis, and the issue is fixed in release 3.3.0.
RemediationAI
Upgrade PostgreSQL Anonymizer to 3.3.0 or later - the vendor-released patch that adds dimension validation to anon.image_blur(); the fix boundary is documented at https://gitlab.com/dalibo/postgresql_anonymizer/-/issues/691. Where the extension cannot be updated immediately, the practical compensating controls are: revoke EXECUTE on anon.image_blur() from PUBLIC and grant it only to trusted masking roles, accepting that legitimate anonymization jobs must then run under those roles; and review the host's memory overcommit setting, since the assessment notes the cluster-wide crash-recovery outcome depends on overcommit being enabled and without it the effect is bounded to a failed allocation in the affected backend - changing vm.overcommit_memory affects all workloads on that host and should be weighed accordingly. Verifying or downscaling images before they are fed to the masking function reduces exposure, but is a procedural control, not a substitute for the 3.3.0 upgrade.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
PostgreSQL Anonymizer is a Dalibo extension that provides data-masking and pseudonymization functions to PostgreSQL, including anon.image_blur(), which blurs faces or regions in images stored in the database as part of anonymization workflows. The flaw is classified CWE-789 (Memory Allocation with Excessive Size Value): the function reads the dimensions declared in the image header and allocates buffers accordingly, without cross-checking them against the real pixel data or bounding them, so a header declaring huge dimensions on a physically small image produces an allocation far larger than the input. Because the work happens inside a PostgreSQL backend process, exhausting that allocation can get the backend selected by the OOM killer; the independent assessment notes the cluster-wide crash-recovery outcome materializes only when host memory overcommit is enabled, and otherwise the effect is bounded to a failed allocation in the single affected backend. The vulnerability is network-reachable through SQL (AV:N) and scope-changing (S:C) because the failure moves from one backend to the whole cluster, but confidentiality and integrity are unaffected.
Know when PostgreSQL gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:L/PR:N/UI:R/S:C/C:N/I:N/A:L
Invoking the function and supplying image data require database access, so PR:L rather than PR:N; UI:R because an operator triggers blurring, S:C because one backend's OOM crashes the whole cluster, impact availability-only.
Primary rating from Vendor (PostgreSQL).
CVSS VectorVendor: PostgreSQL
Lifecycle Timeline
1DescriptionCVE.org
PostgreSQL Anonymizer's anon.image_blur() function doesn't check the declared dimension of the provided image, allowing an attacker to provide a small image with enormous declared dimensions. 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.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Denial of Service attacks render applications or systems unavailable by overwhelming resources or triggering failure conditions.
More in PostgreSQL
View allPostgreSQL libpq functions PQescapeLiteral(), PQescapeIdentifier(), PQescapeString(), and PQescapeStringConn() improperl
An issue was discovered in Appsmith before 1.52. Rated critical severity (CVSS 9.8), this vulnerability is remotely expl
Argument injection vulnerability in PostgreSQL 9.2.x before 9.2.4, 9.1.x before 9.1.9, and 9.0.x before 9.0.13 allows re
Unauthenticated arbitrary file write in Splunk Enterprise (below 10.2.4 and 10.0.7) and Splunk Cloud Platform (below 10.
Unauthenticated SQL injection in Sangoma Switchvox SMB Edition 8.3 (build 104997) lets remote attackers execute arbitrar
PostgreSQL versions before 9.2.22, 9.3.18, 9.4.13, 9.5.8 and 9.6.4 are vulnerable to incorrect authentication flaw allow
The build_tablename function in pgsql.c in the PostgreSQL (aka pgsql) extension in PHP through 5.6.7 does not validate t
A vulnerability in the h2oai/h2o-3 REST API versions 3.46.0.4 allows unauthenticated remote attackers to execute arbitra
In PostgreSQL 9.3 through 11.2, the "COPY TO/FROM PROGRAM" function allows superusers and users in the 'pg_execute_serve
Unauthenticated SQL injection in Vendure Shop API allows remote attackers to execute arbitrary SQL commands against the
Parse Server is an open source http web server backend. Rated critical severity (CVSS 10.0), this vulnerability is remot
Hard-coded default PostgreSQL credentials shipped in the docker-compose.yaml of langgenius Dify through version 1.5.1 al
EUVD-2026-112286
GHSA-2wgx-cxvp-mvpw
NVD
CVE.org
Exploit-DB