Supabase Disables TLS 1.2 CBC Ciphers Nov. 10: How to Fix It

Supabase is removing four legacy TLS 1.2 cipher suites from its project APIs on November 10, 2026, at the earliest. If your app, device, or server only supports those older CBC-mode ciphers, it will fail to connect to Supabase Auth, the Data API, Storage, Realtime, or Edge Functions once the change lands — even though nothing about your code or database changed. Supabase says fewer than 0.0001% of recent connections used these ciphers, but if yours is one of them, the fix is straightforward: update the client's TLS library or operating system so it can negotiate TLS 1.3 or one of the six cipher suites Supabase is keeping.

What's Actually Changing on Supabase's APIs

According to Supabase's official changelog, the company will stop offering four TLS 1.2 cipher suites that use CBC (cipher block chaining) mode on the HTTP APIs served from <project_ref>.supabase.co and any custom domains pointed at a Supabase project. The change was first announced on October 12, 2026, with affected customers notified by email on October 14. The removal itself is scheduled for November 10, 2026, though Supabase's own TLS policy page notes the date could shift based on customer feedback.

The scope is narrower than it might sound. This is not a change to which TLS protocol versions Supabase supports — it has accepted only TLS 1.2 and TLS 1.3 for years, with SSL 3.0, TLS 1.0, and TLS 1.1 already turned off. It is also not a change to every service Supabase runs. The four ciphers are being dropped only on the project-level HTTP APIs: Auth, the Data API (PostgREST), Storage, Realtime, and Edge Functions, because those all sit behind the same HTTP front door.

Which TLS 1.2 Ciphers Are Being Removed, and Which Stay

Supabase's TLS policy documentation spells out exactly which cipher suites are leaving and which ones remain available on TLS 1.2. Every suite being kept is an AEAD (authenticated encryption with associated data) cipher; every suite being dropped uses the older CBC construction.

On TLS 1.3, nothing changes: that protocol version only ever defined AEAD ciphers, so there was never a CBC-mode option to remove.

Why Supabase Is Dropping CBC-Mode Ciphers

Supabase frames this as routine hardening rather than a response to a specific incident. CBC-mode TLS 1.2 ciphers are a legacy category that the broader industry has been retiring for years in favor of AEAD-only configurations, which combine encryption and integrity checking in a single, better-understood operation. Supabase's own guidance has required TLS 1.2 or 1.3 for a long time already; this change simply narrows the list of acceptable cipher suites within TLS 1.2 to the AEAD subset, bringing every supported protocol version onto the same modern footing. Notably, TLS 1.3 itself — standardized by the IETF in RFC 8446 — never defined a CBC-mode option in the first place; AEAD ciphers were a requirement of the protocol from day one. Supabase's move effectively applies that same AEAD-only expectation retroactively to the subset of its traffic still negotiating TLS 1.2.

Because the overwhelming majority of traffic already negotiates an AEAD suite or TLS 1.3, Supabase expects the practical blast radius to be small. The company says it looked at live traffic across its fleet and found that under 0.0001% of connections in the run-up to the announcement used one of the four ciphers being removed.

Who Is Actually Affected

The affected population is narrow but not zero, and it skews toward exactly the kind of client that is easy to forget about. Based on Supabase's own description, you are more likely to be affected if your app talks to Supabase from:

• A device or browser running an end-of-life operating system that never received TLS stack updates.
• An embedded device, IoT gateway, or kiosk that has not been patched since it was deployed.
• An older HTTP client library, mobile WebView, or language runtime with a TLS implementation that was never upgraded to prefer AEAD ciphers.
• A corporate proxy, legacy load balancer, or security appliance sitting between end users and Supabase that only negotiates CBC-mode suites.

Supabase says it is reaching out directly to the owners of projects whose traffic included connections using the four retiring ciphers. If you have not received that notice, your project's current traffic almost certainly does not depend on them — but "current" is the operative word, since a client that connects rarely (an old mobile build still in app stores, a rarely-restarted IoT fleet) might not show up in a recent traffic sample.

It is also worth remembering that "affected" does not mean "insecure." A client still negotiating a CBC-mode suite today is not under active attack; it is simply relying on an older, more conservative part of the TLS 1.2 specification that the rest of the ecosystem has been phasing out for other reasons, including implementation complexity and the difficulty of verifying padding-oracle resistance across every TLS library. Supabase's change is about standardizing on a smaller, better-audited set of ciphers across its fleet, not about responding to an exploit against Supabase customers specifically.

What's Not Affected

It's worth being precise about the boundaries here, because Supabase projects have several distinct connection paths and only one of them is in scope:

• Direct Postgres connections to your database (port 5432) are untouched by this change.
• Connection pooler traffic (Supavisor/PgBouncer-style pooled connections) is untouched.
• The Management API at api.supabase.com, used for provisioning and project configuration, is untouched.
• Any client already using TLS 1.3, or a TLS 1.2 connection that negotiates one of the six AEAD suites listed above, sees no change in behavior at all.

