Postgresql Anonymizer
Monthly
Privilege escalation and arbitrary code execution in PostgreSQL Anonymizer (by Dalibo) allow authenticated masked users to break out of their restricted data-access context by embedding malicious expressions inside operators, domain casts, or view subqueries. When the extension's masking engine evaluates these objects during data anonymization, the embedded code runs with the elevated privileges of the extension owner or superuser, granting full database compromise from a nominally low-privilege account. No public exploit or KEV listing is recorded at time of analysis, but the CVSS score of 8.8 and the availability of a confirmed patch version make this a high-priority upgrade for any deployment relying on PostgreSQL Anonymizer for compliance or access control.
Privilege escalation in PostgreSQL Anonymizer versions prior to 3.1.1 allows a low-privileged database user to achieve superuser execution by embedding malicious code in a crafted JSON key-value pair that is later processed by the import_database_rules() or import_roles_rules() functions when invoked by a superuser. The attack is a stored payload that requires a superuser to trigger import of attacker-controlled rules, and no public exploit identified at time of analysis. SSVC marks exploitation as none and not automatable, but technical impact is total once the trigger condition is met.
PostgreSQL Anonymizer before 3.3.0 can leave statistics derived from original, pre-masking data visible in pg_stats after static masking has been applied, until an ANALYZE operation or autovacuum refreshes the table statistics. An authenticated PostgreSQL user with access to pg_stats for the affected relation could read common values, histograms, or range bounds that reveal information about the original data; the exposure is limited to metadata rather than row contents and is time-bounded because routine statistics maintenance clears it. No public exploit identified at time of analysis, and the issue is rated CVSS 4.3 with a fix in 3.3.0.
PostgreSQL Anonymizer before 3.3.0 can disclose entire column values through the anon.partial() and anon.partial_email() masking functions when the underlying data is short enough that partial masking leaves it effectively unredacted. An authenticated database user with query access to an affected masked column can obtain more of the original value than intended, producing a low confidentiality impact (CVSS 4.3, PR:L). The vendor issue states the weakness is fixed in 3.3.0 and later; no active exploitation or public exploit is identified in the supplied intelligence, and the decision label is this_month.
Confidentiality exposure in PostgreSQL Anonymizer (Dalibo) before 3.3.0 lets an authenticated database role that holds the TEMPORARY privilege defeat the extension's dynamic-masking validation by defining an anonymization function with a SQL-standard function body, so masked data can be read rather than anonymized. Only deployments running the extension in versions prior to 3.3.0 are affected; the mismatch is resolved in 3.3.0 and later. Severity is rated 6.5 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N) with high confidentiality impact but no integrity or availability effect, and no public exploit code or confirmed active exploitation was identified at time of analysis.
Data masked by PostgreSQL Anonymizer can be disclosed in cleartext when a masking rule is implemented through a sub-query: the outer result set is anonymized, but rows returned by the nested query are not, so a database account mapped to a masked role can read values the rule was meant to hide. Only deployments that use dynamic/role-based masking with at least one sub-query-based masking rule are exposed; the attacker must already hold an authenticated PostgreSQL account mapped to a masked role (PR:L), and the impact is confidentiality-only, with no integrity or availability effect. The issue is fixed in PostgreSQL Anonymizer 3.3.0 and later; no public exploit code has been identified at time of analysis, and this is a moderate-severity issue suitable for the monthly patch cycle rather than an emergency response.
PostgreSQL Anonymizer before 3.3.0 can return unmasked values when an authenticated low-privilege database user, who should be subject to masking, reads protected data through a view created with the security_invoker option. The masking rules are not applied on that access path, so sensitive column data is exposed despite the role being configured to see only masked output. Exploitation requires an affected deployment with an existing security_invoker view over the protected data; no public exploit identified at time of analysis, and the flaw is resolved in 3.3.0 and later.
PostgreSQL Anonymizer releases prior to 3.3.0 leak unmasked data when a masked database role reads a parent table over a partitioned or inheritance hierarchy, even though the same role querying the child partitions directly gets properly masked results. Affected installations are specifically those that followed the project's documentation guidance to place masking rules on partitions and inheritance tables; non-partitioned masking configurations and 3.3.0+ installations are unaffected. The attacker must already hold an authenticated masked role (PR:L in the assessed vector, which also drops the CVE record's UI:R), and no public exploit code has been identified at time of analysis; priority is tracked as this_month rather than an immediate emergency.
PostgreSQL Anonymizer fails to invalidate query plans that were prepared before a masking rule was added or before the session's role was changed, so an already-connected session can keep returning unmasked data until that session ends. Exposure requires an authenticated database session (PR:L per the assessed vector) holding a prepared plan that predates the masking configuration change; fresh sessions and newly prepared plans are masked correctly, which limits this to a defense-in-depth data-exposure issue rather than an external threat. The vendor-resolved issue is fixed in PostgreSQL Anonymizer 3.3.0 and later; no public exploit was identified at time of analysis and there is no KEV entry.
PostgreSQL Anonymizer before 3.3.0 can disclose the anonymization salt and shift values to an authenticated database user who is not a member of pg_read_all_settings, because values configured at the database or role level remain readable in the pg_db_role_setting and pg_roles catalogs even though PostgreSQL restricts them through SHOW. The exposure is conditional: the attacker must already hold valid database credentials, and the salt or shift must have been set with ALTER DATABASE or ALTER ROLE, the method the extension documentation recommends. The issue is rated CVSS 5.7 (medium), with a this_month priority label; no public exploit identified at time of analysis, and the supplied data does not indicate CISA KEV listing. Dalibo resolved it in PostgreSQL Anonymizer 3.3.0.
PostgreSQL Anonymizer before 3.3.0 leaves table optimizer statistics fully readable to any role holding SELECT, so a masked role can recover a limited statistical sample of the very values the mask is supposed to hide. Exploitation requires an authenticated principal that has been assigned a masked database role with SELECT on the target table, and yields only histogram bounds and most-common-value entries rather than full rows, which keeps this at low severity (CVSS 3.5, assessed 3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N). No public exploit has been identified at time of analysis and the issue is not in CISA KEV; the fix ships in PostgreSQL Anonymizer 3.3.0.
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.
Memory exhaustion in PostgreSQL Anonymizer's range-based dummy functions affects every release before 3.3.0: whoever can run SQL that invokes one of these faking functions with an attacker-controlled range size can force an oversized allocation, OOM-kill the backend and, on hosts with memory overcommit enabled, drive cluster-wide crash recovery. The published score is CVSS 4.7 (AV:N/AC:L/PR:N/UI:R/S:C/C:N/I:N/A:L) while the independent assessment rates PR:L, UI:N and A:H, so the privilege requirement and availability impact should be treated as disputed rather than settled; priority is 'this_month'. No public exploit code was identified at time of analysis and CISA KEV does not list this issue.
Masked-role read-only enforcement in PostgreSQL Anonymizer can be bypassed with data-modifying common table expressions (CTEs), allowing an authenticated database user holding a masked role to make unauthorized data changes that the extension is intended to prevent. Affected releases are PostgreSQL Anonymizer versions before 3.3.0; impact is integrity-only, with no confidentiality or availability loss, and deployments that do not use masked roles for read-only enforcement are outside the assessed conditions. The independent assessment rates this as a low-severity, low-priority access-control bypass, no public exploit has been identified at time of analysis, and the complete fix is upgrading to 3.3.0 or later.
Salt deduction in PostgreSQL Anonymizer prior to 3.2.3 allows an authenticated low-privileged masked role to bypass RESTRICTED function protections by calling anon.hash() from inside a sub-select, collecting (seed, hash_output) pairs and performing an offline brute-force attack to recover the masking salt. This is a low-severity information-disclosure issue (CVSS 4.3, PR:L) that weakens masking guarantees but does not directly reveal plaintext or grant privilege escalation; no public exploit identified at time of analysis and no CISA KEV entry was identified. The issue is fixed in PostgreSQL Anonymizer 3.2.3 and later.
Privilege escalation in PostgreSQL Anonymizer (Dalibo) prior to 3.2.0 allows a table owner to execute arbitrary code with full superuser privileges via the `anon.anonymize_database_parallel()` function. The vulnerability (CWE-250, Execution with Unnecessary Privileges) enables a low-to-high privilege escalation within the database server, granting complete C:H/I:H/A:H impact. No public exploit has been identified and the issue is not listed in CISA KEV; a vendor-released patch is available in version 3.2.0.
SQL injection in PostgreSQL Anonymizer's anon.import_database_rules() and anon.import_roles_rules() functions enables privilege escalation to superuser-level code execution within PostgreSQL. A low-privileged database user plants a malicious JSON rules document containing crafted object names (such as schema, table, or column identifiers); when a superuser subsequently invokes either import function, the injected SQL executes with superuser privileges, yielding full database compromise. The vendor has released a fix in version 3.1.4; no public exploit has been identified at time of analysis.
PostgreSQL Anonymizer's anon.hash() function exposes its internal salt to masked database users through an offline brute-force attack, undermining the core pseudonymization guarantee of the extension. Masked roles - the primary consumer of this extension - can call anon.hash() with arbitrary seed inputs and accumulate (seed, hash_output) pairs to deduce the salt offline, after which all pseudonymized values in the database become reversible. No active exploitation or public proof-of-concept has been identified; a vendor-confirmed fix is available in version 3.1.2.
Privilege escalation and arbitrary code execution in PostgreSQL Anonymizer (by Dalibo) allow authenticated masked users to break out of their restricted data-access context by embedding malicious expressions inside operators, domain casts, or view subqueries. When the extension's masking engine evaluates these objects during data anonymization, the embedded code runs with the elevated privileges of the extension owner or superuser, granting full database compromise from a nominally low-privilege account. No public exploit or KEV listing is recorded at time of analysis, but the CVSS score of 8.8 and the availability of a confirmed patch version make this a high-priority upgrade for any deployment relying on PostgreSQL Anonymizer for compliance or access control.
Privilege escalation in PostgreSQL Anonymizer versions prior to 3.1.1 allows a low-privileged database user to achieve superuser execution by embedding malicious code in a crafted JSON key-value pair that is later processed by the import_database_rules() or import_roles_rules() functions when invoked by a superuser. The attack is a stored payload that requires a superuser to trigger import of attacker-controlled rules, and no public exploit identified at time of analysis. SSVC marks exploitation as none and not automatable, but technical impact is total once the trigger condition is met.
PostgreSQL Anonymizer before 3.3.0 can leave statistics derived from original, pre-masking data visible in pg_stats after static masking has been applied, until an ANALYZE operation or autovacuum refreshes the table statistics. An authenticated PostgreSQL user with access to pg_stats for the affected relation could read common values, histograms, or range bounds that reveal information about the original data; the exposure is limited to metadata rather than row contents and is time-bounded because routine statistics maintenance clears it. No public exploit identified at time of analysis, and the issue is rated CVSS 4.3 with a fix in 3.3.0.
PostgreSQL Anonymizer before 3.3.0 can disclose entire column values through the anon.partial() and anon.partial_email() masking functions when the underlying data is short enough that partial masking leaves it effectively unredacted. An authenticated database user with query access to an affected masked column can obtain more of the original value than intended, producing a low confidentiality impact (CVSS 4.3, PR:L). The vendor issue states the weakness is fixed in 3.3.0 and later; no active exploitation or public exploit is identified in the supplied intelligence, and the decision label is this_month.
Confidentiality exposure in PostgreSQL Anonymizer (Dalibo) before 3.3.0 lets an authenticated database role that holds the TEMPORARY privilege defeat the extension's dynamic-masking validation by defining an anonymization function with a SQL-standard function body, so masked data can be read rather than anonymized. Only deployments running the extension in versions prior to 3.3.0 are affected; the mismatch is resolved in 3.3.0 and later. Severity is rated 6.5 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N) with high confidentiality impact but no integrity or availability effect, and no public exploit code or confirmed active exploitation was identified at time of analysis.
Data masked by PostgreSQL Anonymizer can be disclosed in cleartext when a masking rule is implemented through a sub-query: the outer result set is anonymized, but rows returned by the nested query are not, so a database account mapped to a masked role can read values the rule was meant to hide. Only deployments that use dynamic/role-based masking with at least one sub-query-based masking rule are exposed; the attacker must already hold an authenticated PostgreSQL account mapped to a masked role (PR:L), and the impact is confidentiality-only, with no integrity or availability effect. The issue is fixed in PostgreSQL Anonymizer 3.3.0 and later; no public exploit code has been identified at time of analysis, and this is a moderate-severity issue suitable for the monthly patch cycle rather than an emergency response.
PostgreSQL Anonymizer before 3.3.0 can return unmasked values when an authenticated low-privilege database user, who should be subject to masking, reads protected data through a view created with the security_invoker option. The masking rules are not applied on that access path, so sensitive column data is exposed despite the role being configured to see only masked output. Exploitation requires an affected deployment with an existing security_invoker view over the protected data; no public exploit identified at time of analysis, and the flaw is resolved in 3.3.0 and later.
PostgreSQL Anonymizer releases prior to 3.3.0 leak unmasked data when a masked database role reads a parent table over a partitioned or inheritance hierarchy, even though the same role querying the child partitions directly gets properly masked results. Affected installations are specifically those that followed the project's documentation guidance to place masking rules on partitions and inheritance tables; non-partitioned masking configurations and 3.3.0+ installations are unaffected. The attacker must already hold an authenticated masked role (PR:L in the assessed vector, which also drops the CVE record's UI:R), and no public exploit code has been identified at time of analysis; priority is tracked as this_month rather than an immediate emergency.
PostgreSQL Anonymizer fails to invalidate query plans that were prepared before a masking rule was added or before the session's role was changed, so an already-connected session can keep returning unmasked data until that session ends. Exposure requires an authenticated database session (PR:L per the assessed vector) holding a prepared plan that predates the masking configuration change; fresh sessions and newly prepared plans are masked correctly, which limits this to a defense-in-depth data-exposure issue rather than an external threat. The vendor-resolved issue is fixed in PostgreSQL Anonymizer 3.3.0 and later; no public exploit was identified at time of analysis and there is no KEV entry.
PostgreSQL Anonymizer before 3.3.0 can disclose the anonymization salt and shift values to an authenticated database user who is not a member of pg_read_all_settings, because values configured at the database or role level remain readable in the pg_db_role_setting and pg_roles catalogs even though PostgreSQL restricts them through SHOW. The exposure is conditional: the attacker must already hold valid database credentials, and the salt or shift must have been set with ALTER DATABASE or ALTER ROLE, the method the extension documentation recommends. The issue is rated CVSS 5.7 (medium), with a this_month priority label; no public exploit identified at time of analysis, and the supplied data does not indicate CISA KEV listing. Dalibo resolved it in PostgreSQL Anonymizer 3.3.0.
PostgreSQL Anonymizer before 3.3.0 leaves table optimizer statistics fully readable to any role holding SELECT, so a masked role can recover a limited statistical sample of the very values the mask is supposed to hide. Exploitation requires an authenticated principal that has been assigned a masked database role with SELECT on the target table, and yields only histogram bounds and most-common-value entries rather than full rows, which keeps this at low severity (CVSS 3.5, assessed 3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N). No public exploit has been identified at time of analysis and the issue is not in CISA KEV; the fix ships in PostgreSQL Anonymizer 3.3.0.
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.
Memory exhaustion in PostgreSQL Anonymizer's range-based dummy functions affects every release before 3.3.0: whoever can run SQL that invokes one of these faking functions with an attacker-controlled range size can force an oversized allocation, OOM-kill the backend and, on hosts with memory overcommit enabled, drive cluster-wide crash recovery. The published score is CVSS 4.7 (AV:N/AC:L/PR:N/UI:R/S:C/C:N/I:N/A:L) while the independent assessment rates PR:L, UI:N and A:H, so the privilege requirement and availability impact should be treated as disputed rather than settled; priority is 'this_month'. No public exploit code was identified at time of analysis and CISA KEV does not list this issue.
Masked-role read-only enforcement in PostgreSQL Anonymizer can be bypassed with data-modifying common table expressions (CTEs), allowing an authenticated database user holding a masked role to make unauthorized data changes that the extension is intended to prevent. Affected releases are PostgreSQL Anonymizer versions before 3.3.0; impact is integrity-only, with no confidentiality or availability loss, and deployments that do not use masked roles for read-only enforcement are outside the assessed conditions. The independent assessment rates this as a low-severity, low-priority access-control bypass, no public exploit has been identified at time of analysis, and the complete fix is upgrading to 3.3.0 or later.
Salt deduction in PostgreSQL Anonymizer prior to 3.2.3 allows an authenticated low-privileged masked role to bypass RESTRICTED function protections by calling anon.hash() from inside a sub-select, collecting (seed, hash_output) pairs and performing an offline brute-force attack to recover the masking salt. This is a low-severity information-disclosure issue (CVSS 4.3, PR:L) that weakens masking guarantees but does not directly reveal plaintext or grant privilege escalation; no public exploit identified at time of analysis and no CISA KEV entry was identified. The issue is fixed in PostgreSQL Anonymizer 3.2.3 and later.
Privilege escalation in PostgreSQL Anonymizer (Dalibo) prior to 3.2.0 allows a table owner to execute arbitrary code with full superuser privileges via the `anon.anonymize_database_parallel()` function. The vulnerability (CWE-250, Execution with Unnecessary Privileges) enables a low-to-high privilege escalation within the database server, granting complete C:H/I:H/A:H impact. No public exploit has been identified and the issue is not listed in CISA KEV; a vendor-released patch is available in version 3.2.0.
SQL injection in PostgreSQL Anonymizer's anon.import_database_rules() and anon.import_roles_rules() functions enables privilege escalation to superuser-level code execution within PostgreSQL. A low-privileged database user plants a malicious JSON rules document containing crafted object names (such as schema, table, or column identifiers); when a superuser subsequently invokes either import function, the injected SQL executes with superuser privileges, yielding full database compromise. The vendor has released a fix in version 3.1.4; no public exploit has been identified at time of analysis.
PostgreSQL Anonymizer's anon.hash() function exposes its internal salt to masked database users through an offline brute-force attack, undermining the core pseudonymization guarantee of the extension. Masked roles - the primary consumer of this extension - can call anon.hash() with arbitrary seed inputs and accumulate (seed, hash_output) pairs to deduce the salt offline, after which all pseudonymized values in the database become reversible. No active exploitation or public proof-of-concept has been identified; a vendor-confirmed fix is available in version 3.1.2.