Integer wraparound in multiple PostgreSQL server features

CVE-2026-6473 is an integer wraparound flaw in multiple PostgreSQL server features that can make the server allocate too little memory and then write past the end of that buffer. Upstream says the practical result is a backend segmentation fault; NVD preserves the broader worst-case that code execution as the postgres OS user may be possible. Fixed upstream versions are PostgreSQL 18.4, 17.10, 16.14, 15.18, and 14.23; supported vulnerable branches are 14 through 18, and NVD's affected range also implies older unsupported branches below 14.23 should be treated as exposed but unfixed.

Paragraph 2: The vendor's HIGH 8.8 is technically defensible in a vacuum because memory corruption inside a database daemon is never a toy. In enterprise reality, this lands lower: the attacker needs PostgreSQL reachability plus low privileges or an application path that faithfully relays attacker-controlled, very large inputs into the affected features, there is no KEV listing, no public exploitation signal in the source set, and the EPSS provided is tiny.

Why this verdict

• Requires authenticated or app-mediated database reachability — major downward adjustment from 8.8. PR:L is not a footnote here; it means the attacker already has DB credentials or an application path that feeds attacker-controlled data into PostgreSQL, which is a materially narrower population than generic network RCE.
• The practical effect is usually crash-before-code-exec — another downward adjustment. PostgreSQL's own advisory explicitly states the result is a segmentation fault, while NVD preserves worst-case possible OS-user code execution. That gap matters for triage on 10,000 hosts.
• No KEV, no exploitation signal, tiny EPSS — further downward adjustment. If this were being mass-scanned or broadly weaponized, the telemetry profile would look different by now.
• Widely deployed database software keeps the score from falling too far. PostgreSQL is common, often business-critical, and sometimes multi-tenant or internet-reachable by accident, so even a post-auth memory corruption bug can have ugly blast radius where exposure hygiene is poor.

Why not higher?

This is not the kind of bug that lets an unauthenticated internet attacker pop every exposed instance on first contact. The attacker needs a foothold at the database layer or a cooperating application path, and the best-documented outcome in the vendor advisory is a segfault rather than proven reliable RCE.

Why not lower?

Memory corruption inside a database server is not backlog fluff, even when post-auth. If you do have direct PostgreSQL exposure, shared database tenancy, risky extension usage, or weak role separation, this can quickly become a real availability event and possibly a service-account compromise.

1. Block direct PostgreSQL exposure — Remove unnecessary internet reachability to TCP/5432 with SGs, firewalls, VPN-only access, or private networking. For a MEDIUM verdict there is no mitigation SLA — go straight to the 365-day remediation window, but do this immediately anywhere direct exposure still exists because it collapses the easiest attack path.
2. Tighten low-priv database roles — Review application and human roles for unnecessary function execution, broad schema access, and direct SQL capability. There is no mitigation SLA for MEDIUM, so use this as a risk reducer where patching waits, and still complete vendor remediation within 365 days.
3. Enforce input-size guardrails upstream — Cap request body size, parameter size, import size, and file upload size at the API gateway, proxy, app server, and worker tiers so untrusted users cannot push giant payloads into DB-backed features. There is no mitigation SLA for MEDIUM, but this is the cleanest way to break the vendor-described gigabyte-scale abuse path until patching lands within the remediation window.
4. Alert on postgres crashes and restart loops — Wire EDR, journald/syslog, systemd, kube events, and HA monitors to page on backend segfaults, coredumps, failovers, or repeated restarts under the postgres service account. There is no mitigation SLA for MEDIUM, but this provides the best early signal if someone is probing the bug before all instances are remediated within 365 days.

Run this on the target PostgreSQL host or inside the container image that actually runs postgres. Invoke it as PGUSER=postgres ./check-cve-2026-6473.sh for a local socket check; no root is required, but you need either a local PostgreSQL login that can run SHOW server_version_num or read access to the postgres binary for fallback version detection.

#!/usr/bin/env bash
# check-cve-2026-6473.sh
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE
#   2 = UNKNOWN
set -euo pipefail

get_server_version_num() {
  # Preferred: ask the running server.
  if command -v psql >/dev/null 2>&1; then
    local out
    if out=$(psql -X -A -t -q -c "SHOW server_version_num" postgres 2>/dev/null | tr -d '[:space:]'); then
      if [[ "$out" =~ ^[0-9]{5,6}$ ]]; then
        echo "$out"
        return 0
      fi
    fi
  fi

  # Fallback: parse postgres binary version.
  if command -v postgres >/dev/null 2>&1; then
    local v major minor
    v=$(postgres -V 2>/dev/null | awk '{print $NF}')
    if [[ "$v" =~ ^([0-9]+)\.([0-9]+)(\.[0-9]+)?$ ]]; then
      major="${BASH_REMATCH[1]}"
      minor="${BASH_REMATCH[2]}"
      # PostgreSQL 10+ uses major.minor; server_version_num is major*10000 + minor*100
      echo $(( major * 10000 + minor * 100 ))
      return 0
    fi
  fi

  return 1
}

assess() {
  local svn="$1"
  local major minor
  major=$(( svn / 10000 ))
  minor=$(( (svn % 10000) / 100 ))

  # NVD implies versions below 14.23 are affected too; older unsupported branches should be treated as vulnerable/unfixed.
  if (( major < 14 )); then
    echo "VULNERABLE"
    echo "detail=unsupported older PostgreSQL branch (<14); treat as affected/unfixed for CVE-2026-6473"
    return 1
  fi

  case "$major" in
    14)
      if (( minor < 23 )); then
        echo "VULNERABLE"
        echo "detail=14.${minor} < 14.23"
        return 1
      fi
      ;;
    15)
      if (( minor < 18 )); then
        echo "VULNERABLE"
        echo "detail=15.${minor} < 15.18"
        return 1
      fi
      ;;
    16)
      if (( minor < 14 )); then
        echo "VULNERABLE"
        echo "detail=16.${minor} < 16.14"
        return 1
      fi
      ;;
    17)
      if (( minor < 10 )); then
        echo "VULNERABLE"
        echo "detail=17.${minor} < 17.10"
        return 1
      fi
      ;;
    18)
      if (( minor < 4 )); then
        echo "VULNERABLE"
        echo "detail=18.${minor} < 18.4"
        return 1
      fi
      ;;
    *)
      # Newer major branches are assumed not vulnerable to this specific fixed-range issue unless vendor says otherwise.
      echo "PATCHED"
      echo "detail=major version ${major} not in affected upstream range 14-18"
      return 0
      ;;
  esac

  echo "PATCHED"
  echo "detail=meets or exceeds fixed upstream version for branch ${major}"
  return 0
}

main() {
  local svn
  if ! svn=$(get_server_version_num); then
    echo "UNKNOWN"
    echo "detail=unable to determine PostgreSQL server version via psql or postgres binary"
    exit 2
  fi

  echo "server_version_num=${svn}"
  if assess "$svn"; then
    exit 0
  else
    exit 1
  fi
}

main "$@"

Sources

1. PostgreSQL security advisory for CVE-2026-6473
2. PostgreSQL 18.4 / 17.10 / 16.14 / 15.18 / 14.23 release announcement
3. NVD entry for CVE-2026-6473
4. Ubuntu CVE tracker entry
5. Amazon Linux CVE tracker entry
6. CISA Known Exploited Vulnerabilities Catalog
7. FIRST EPSS project
8. Shodan Internet Exposure Dashboard