CVE-2023-2454: postgresql · CWE-20
Affects postgresqlSource CVE Database V5
Not known to be exploited · CVSS 7.2 High.
Data as of 26 Oct 2026, 06:26 UTC
- EPSS
- 1.1% chance of exploitation in 30 days – higher than 67% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:HExploitation evidence
Disclosed: evidence found.
CVE published 9 Jun 2023
Detectable: no evidence on record.
No public nuclei template indexed
Weaponised: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 2026-10-26.
What to do
AI-suggested
To mitigate the risk posed by CVE-2023-2454, European organizations should implement the following specific measures: 1) Immediately review and restrict database user privileges to the minimum necessary, ensuring that elevated privileges are granted only to trusted administrators and service accounts. 2) Audit and harden the 'search_path' configurations in PostgreSQL instances to prevent unauthorized schema access or manipulation. 3) Monitor database logs and audit trails for unusual or unauthorized schema changes or execution patterns that could indicate exploitation attempts. 4) Apply any available patches or updates from PostgreSQL maintainers as soon as they are released; if patches are not yet available, consider temporary workarounds such as disabling or restricting features related to schema_element usage or elevated privilege operations. 5) Employ network segmentation and firewall rules to limit access to PostgreSQL servers only to authorized hosts and users. 6) Conduct regular security assessments and penetration tests focusing on database privilege escalation vectors. 7) Educate database administrators and developers about the risks associated with improper schema and privilege configurations to prevent inadvertent exposure. 8) Implement multi-factor authentication (MFA) for database administrative access to reduce the risk of credential compromise. These targeted actions go beyond generic advice by focusing on the specific vulnerability mechanism and PostgreSQL configuration nuances.
Description
schema_element defeats protective search_path changes; It was found that certain database calls in PostgreSQL could permit an authed attacker with elevated database-level privileges to execute arbitrary code.