Supabase Self-Hosting from CVE Detection to Patch — GoTrue Auth Bypass, Docker Compose Path Traversal, and Trivy Scan Examples

I'll admit I once ran six containers in their initial install state for months, telling myself "it's only on the internal network, it'll be fine." Then I came across a case where 170+ Supabase apps had exposed data externally due to missing RLS settings, and I realized just how flimsy "internal network" is as a line of defense. If you're using Supabase Cloud, the Supabase team patches things automatically — but the moment you run it yourself with Docker Compose, you're responsible for tracking all six or more images yourself: PostgreSQL, Kong, GoTrue, PostgREST, Realtime, and Studio.

By the end of this post, you'll be able to scan and prioritize CVEs in your running stack in under 30 minutes. Focusing on the major CVEs disclosed between 2025 and 2026, I've put together a guide tailored for those running Supabase themselves via Docker Compose — covering everything from vulnerability detection to applying actual patches and building a system to prevent recurrence.

From auth bypass to a Path Traversal that can touch the host filesystem with a single docker compose ps — these vulnerabilities are closer than you might think.

Core Concepts

CVE, CVSS, EPSS, KEV — Four Metrics That Determine Priority

These terms tend to get jumbled together in security discussions, but understanding them once makes reading CVE reports much easier.

CVE (Common Vulnerabilities and Exposures): A unique identifier assigned to publicly disclosed security vulnerabilities. Format: CVE-year-number. Severity is expressed via CVSS score (0–10); 7.0 or above is High, 9.0 or above is Critical.

CVSS (Common Vulnerability Scoring System): A score that aggregates the characteristics of the vulnerability itself (network accessibility, attack complexity, whether user interaction is required, etc.). It measures "how bad is this vulnerability" but does not reflect "how likely is an attack right now."

EPSS (Exploit Prediction Scoring System): A metric that predicts the probability (0–1) that a CVE will actually be exploited. A high CVSS with low EPSS means immediate threat likelihood is low; conversely, a low CVSS with high EPSS calls for a quick response.

KEV (Known Exploited Vulnerabilities): A list maintained by CISA of CVEs confirmed to have been exploited in the wild. Regardless of CVSS score, inclusion in KEV should be treated as the highest-priority patch signal.

By combining these four, you can read situations like "low CVSS but listed in KEV" or "high CVSS but EPSS of 0.001" — which is what lets you pick out what actually needs attention right now from dozens of CVEs.

CVE Layers in the Supabase Docker Stack

Vulnerabilities arise across three main layers.

A situation that comes up frequently in practice: the application image is up to date, but the base image's openssl is outdated. Blind spots like this appear when you're not monitoring all three layers simultaneously.

The Basic Response Workflow

It looks complex, but the basic flow is simple.

1. Scan: Use Trivy or Grype to identify which CVEs exist in your current images
2. Prioritize: Evaluate using CVSS + EPSS + KEV listing status
3. Apply patch: Update the image tag or apply a temporary mitigation
4. Verify: Rescan after patching to confirm the vulnerability is resolved

Practical Application

Example 1: CVE-2026-31813 — Emergency Response to GoTrue Auth Bypass

This applies if you're using Apple or Azure OIDC login and your GoTrue version is below v2.185.0. It's an authentication bypass vulnerability where a maliciously crafted ID token can be used to issue an arbitrary user session.

The CVSS score of 4.8 (Medium) makes it easy to underestimate — but there's a reason it's low. CVSS evaluates attack conditions holistically, and this vulnerability only manifests in specific configurations where the Apple or Azure OIDC provider is enabled. It's not "open to everyone" but rather "only opens with a specific configuration," which is why the score is low. That's why it's more important to first ask "does our environment meet the conditions?" than to focus on the CVSS score. If it does, patching immediately is the better call.

# Replace only the GoTrue image with the latest version
docker pull supabase/gotrue:v2.185.0
 
