Thank you for helping keep the Supabase CLI and its users safe.

Please report suspected vulnerabilities through our HackerOne program: https://hackerone.com/supabase. Please do not open public GitHub issues or pull requests for security problems.

This repository contains the Supabase CLI. It runs on a developer's machine or in CI, starts the local development stack (supabase start), manages migrations, deploys and downloads Edge Functions, and talks to the hosted Supabase Management API on the user's behalf. There is no hosted CLI: the target is the CLI and the local stack it starts on your own machine. Issues in the hosted Management API itself are not tracked in this repository. Report them through HackerOne as usual and say which API you tested.

In general, we want to hear about anything that lets an attacker get a CLI user's credentials, act as that user, or run code or write files on their machine without the user choosing to: obtaining a Supabase access token or project secret the attacker should not have, redirecting the CLI's credentials to a server the user did not choose, connecting to a database or API without properly verifying who is on the other end, or turning data that the CLI downloads into a write outside the location it was meant for. The attacker should not need the victim's credentials or a shell on the victim's machine, and the problem should be present in a released version of the CLI used as documented.

Examples of what this includes (these are illustrations, not a complete list):

• Theft of a CLI access token. Getting a user to complete a CLI login, or any other flow, in a way that hands the resulting access token to the attacker.
• Writes outside the intended directory. Content the CLI downloads (for example a function bundle or its file paths) that makes the CLI create or overwrite files outside the project directory it was asked to write to. Show the file actually written to a location of the attacker's choosing.
• Secret exposure. An access token, database password or project secret key written to output, logs or local files in a place where the CLI is meant to redact or omit it.
• Credentials sent to the wrong place. Project or repository content that the CLI reads, such as a .env file or config.toml, that changes where the CLI sends its access token or which server it talks to, without the user choosing that.
• Server identity not verified. A CLI connection that carries credentials or data, such as to the project database or the Management API, that does not verify the server's TLS certificate and hostname, or that silently accepts a weaker mode than the user asked for. This is in scope even though exploiting it needs a network position between the user and the server: the CLI is expected to protect those connections, so it is not the MITM exclusion below. Show which command connects, what the attacker intercepts, and the CLI version.

Reports that rely on the behavior below will normally be closed as informative or not applicable.

By design

• The local development stack is for your own workstation. The stack that supabase start runs is meant for local development. It has no authorization or isolation layer suitable for the internet, and our documentation says it should not be exposed publicly. Reports against a local stack that someone has made reachable from the internet are reports about that deployment, not about the CLI. If you believe the same issue affects a self-hosted deployment, reproduce it using the self-hosting guide and say so.
• The CLI uses credentials that are already present. If an access token is set in the environment (SUPABASE_ACCESS_TOKEN) or saved by an earlier supabase login, commands that call the Management API will use it without prompting. A command that "works without logging in" on a machine or agent session that already holds a token is not an authentication bypass. Retest in a clean environment.
• The CLI acts with its user's privileges. Running SQL, pushing migrations, deploying functions or managing secrets for projects the token can reach is the purpose of the tool.

Prerequisites that make the attack pointless

• The attacker needs the victim's access token, database password or project secret key.
• The attacker already has a shell, or write access to the user's home directory, on the victim's machine.
• The attacker needs owner or admin rights on the victim's project or organization, and the action is one those rights already allow.

Reports that are not evidence of a flaw

• Credentials in the git history of this repository that are revoked or no longer valid, including values in old or commented-out config templates. Show that a credential is live and grants access.
• Static analysis or scanner output with no working proof of concept against a released CLI version.

