CVE-2026-16503: VPS.org Supabase Auth Bypass Vulnerability

CVE-2026-16503 Overview

CVE-2026-16503 affects the VPS.org one-click Supabase deployment template. The template provisions a PostgreSQL instance bound to all network interfaces (0.0.0.0:5432) with the default database password set to postgres. Because Docker installs its own iptables rules during container startup, this exposure bypasses standard host-based Uncomplicated Firewall (UFW) configurations that operators typically rely on.

Any attacker on the network can connect to the exposed PostgreSQL service and authenticate using the well-known default credential. This provides direct read and write access to application data hosted in the Supabase backend.

Critical Impact
Unauthenticated network attackers can access PostgreSQL databases deployed via the VPS.org Supabase template using the default password postgres, bypassing host UFW rules.

Affected Products

VPS.org one-click Supabase deployment template
Bundled PostgreSQL container instance
Deployments relying on host UFW for network isolation

Discovery Timeline

2026-07-31 - CVE-2026-16503 published to the National Vulnerability Database
2026-08-03 - Last updated in NVD database

Technical Details for CVE-2026-16503

Vulnerability Analysis

The issue is an insecure default configuration classified under [CWE-1188] (Initialization of a Resource with an Insecure Default). The one-click Supabase template deploys the PostgreSQL container without altering the shipped default credentials and without restricting the port binding to the loopback interface or an internal Docker network.

Operators deploying the template inherit a database that accepts authentication with the username postgres and password postgres. The credential is publicly documented and trivially guessed. Combined with an unrestricted bind address, the database is reachable from any host that can route to port 5432 on the VPS.

The secondary defect is a firewall bypass caused by Docker's default networking behavior. Docker inserts rules into the DOCKER and DOCKER-USER chains ahead of rules managed by UFW. Administrators who explicitly deny inbound traffic to port 5432 in UFW still see the port reachable because Docker's iptables rules take precedence.

Root Cause

The root cause is two-fold. First, the template ships a widely known default credential without forcing a rotation during provisioning. Second, the container binds PostgreSQL to 0.0.0.0 rather than 127.0.0.1 or a private Docker network, exposing the service beyond the host boundary.

Attack Vector

Exploitation requires no authentication, no user interaction, and no local access. An attacker scans the internet for hosts responding on TCP port 5432, connects with a standard PostgreSQL client, and authenticates as postgres with the password postgres. Successful authentication grants full database privileges, enabling data theft, modification, or destruction of Supabase-managed content. Refer to the CERT Vulnerability Advisory #243636 for additional technical detail.

Detection Methods for CVE-2026-16503

Indicators of Compromise

Inbound TCP connections to port 5432 from external IP addresses in host or cloud provider flow logs
PostgreSQL authentication events for the postgres role originating from non-application source addresses
New roles, extensions, or large COPY or pg_dump operations executed by the postgres user
Unexpected outbound connections from the database container after initial deployment

Detection Strategies

Enumerate listening sockets on the host with ss -tlnp and confirm no container exposes 5432 on 0.0.0.0
Inspect Docker port mappings using docker ps and validate that PostgreSQL is bound to 127.0.0.1 or a private network
Run external port scans against the VPS from an off-host location to verify port 5432 is not reachable
Review PostgreSQL logs (pg_log) for successful logins from unfamiliar client IP addresses

Monitoring Recommendations

Alert on any successful authentication to the postgres superuser role from outside the application subnet
Monitor iptables rule changes and container restarts that may reintroduce the exposed binding
Ingest PostgreSQL and Docker daemon logs into a central data lake for correlation with network telemetry

How to Mitigate CVE-2026-16503

Immediate Actions Required

Rotate the PostgreSQL postgres account password to a strong, unique value and update all dependent Supabase services
Reconfigure the container to bind PostgreSQL to 127.0.0.1:5432 or attach it to an internal Docker network only
Audit existing deployments for signs of unauthorized access, unexpected roles, or data exfiltration
Apply cloud provider security group rules that block inbound traffic to port 5432 at the network edge

Patch Information

No vendor patch is referenced in the advisory. Remediation requires operator action to modify the deployment configuration. Consult the CERT Vulnerability Advisory #243636 for vendor coordination status.

Workarounds

Use DOCKER-USER chain rules to explicitly drop inbound traffic to port 5432 from external sources, since UFW alone is insufficient
Publish only the Supabase HTTP API and Studio interfaces, keeping the database socket private to the host or a Docker network
Replace the shipped credential during first boot with a provisioning script or environment variable override before starting the container

bash

# Restrict PostgreSQL to loopback and drop external traffic via DOCKER-USER
docker run -d --name supabase-db \
  -p 127.0.0.1:5432:5432 \
  -e POSTGRES_PASSWORD="$(openssl rand -base64 32)" \
  supabase/postgres

# Ensure Docker cannot bypass firewall for port 5432
sudo iptables -I DOCKER-USER -p tcp --dport 5432 ! -s 127.0.0.1 -j DROP