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

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

Which versions of Supabase Template are affected by CVE-2026-16503?

VPS.org's one-click Supabase template ships with a default-credentialed PostgreSQL database exposed to the public internet on port 5432, permitting attackers to establish direct database connections…

How to fix or mitigate CVE-2026-16503?

Within 24 hours, identify all instances running the VPS.org one-click Supabase template and immediately restrict network access to port 5432 (disconnect from internet or implement firewall denial rules). Within 7 days, change the PostgreSQL default 'postgres' password to a strong, unique credential; implement network and host-level firewall rules restricting port 5432 to authorized internal systems only; and audit PostgreSQL access logs for unauthorized connection attempts during the exposure window. Within 30 days, conduct a forensic review of database activity logs to identify what data was accessed, complete any required compliance notifications, and migrate all affected instances to a hardened Supabase deployment or alternative database platform with secure-by-default configuration.

Supabase Template CVE-2026-16503

EUVD-2026-51547 CRITICAL

Initialization of a Resource with an Insecure Default (CWE-1188)

2026-07-31 certcc

GHSA-j3fc-fx73-7qv7

Authentication Bypass Docker PostgreSQL Supabase Template

9.1

CVSS 3.1 · Vendor: certcc

Severity by source

Vendor (certcc) PRIMARY

9.1 CRITICAL

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

vuln.today AI

9.8 CRITICAL

Known default password on a network-exposed port gives unauthenticated superuser DB access (PR:N/AC:L/AV:N), enabling read, modification, and destruction of data, so C/I/A all High.

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

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

Primary rating from Vendor (certcc).

CVSS VectorVendor: certcc

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

High

Integrity

High

Availability

None

Lifecycle Timeline

Analysis Generated

Aug 03, 2026 - 20:37 vuln.today

CVSS changed

Aug 03, 2026 - 18:22 NVD

9.1 (CRITICAL)

CVE Published

Jul 31, 2026 - 15:18 cve.org

UNKNOWN (no severity yet)

CVE Published

Jul 31, 2026 - 15:18 cve.org

CRITICAL 9.1

DescriptionCVE.org

Deployment of the VPS.org one-click Supabase template deploys a PostgreSQL instance that is published on all interfaces (0.0.0.0:5432) with a default database password set to "postgres". Because Docker installs its own iptables rules, this exposure bypasses a standard host UFW configuration.

AnalysisAI

Exposure of a default-credentialed PostgreSQL database in the VPS.org one-click Supabase template allows remote attackers to connect directly to the database on 0.0.0.0:5432 using the well-known default password 'postgres', gaining full read/write access. The flaw stems from insecure default initialization combined with Docker's iptables rules overriding host UFW firewall policy, so operators who believe UFW protects the port are silently exposed. No public exploit has been identified at time of analysis, and EPSS is low (0.14%, 4th percentile), but SSVC rates the technical impact as total and exploitation as automatable.

Technical ContextAI

The affected component is a one-click deployment template (cpe:2.3:a:vps.org:supabase_template) that stands up Supabase, an open-source Firebase alternative built on PostgreSQL. The root cause maps to CWE-1188 (Insecure Default Initialization of a Resource): the template ships PostgreSQL bound to all interfaces (0.0.0.0:5432) with the vendor default database password 'postgres' left unchanged. A key aggravating factor is Docker networking behavior - the Docker daemon writes its own iptables rules directly into the nat/filter tables, which are evaluated before UFW's rules, so a published container port remains reachable from the internet even when UFW is configured to deny it. This is a well-documented interaction between Docker and UFW rather than a bug in either firewall.

RemediationAI

No vendor-released patch identified at time of analysis, so remediation is configuration-driven and should be applied immediately. First, change the PostgreSQL 'postgres' superuser password to a strong unique value (ALTER USER postgres WITH PASSWORD ...) - this closes the default-credential path with no functional side effects. Second, stop publishing the database on all interfaces: bind the container port to localhost (e.g. map 127.0.0.1:5432:5432 rather than 5432:5432) or remove the host port publication entirely so only other containers on the Docker network can reach it - side effect is that remote database clients will need an SSH tunnel or VPN. Third, because Docker's iptables rules bypass UFW, do not rely on UFW alone; instead use Docker's own controls (DOCKER-USER iptables chain rules to restrict source IPs, or set the daemon's iptables handling) to filter access to 5432 - note that editing the DOCKER-USER chain requires care to avoid breaking other container connectivity. Consult the CERT/CC note (https://kb.cert.org/vuls/id/243636) for vendor guidance and any updated template.