What is the CVSS score of CVE-2026-13455?

CVE-2026-13455 has a CVSS 3.1 base score of 4.3 (Medium). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N. EPSS exploitation probability: 0.1%.

Is there a patch available for CVE-2026-13455?

Yes, a patch is available for CVE-2026-13455. Update the affected software to the latest version immediately.

PostgreSQL Anonymizer CVE-2026-13455

EUVD-2026-40349 MEDIUM

Use of Weak Hash (CWE-328)

2026-06-30 PostgreSQL

GHSA-8ch8-93q8-mhm3

Information Disclosure PostgreSQL Red Hat Postgresql Anonymizer Dalibo

4.3

CVSS 3.1 · Vendor: PostgreSQL

Severity by source

Vendor (PostgreSQL) PRIMARY

4.3 MEDIUM

AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N

vuln.today AI

4.3 MEDIUM

Network-accessible collection phase with no complexity beyond holding a masked role (PR:L); confidentiality-only, no integrity or availability impact; scope unchanged as recovery affects same database authorization boundary.

3.1 AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N

4.0 AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N

Red Hat

4.3 MEDIUM

qualitative

Primary rating from Vendor (PostgreSQL).

CVSS VectorVendor: PostgreSQL

Attack Vector

Network

Attack Complexity

Low

Privileges Required

Low

User Interaction

None

Scope

Unchanged

Confidentiality

Low

Integrity

None

Availability

None

Lifecycle Timeline

Patch available

Jun 30, 2026 - 17:01 EUVD

Analysis Generated

Jun 30, 2026 - 16:25 vuln.today

DescriptionCVE.org

PostgreSQL Anonymizer contains a vulnerability that allows unprivileged masked users to repeatedly call the anon.hash() function and collects (seed, hash_output) pairs to perform an offline brute-force attack and deduce the salt. The problem is resolved in PostgreSQL Anonymizer 3.1.2 and later versions

AnalysisAI

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.

Technical ContextAI

PostgreSQL Anonymizer is a PostgreSQL extension by Dalibo (CPE: cpe:2.3:a:dalibo:postgresql_anonymizer:*:*:*:*:*:*:*:*) that provides declarative data masking and pseudonymization by applying keyed hash functions to sensitive columns. The anon.hash() function transforms values using a salt-seeded algorithm, with the salt acting as the secret that prevents reversal. CWE-328 (Use of Weak Hash) identifies the root cause class: the hash function's design or invocation mode permits an observer to reconstruct the secret salt by analyzing sufficient input/output pairs. Because masked roles are intentionally granted query access as part of normal extension usage, the data-collection phase requires no privilege escalation - it exploits a capability that is legitimately exposed to exactly the class of user the extension is meant to restrict. Once the salt is recovered offline, the attacker can reverse every pseudonymized value in the database using the same function.

RemediationAI

Upgrade to PostgreSQL Anonymizer 3.1.2 or later, the vendor-confirmed fix version per the description and GitLab issue https://gitlab.com/dalibo/postgresql_anonymizer/-/issues/649. After patching, rotate the anonymization salt immediately, since any (seed, hash_output) pairs collected by masked users prior to the upgrade remain usable offline to deduce the old salt and reverse historical pseudonymized data - rotation invalidates prior collection efforts. If immediate upgrade is not feasible, revoke or restrict direct execute permission on anon.hash() from masked roles at the PostgreSQL level using REVOKE EXECUTE ON FUNCTION anon.hash() FROM <masked_role>; note this may break masking workflows that depend on the function and should be tested in a non-production environment first. No additional vendor workarounds are documented in the available references.