If your database layer runs on Supabase's documented TLS policy and you connect through typical modern tooling (recent Postgres drivers, current browsers, a supported mobile OS), this deprecation is unlikely to touch you. For broader context on how Postgres itself handles end-of-support timelines, our explainer on PostgreSQL's end-of-life schedule covers a related but separate kind of deadline Supabase-hosted databases can also run into.

How to Check If Your App Will Break

Supabase's guidance for preparing is simple and client-side: you need to find out which TLS ciphers your actual clients negotiate today, not which ones they theoretically support. Practical steps include:

1. Inventory your clients. List every distinct type of client that calls your project's default or custom domain: web app, mobile app builds still in the wild, server-to-server integrations, embedded or IoT devices, and any third-party service that calls your Supabase URL on your behalf.
2. Check each one's TLS stack. Look at the operating system version, the HTTP client library, and the language runtime's TLS implementation for anything old enough to lack AEAD cipher support.
3. Test against a client that disables CBC suites. If you can configure a test environment to offer only the six surviving TLS 1.2 ciphers plus TLS 1.3, and your production client still connects cleanly, you are in good shape.
4. Watch for the email. If Supabase's traffic analysis already flagged your project, you should have received direct notice; treat that as a strong signal to act before November 10.

How to Fix It Before November 10

If you do find an affected client, the fix is on your side, not Supabase's — there is no server-side opt-out or extension built into the API itself:

• Update the OS or TLS library. Most mainstream operating systems and HTTP stacks have supported AEAD ciphers and TLS 1.3 for years; the fix is usually a routine update rather than a code change.
• Upgrade the client runtime. For mobile apps, that may mean shipping a new build with an updated networking library, since you cannot patch TLS behavior in an app already installed on a user's device without a release.
• Reconfigure middleboxes. If a corporate proxy or legacy load balancer is the actual TLS endpoint talking to Supabase, its administrator needs to enable a modern cipher suite or TLS 1.3 support.
• Ask for help if you're stuck. Supabase explicitly invites affected teams to open a support ticket specifying the client and the cipher it needs if an update isn't realistic before the deadline.

None of this requires touching your database schema, your API keys, or your application logic — it is purely about the TLS handshake layer between a client and Supabase's edge.

Two More Supabase Breaking Changes to Watch This Month

The TLS cipher change lands in the middle of a busier-than-usual month of breaking changes across Supabase's tooling, which is worth knowing about if you maintain a Supabase project on more than one front:

Supabase CLI v3 shipped on November 2, 2026, and became the default install on npm, Scoop, Linux packages, and supabase/setup-cli immediately, with Homebrew following a day later. The headline change is that database and storage commands now target your local stack by default; reaching a hosted project requires an explicit --remote flag, and any command that would modify a hosted project now asks for confirmation first (or requires --yes in CI). Teams running unattended deploy scripts or AI coding agents against Supabase should check the CLI v3 changelog before their next pipeline run, since a script written for v2 defaults can silently target the wrong stack under v3.

supabase-flutter v3 is further out but on a tight timeline: the changelog entry went up November 6, 2026, with the stable 3.0.0 release planned for November 11 — the day after the TLS cipher deadline. It reworks the Dart and Flutter client libraries around generated, typed queries instead of untyped maps, and renames several sub-packages (gotrue, realtime_client, storage_client, and functions_client become supabase_auth, supabase_realtime, supabase_storage, and supabase_functions). Teams can already try the prereleases on pub.dev and read the full supabase-flutter v3 changelog ahead of the stable cutover.

None of these three changes are related to each other technically, but they share a theme: Supabase is tightening defaults and retiring legacy behavior across its stack in the same two-week window, which is worth factoring into any migration or release planning you're doing in November.

What's Next

Supabase has been explicit that November 10 is "at the earliest," meaning the company could still push the CBC-cipher removal later if enough customer feedback comes in before then. Teams that have not checked their client inventory should treat the date as real regardless, since Supabase's own language leaves room for the deadline to move but not to disappear entirely.

Beyond this specific change, the broader signal for anyone building on Supabase is that TLS 1.2 support itself is not going away yet — only the weaker cipher suites within it are. If you are choosing or re-evaluating a backend platform entirely, rather than just patching TLS settings on an existing one, our comparison of Railway, Render, and Fly.io walks through how those platforms' connection and TLS defaults compare for teams weighing alternatives. For most existing Supabase users, though, the practical takeaway is narrower: check your client list, update anything still relying on CBC-mode TLS 1.2, and the November 10 cutover should be invisible.

Written byFelix Moreau

Felix Moreau writes Pandromeda's software coverage and how-to guides. He covers Windows, macOS and Linux updates, the apps people rely on, emulators and developer tools, and turns official documentation into clear, numbered steps that work on the current version.

More from Felix MoreauAll Software & Guides coverage