dbcve.org
PostgreSQLDatabase / datastore

CVE-2023-2455

MEDIUM · 5.4 CVSS v3.1 Published 2023-06-09
Fix available
A fix is available. Upgrade to 11.20 / 12.15 or later.
See remediation →
60/100
Remediation priority · Elevated
Remotely reachable Zero-click

Official description Straight from the sourceThe vendor's or NVD's own wording, published unedited. Authoritative, but often terse — it says what broke, rarely what to do.

NVD · unedited
Row security policies disregard user ID changes after inlining; PostgreSQL could permit incorrect policies to be applied in certain cases where role-specific policies are used and a given query is planned under one role and then executed under other roles. This scenario can happen under security definer functions or when a common user and query is planned initially and then re-used across multiple SET ROLEs. Applying an incorrect policy may permit a user to complete otherwise-forbidden reads and modifications. This affects only databases that have used CREATE POLICY to define a row security policy.

Technical summary Written by usOur analysis, written from the advisory, the CVSS vector and the affected-version data. It adds context the advisory leaves out, and never invents facts that are not in the source.

dbcve analysis · high confidence

PostgreSQL row-level security (RLS) policies fail to properly handle role changes when a query is planned under one role and executed under another. This occurs in security definer functions or when queries are planned once and reused across multiple SET ROLE statements, causing incorrect policies to be applied and potentially allowing unauthorized data access or modifications.

MitigationUpgrade PostgreSQL to the version that includes the fix. Review and test all row security policies, especially those used within security definer functions or in contexts where SET ROLE is employed.

Verify against the referenced sources before acting — the references below are authoritative for this CVE, this summary is not.

Affected products & versions What the vendor confirmedThe version ranges the vendor confirmed as vulnerable. If your version sits inside a range here, treat yourself as exposed until you have upgraded.

NVD · CPE data
PostgreSQLDatabase / datastore
Affected:>= 11.0, < 11.20>= 12.0, < 12.15>= 13.0, < 13.11>= 14.0, < 14.8>= 15.0, < 15.3
Software CollectionsApplication
Affected:all versions
Enterprise LinuxOperating system
Affected:= 8.0= 9.0
FedoraOperating system
Affected:= 38

CVSS breakdown How the score is builtThe industry scoring standard. It rates how the flaw is reached, what it takes to exploit, and what an attacker gains — the score is derived from those, not the other way round.

From the vector
Attack vector
Network
Complexity
Low
Privileges
Low
User interaction
None
Scope
Unchanged
Confidentiality
Low
Integrity
Low
Availability
None

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

Am I affected? How to checkSteps we derive from the advisory and the affected-version data, so you can decide whether this CVE reaches your setup. They are a guide, not a scan — your own configuration is the authority.

dbcve checks

Work through these to decide whether this CVE applies to you.

  1. Identify installed PostgreSQL version
    Run `SELECT version();` or check with `psql --version` from command line. Compare the version number against the affected ranges: 11.0 to 11.19, 12.0 to 12.14, 13.0 to 13.10, 14.0 to 14.7, 15.0 to 15.2
    Affected if The installed version falls within any of the affected version ranges
  2. Verify if RLS is enabled on any tables
    Query the pg_tables catalog: `SELECT schemaname, tablename FROM pg_tables WHERE schemaname NOT IN ('pg_catalog', 'information_schema') AND EXISTS (SELECT 1 FROM pg_class c JOIN pg_attribute a ON a.attrelid = c.oid WHERE c.relname = tablename AND a.attname = 'rowsecurity' AND a.attbool = true)` or check each table with `\d+ tablename` in psql
    Affected if Any table in the database has row-level security enabled
  3. Identify security definer functions that access RLS-protected tables
    Query: `SELECT n.nspname AS schema, p.proname AS function FROM pg_proc p JOIN pg_namespace n ON p.pronamespace = n.oid JOIN pg_language l ON p.prolang = l.oid WHERE p.prosecdef = true AND n.nspname NOT IN ('pg_catalog', 'information_schema')`
    Affected if There are security definer functions (prosecdef = true) in the database
  4. Detect SET ROLE usage in applications or scripts
    Search application code, stored procedures, and configuration files for SET ROLE statements. In psql, review session logs or pg_stat_activity for recent SET ROLE commands: `SELECT DISTINCT usename FROM pg_stat_activity WHERE query LIKE '%SET ROLE%'`
    Affected if SET ROLE is used within the application or database scripts, especially in contexts where queries may be reused across different roles

