Skip to content

Supabase's October 30 change: new public tables need a grant for Data API access. What to doSupabase's October 30 change is live: new public tables need a grant for Data API access. What broke and how to fix it

24 tools · 139 fixes · 42 issue guides · Sources: Supabase, GitHub, postgresql.org, Vercel + 53

Incident feed

A crafted dyad:// link could connect a Dyad user's apps to an attacker's Supabase or Neon account

On October 18, 2026, CVE-2026-111988 was published for the Dyad AI app builder through 1.16.0. Dyad accepted Supabase and Neon sign-in return links it had not started, so one crafted dyad:// link could attach a user's apps to a database account the attacker controls. VulDB (the CNA) rates it Medium, 4.3, and Dyad's own advisory rates it High, 8.3. It is fixed in 1.17.0 (advisory published September 28, 2026).

Share link · Share on X

What was reported

CVE-2026-111988 was published October 18, 2026. The NVD record has status Received, so NVD has not analyzed this CVE yet. The description it carries from VulDB, the CNA, says Dyad up to 1.16.0 has a cross-site request forgery flaw in its OAuth callback handler that can be triggered remotely, and that upgrading to 1.17.0-beta.1 resolves it. VulDB names the patch commit 39fbae87b38573616a1a3b152cdb292787bb1109. VulDB (the CNA) assigns CWE-352 and CWE-862 and rates it CVSS 3.1 score 4.3, severity Medium, vector CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N. That v1.17.0-beta.1 prerelease was published September 24, 2026 (Pacific time). v1.17.0, published September 28, 2026 (Pacific time), is the first stable release with the fix. Both releases contain pull request #4433 and that commit.

Dyad's own advisory, GHSA-pqj5-w36j-2839, was published September 28, 2026 and rates the same bug High, CVSS 3.1 score 8.3. It lists CWE-346 and CWE-352. It says Dyad accepted the dyad://supabase-oauth-return and dyad://neon-oauth-return deep links without checking that they belonged to a connection the user had started, and read the access token, refresh token, and expiry straight from the URL. Dyad accepted any Supabase token that Supabase considered valid, whatever account it belonged to, and added the attacker's Supabase organization without asking. It also overwrote an existing Neon connection. The only prompt was the operating system's "Open Dyad?" dialog.

The advisory says databases the victim creates or connects after that live in the attacker's account, so the attacker can read and change that app data, which may include end users' personal information, and can break a working connection. It says the attacker does not get the victim's own Supabase or Neon credentials or existing data. Versions through 1.16.0 are affected. The fix first shipped in the v1.17.0-beta.1 prerelease on September 24, 2026 (Pacific time). v1.17.0, published September 28, 2026 (Pacific time), is the first stable release with the fix, and both releases contain pull request #4433 and commit 39fbae87b38573616a1a3b152cdb292787bb1109. The advisory says the fix shipped in 1.17.0, together with an update to Dyad's hosted OAuth proxies: each connection now carries a single-use flow identifier, and callbacks that are missing, unknown, expired, or already used are rejected. If you may have opened such a link, upgrade, disconnect and reconnect Supabase and Neon, and check that the projects and organizations Dyad shows belong to you.

How to prevent it

Update Dyad to 1.17.0 or later. If you may have opened such a link, disconnect and reconnect Supabase and Neon in Dyad's settings and check that every project and organization it lists is yours. Until you update, do not open dyad:// links from anyone else. The advisory says no setting blocks the attack on affected versions.

Sources

Related

The weekly fix

The weekly fix: 3 real security mistakes in vibe-coded apps and how to fix them, every Tuesday.

One email, every Tuesday. A welcome note follows the first signup.