# Leave other services as-is and restart only auth
docker compose up -d --no-deps auth
 
# Verify version (run the binary directly instead of relying on image metadata)
docker run --rm supabase/gotrue:v2.185.0 --version

If an immediate patch isn't feasible, you can apply a temporary mitigation at the network level. Pay attention to the order of iptables rules — ACCEPT must come before DROP.

# Allow internal network (10.0.0.0/8), block everything else
# Use -I to insert ACCEPT at the top of the chain, then -A to append DROP at the end
iptables -I INPUT -p tcp --dport 9999 -s 10.0.0.0/8 -j ACCEPT
iptables -A INPUT -p tcp --dport 9999 -j DROP

If ACCEPT and DROP are in the wrong order, the internal network gets blocked too. Disabling the Apple and Azure providers in the Supabase dashboard under Authentication settings, alongside the temporary mitigation, adds an additional line of defense.

Example 2: CVE-2025-62725 — Patching Docker Compose Path Traversal

Our team first encountered this CVE during a routine docker compose config run. In Docker Compose versions prior to v2.40.2, insufficient path validation in OCI artifact layer annotations allowed arbitrary file writes to any location on the host filesystem (CVSS 8.9, High).

What makes it especially dangerous is that it can be triggered even during read-only commands like docker compose ps or docker compose config. Simply having a docker-compose.yml file that references a malicious OCI image is enough to create a dangerous situation.

# Check the current Docker Compose version
docker compose version
 
# Docker Desktop users: this is resolved by updating Desktop
# For standalone installations on Linux: auto-detect architecture and update
ARCH=$(uname -m)
curl -SL "https://github.com/docker/compose/releases/download/v2.40.2/docker-compose-linux-${ARCH}" \
  -o /usr/local/bin/docker-compose
chmod +x /usr/local/bin/docker-compose
 
# Verify version after update
docker compose version
# Must be Docker Compose version v2.40.2 or higher

Using uname -m to dynamically detect the architecture works identically for both x86_64 (Intel/AMD) and aarch64 (ARM, M1/M2 Mac, Graviton EC2).

Example 3: Scanning Supabase Images with Trivy

Trivy is the most widely used container scanner, but there's one important incident worth highlighting. In March 2026, the Trivy image on Docker Hub (versions 0.69.4–0.69.6, including the latest tag) suffered a supply chain compromise. If your CI/CD pipeline is using trivy:latest without review, this warrants attention.

# Pin to a specific digest (avoid the latest tag)
# docker.io/aquasec/trivy@sha256:<verified_digest>
 
# How to check the image tag of the currently running postgres container
docker inspect --format '{{index .RepoTags 0}}' $(docker ps -q -f name=supabase_db)
# Or read the version from the .env file
POSTGRES_VERSION=$(grep POSTGRES_IMAGE .env | cut -d= -f2 | cut -d: -f2)
 
# Scan the Supabase postgres image
trivy image supabase/postgres:15.6.1.143
 
# CI/CD integration: fail the build only on CRITICAL and HIGH
trivy image \
  --severity CRITICAL,HIGH \
  --exit-code 1 \
  supabase/gotrue:v2.185.0
 
# Generate a JSON report (for later analysis and archiving)
trivy image \
  --format json \
  --output trivy-report.json \
  supabase/studio:latest

Running Trivy and Grype in parallel can compensate for gaps caused by differences between their vulnerability databases. It genuinely does happen that the two scanners catch different CVEs.

# Cross-verify the same image with Grype
grype supabase/gotrue:v2.185.0
 
# SBOM-based scan: enumerates the full package manifest without analyzing image layers,
# which can detect packages installed at runtime — more thorough than a standard scan
syft supabase/postgres:15.6.1.143 -o json | grype

Example 4: Runtime Attack Detection with CrowdSec