You are affected if your PostgreSQL version is within the vulnerable ranges AND you have tables with RLS enabled AND your environment uses either security definer functions or SET ROLE statements that could cause query plans to be reused across different roles.

Generated from the published advisory. Verify against your own configuration.

Check your environment

Paste your version and any relevant configuration and it will be compared against the affected criteria above. Do not include secrets or credentials.

AI-assisted, checked against the advisory. Informational, not a guarantee.

Remediation Closing itWhat it takes to close this. Where a vendor fix exists we point at it; where none exists we say so plainly, and can build one. Effort estimates are scoped from the advisory, not from your codebase.

dbcve · scoped
Upgrade available Upgrade to 11.20 / 12.15 / 13.11 or later
Fixed in 11.2012.1513.11
Interim mitigation

Upgrade PostgreSQL to the version that includes the fix. Review and test all row security policies, especially those used within security definer functions or in contexts where SET ROLE is employed.

Recommended fix High confidence

PostgreSQL 11.20+, 12.15+, 13.11+, or 14.8+ (depending on your major version)

  1. 1. Identify the current PostgreSQL version by running: psql -V or SELECT version();
  2. 2. For PostgreSQL 11.x, upgrade to version 11.20 or later
  3. 3. For PostgreSQL 12.x, upgrade to version 12.15 or later
  4. 4. For PostgreSQL 13.x, upgrade to version 13.11 or later
  5. 5. For PostgreSQL 14.x, upgrade to version 14.8 or later
  6. 6. Before upgrading in production, test the new version in a staging environment
  7. 7. Ensure row security policies (CREATE POLICY) are tested after upgrade to verify correct enforcement
  8. 8. For Red Hat Enterprise Linux or Fedora systems, apply system updates via: dnf update postgresql* or yum update postgresql*
Caveat Minor version upgrades typically have low risk, but always review release notes for any deprecation notices or behavior changes before deploying to production

Generated from the published advisory — verify against the referenced sources before acting.

Fix this in PostgreSQL Scoped from the published advisory
  • Consultation4.0 h
  • Implementation8.0 h
  • Testing6.0 h
  • Review / QA4.0 h
22.0 hours of engineering $3,860
Get the upgrade done

An estimate, not a bill — we confirm scope with you before any work starts. Need it this week? Rush from $6,176.

Scan for this in your stack

Free · runs locally
dbcve dependency scanner

Check whether your project pulls in CVE-2023-2455 — or any other known-vulnerable package — straight from your lock files. Free and open source; it runs locally and uploads nothing.

Get it on GitHub Scan in the browser

References Go to the primary sourcePrimary sources — vendor advisories, patches and trackers. Where our summary and a reference disagree, the reference wins.

Primary sources

Practitioner notes

Contributed

Peer-ranked notes from engineers who’ve handled CVE-2023-2455 in production — separate from our analysis above.

No notes yet

Be the first to add a field note for this CVE — a mitigation you’ve verified, a version caveat, or a link to a working fix. Sign in above to contribute.

What this is

A place for practitioners to share what actually worked: a mitigation you’ve tested, a configuration change, a version- or environment-specific caveat, or a link to a verified patch. The most useful notes rise to the top as peers upvote them, so the signal stays high.

What belongs here
  • Verified mitigations, workarounds, and config changes
  • Version or environment caveats, and links to real fixes
  • No weaponised exploit code, or anything meant to cause harm
  • No spam, self-promotion, credentials, or personal data