These are excluded program-wide (see also https://supabase.com/.well-known/security.txt). They are repeated here so you do not need to leave this repository to find them.

• Clickjacking on pages with no sensitive actions.
• Unauthenticated, logout and login CSRF.
• Attacks requiring MITM or physical access to a user's device.
• Attacks requiring social engineering.
• Any activity that could lead to the disruption of our service (DoS). This means volumetric attacks, load testing and flooding. A vulnerability in our code that lets an unprivileged attacker crash a service or exhaust resources for other users or tenants is in scope. Denial of service that only affects the attacker's own project, or that needs admin or owner privileges, is not.
• Content spoofing and text injection issues without showing an attack vector, or without being able to modify HTML/CSS.
• Email spoofing.
• Missing DNSSEC, CAA or CSP headers.
• Lack of Secure or HttpOnly flags on non-sensitive cookies.
• Dead links.
• User enumeration.

These are described in our public documentation. Please check them before reporting.

• Local development is not self-hosting. The local development guide and the self-hosting guide describe different setups. The local stack is not intended to be exposed outside the developer's machine.
• SUPABASE_ACCESS_TOKEN can be set in the environment to authenticate the CLI without an interactive login, for example in CI.

We accept findings against released CLI versions used as documented. We treat findings that need the user to misconfigure their environment first, such as by exposing the local stack to a network, changing its config.toml defaults, or running a modified CLI, as lower severity. Label your report as described in the next section.

• Say what you tested, at the top of the report and in the title. Use one of these labels, for example [Local CLI] ... in the title and a "Target" line at the start of the description:

  • Local CLI, default configuration: a released CLI version, and the local stack it starts, used exactly as our documentation describes with the default config.toml. Include the CLI version, how you installed it, and your operating system.
  • Local CLI, custom configuration: you changed config.toml, exposed the local stack beyond your machine, built from a branch, or modified code. List every change and why. We triage these lower unless the setting is one we recommend or document.

  Reports that do not say which of the two they are about are slower to triage, and are often closed with a request to retest. A finding that works only on a custom configuration is not a finding against a default install.

• Test a real setup. Run the released CLI binary, not only code you copied out of it. Code reading alone is rarely enough. Static analysis findings need a working proof of concept, and the code you cite must match the current repository.

• Give a short, runnable PoC. The exact commands, any files or server responses the attacker controls, and the output showing the impact, such as the file written or the token received.

• State the attacker's starting position. What do they control (a function in an organization the victim belongs to, a web page, a leaked key)? What does the victim have to run? Reports that quietly assume a token already in the environment, or a shell on the victim's machine, are our most common reason to close.

• Name the boundary you crossed. Which user, project or organization could not do this before, or which location could the attacker not write to? If nothing was crossed, it is probably a hardening suggestion.

• Check the docs and this file first. If the behavior is documented, explain why the documented design still fails.

• Include versions. The CLI version, installation method, operating system, and whether any SUPABASE_* environment variables were set.

• One issue per report. Link variants of the same root cause instead of filing each variant separately.

• Do not send unreviewed AI output. Reports that were not reproduced by a human and that ignore the documentation are closed. AI-assisted analysis is fine when you have verified the result. If an AI agent ran the CLI for you, say whether it had logged in or had a token.

• Respond to follow-up questions. Reports that go quiet after we ask for a reproduction are closed.

We rate severity by realistic impact on a default setup. Issues that need user interaction the user can see, a deliberately exposed local stack, or an existing privilege are rated lower even when they are valid, and we may fix them as defense in depth.

These are our program-wide rules. They also apply to AI agents and automated tools acting on your behalf.

Testing

• Do not run automated scanners against other customers' projects. Scanners can run up costs for our users, can disrupt services, and our own security systems cannot tell hostile reconnaissance from research. If you want to run an automated scanner, notify security@supabase.com first and run it only on your own Supabase project.
• Do not attack projects that belong to other customers.
• Do not take advantage of a vulnerability you find, for example by downloading more data than necessary to demonstrate it, or by deleting or modifying other people's data.

Disclosure

• Do not reveal the problem to others until we have researched and fixed it and informed affected customers.
• If you want to share your research publicly (a conference, a blog or any other public forum), send us a draft for review and approval at least 30 days before the publication date. Do not include data about Supabase customer projects, customers' data, or information about Supabase employees, contractors or partners.

What we promise

• We will respond to your report within 5 business days with our evaluation and an expected resolution date.
• If you have followed these instructions, we will not take legal action against you in regard to the report.
• We will handle your report with strict confidentiality and will not pass on your personal details to third parties without your permission.
• We will keep you informed of our progress.
• In public information about the problem, we will name you as the discoverer unless you prefer otherwise.