Patching alone isn't enough. Runtime protection is necessary to defend against zero-day vulnerabilities and attacks that exploit misconfiguration. CrowdSec's supabase-compose collection parses Kong and PostgreSQL logs to detect SQL injection, XSS, and brute-force attacks in real time.

# Install the supabase-compose collection
# Includes Kong log parsers + SQL injection / XSS / brute-force detection scenarios
cscli collections install crowdsecurity/supabase-compose
 
# Verify installed collections
cscli collections list
 
# View currently detected attacks
cscli decisions list

Attaching CrowdSec to the Supabase stack as a sidecar means adding a service to docker-compose.yml.

services:
  crowdsec:
    image: crowdsecurity/crowdsec:latest
    volumes:
      - ./crowdsec/acquis.yaml:/etc/crowdsec/acquis.yaml
      - /var/log/kong:/var/log/kong:ro  # Adjust to match the Kong container's volume mount path
      - crowdsec-db:/var/lib/crowdsec/data
    environment:
      COLLECTIONS: "crowdsecurity/supabase-compose"
    restart: unless-stopped
 
volumes:
  crowdsec-db:

The Kong log collection path needs to be adjusted to match the actual volume mount path of your Kong container. After applying, connecting iptables/nftables or a Cloudflare Bouncer enables automatic blocking of detected IPs.

Pros and Cons

Advantages

Disadvantages and Caveats

The Most Common Mistakes in Practice

1. Not configuring RLS immediately after creating a table — Supabase creates tables with RLS disabled by default. The 2025 Security Retro added automatic RLS enforcement via Event Trigger, but existing tables are not retroactively affected. You can see all tables missing RLS at a glance in the Supabase dashboard under the Security tab > Security Advisor.

2. Pinning the scanner image to the latest tag — As with the Trivy Docker Hub supply chain compromise, the scanner itself can become a vector for executing malicious code. In CI/CD pipelines, it's safer to pin using trivy@sha256:<digest> instead of trivy:latest.

3. Leaving Docker Compose itself unupdated for a long time — It's common to update application images while neglecting Docker Compose itself. Since Docker Compose can itself be an attack vector, as with CVE-2025-62725, it's worth keeping it at v2.40.2 or higher.

Closing Thoughts

Security for self-hosted Supabase is not "set it and forget it" — it's an operational problem of consistently running the scan-evaluate-patch-verify cycle.

Three steps you can start right now:

1. Start by scanning your current images. First check your running postgres image tag (docker inspect --format '{{index .RepoTags 0}}' $(docker ps -q -f name=supabase_db)), then use trivy image --severity CRITICAL,HIGH supabase/postgres:<tag> to narrow results to CRITICAL/HIGH — even with many findings, that makes them much easier to review.

2. Subscribe to Supabase vendor alerts on OpenCVE. Go to https://app.opencve.io/cve/?vendor=supabase and add supabase under the Vendors tab — you'll receive email notifications when new CVEs appear, which greatly reduces the effort of manually checking NVD.

3. Check your Compose version with docker compose version, and if it's below v2.40.2, updating is the fastest fix. It can be done without service interruption and is the most reliable way to block CVE-2025-62725, which can be triggered even by read-only commands.

References

• Supabase Security Retro: 2025 | Supabase Official Blog
• Self-Hosting with Docker | Supabase Docs
• Security at Supabase
• CVE-2026-31813: Supabase Auth Bypass Vulnerability | SentinelOne
• CVE-2025-62725 Detail | NVD
• CVE-2025-62725: From "docker compose ps" to System Compromise | Imperva
• Docker fixes serious vulnerabilities in Compose and Desktop Installer | Techzine
• Hardening self-hosted Supabase with CrowdSec | CrowdSec Official Blog
• Trivy supply chain compromise: What Docker Hub users should know | Docker Official Blog
• Supabase CVEs and Security Vulnerabilities | OpenCVE
• Supabase: Products and vulnerabilities | CVE Details
• Security testing of your Supabase projects | Supabase Docs