By Supabase is removing four CBC-mode TLS 1.2 cipher suites from all project HTTP APIs on November 10, 2026. If your client cannot negotiate TLS 1.3 or one of Supabase’s retained GCM and ChaCha20 suites, the TLS handshake fails silently — no data, no helpful error, just a dropped connection. You have 12 days.
What Is Being Removed
The four cipher suites being removed are:
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
They share the same flaw: CBC-mode encryption with a separate MAC step, which creates the padding oracle attack surface that has plagued TLS for two decades. BEAST, Lucky 13, POODLE, and Vaudenay’s original 2002 exploit all trace back to this construction. TLS 1.3 removed CBC entirely. Supabase is finishing that job for its TLS 1.2 stack.
The removal hits Auth, the Data API, Storage, Realtime, and Edge Functions — every HTTP endpoint on .supabase.co. Direct Postgres connections, the pooler, and the Management API are unaffected.
Who Gets Broken
If your client speaks TLS 1.3, you’re fine. If it uses TLS 1.2 with GCM or ChaCha20 suites, also fine. The risk lives in:
- Old Java apps — Java 7 and earlier, or anything that didn’t explicitly enable TLS 1.3
- Legacy .NET Framework — .NET 4.5 and earlier; Windows Server 2012 and older lack TLS 1.3 entirely
- Embedded and IoT devices — hardware with frozen TLS stacks that shipped before 2018
- Pre-2019 Android SDKs — older mobile clients with restricted cipher negotiation
- Old curl or OpenSSL builds — anything running OpenSSL older than 1.1.1 (released 2018)
Modern runtimes — Node.js 18+, Python 3.7+, Go 1.13+, Java 11+, .NET 5+, Rust with OpenSSL 1.1+ — negotiate TLS 1.3 by default and are not affected.
How to Test Before November 10
Run this against your Supabase project endpoint:
# Force TLS 1.2 + CBC cipher — a successful handshake means you were relying on it
openssl s_client -connect <project-ref>.supabase.co:443 \
-tls1_2 \
-cipher 'ECDHE-RSA-AES128-CBC-SHA256'A successful handshake here is a warning: this cipher is negotiated by your client, and it stops working November 10. An immediate sslv3 alert handshake failure means your OpenSSL is already refusing this cipher — the good outcome.
Error signatures you’ll see if a client breaks after the cutoff:
- curl / Node.js / PHP:
sslv3 alert handshake failure - Chrome / Edge:
ERR_SSL_VERSION_OR_CIPHER_MISMATCH - .NET Framework / PowerShell:
Could not create SSL/TLS secure channel - Java:
SSLHandshakeException: Received fatal alert: handshake_failure - iOS / macOS:
An SSL error has occurred and a secure connection cannot be made
How to Fix It
The cleanest fix is updating the client’s OS, runtime, or TLS library to anything that supports TLS 1.3 or GCM-based TLS 1.2. For most teams, this is a dependency version bump. If you’re on a legacy pipeline that can’t be updated — a Jenkins agent on Windows Server 2012, or firmware you don’t own — route traffic through a reverse proxy that accepts the old cipher and forwards to Supabase over modern TLS.
If neither option is feasible before November 10, Supabase’s troubleshooting guide outlines the support escalation path. Contact them before the 9th, not after.
About That 0.0001%
Supabase notes that fewer than 0.0001% of connections used these ciphers in the past 30 days, framing this as minimal impact. That number deserves scrutiny. Supabase hosts hundreds of thousands of projects. Even 0.0001% of the platform’s total HTTP traffic represents thousands of API calls per day. More importantly, the developers in that fraction are running legacy stacks — the ones least likely to have monitoring that catches a TLS-layer failure, least likely to have read the changelog email sent October 14, and most likely to spend hours debugging a generic connection error before tracing it to a cipher suite removed weeks earlier.
Statistical rarity does not make the failure partial. If you’re in that fraction, every request to Auth, Storage, Realtime, and your Data API stops working at once on November 10.
Action Checklist
- Run the OpenSSL test against your Supabase project endpoint
- Audit legacy services — Java apps, .NET Framework, embedded clients — that connect to Supabase over HTTPS
- Update runtimes to Node.js 18+, Java 11+, .NET 5+, or any stack with TLS 1.3 support
- If you cannot update: configure a TLS-terminating reverse proxy before November 10
