{"id":"CVE-2026-78699","aliases":["EEF-CVE-2026-78699","EUVD-2026-68265","GHSA-6fqq-j9c4-5766"],"status":"published","title":"rename_tenant returns :ok on a failed rename, enabling cross-tenant access in AshPostgres","description":"Unchecked Return Value vulnerability in ash-project ash_postgres allows a user who can drive a tenant rename to a name that collides with an existing tenant's schema to have their tenant record repointed at that other tenant's live schema, gaining access to its data.\n\nAshPostgres.MultiTenancy.rename_tenant/3 issues the ALTER SCHEMA ... RENAME TO ... with the non-raising Ecto.Adapters.SQL.query/2, discards its {:ok, _} | {:error, _} result, and unconditionally returns :ok. PostgreSQL rejects the rename when the target schema already exists (and on insufficient privilege or lock timeout), but that failure never reaches the caller. The calling manage_tenant update action therefore sees success and commits the tenant row with the new name, which is the schema of a different existing tenant, so subsequent reads and writes for that tenant run against the other tenant's data.\n\nThis issue affects ash_postgres: from 0.25.0 before 2.13.0.","severity":{"version":"4.0","score":7.2,"vector":"CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N","level":"high","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-09","score":0.0016,"percentile":0.05234,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-252"],"published":"2026-08-30T15:13:23Z","modified":"2026-10-28T02:30:39Z","fixes":[{"ecosystem":"Hex","package":"ash_postgres","fixed_in":["2.13.0"],"sources":["osv"]}],"affected":[{"source":"osv","ecosystem":"Hex","package":"ash_postgres","ranges":[{"type":"SEMVER","events":[{"introduced":"0.25.0"},{"fixed":"2.13.0"}]}],"versions":["0.25.0","0.25.1","0.25.2","0.25.3","0.25.4","0.25.5","0.26.0","0.26.1","0.26.2","0.27.0","0.28.0","0.28.1","0.29.1","0.29.2","0.29.3","0.29.4","0.29.5","0.29.6","0.30.1","0.31.1","0.32.0","0.32.1","0.32.2","0.33.0","0.33.1","0.34.0","0.34.1","0.34.2","0.34.3","0.34.4","0.34.5","0.35.1","0.35.3","0.35.4","0.35.5","0.36.0","0.36.1","0.36.2","0.36.3","0.36.4","0.36.5","0.37.0","0.37.1","0.37.2","0.37.3","0.37.4","0.37.5","0.37.6","0.37.7","0.37.8","0.38.0","0.38.1","0.38.10","0.38.11","0.38.2","0.38.3","0.38.4","0.38.5","0.38.6","0.38.7","0.38.8","0.38.9","0.39.0-rc0","0.40.0-rc1","0.40.0-rc2","0.40.0-rc3","0.40.0-rc4","0.40.0-rc5","0.40.1","0.40.10","0.40.11","0.40.2","0.40.3","0.40.4","0.40.5","0.40.6","0.40.7","0.40.8","0.40.9","0.41.0-rc.0","0.41.0-rc.1","0.41.0-rc.2","0.41.0-rc.3","0.41.0-rc.4","0.41.0-rc.5","0.41.0-rc.6","0.41.0-rc.7","0.41.0-rc.8","0.41.0-rc.9","0.41.0-rc0","0.41.1","0.41.2","0.41.3","0.41.4","0.41.5","0.41.6","0.41.7","0.42.0-rc.0","0.42.0-rc.1","0.42.0-rc.3","0.42.0-rc.4","0.42.0-rc.5","0.42.0-rc.6","0.42.0-rc.7","0.43.0","1.0.0","1.0.0-pre.0","1.0.0-pre.1","1.0.0-pre.2","1.0.0-pre.3","1.0.0-rc.0","1.0.0-rc.1","1.0.0-rc.2","1.0.0-rc.3","1.0.0-rc.4","1.0.0-rc.5","1.0.0-rc.6","1.0.0-rc.7","1.0.0-rc.8","1.0.0-rc.9","1.1.0","1.1.1","1.1.2","1.1.3","1.2.0","1.2.0-rc.0","1.2.0-rc.1","1.2.1","1.2.2","1.2.3","1.2.4","1.2.5","1.2.6","1.3.0","1.3.0-rc.0","1.3.0-rc.2","1.3.0-rc.3","1.3.0-rc.4","1.3.1","1.3.10","1.3.11","1.3.12","1.3.14","1.3.15","1.3.16","1.3.17","1.3.18","1.3.19","1.3.2","1.3.20","1.3.21","1.3.22","1.3.23","1.3.24","1.3.25","1.3.26","1.3.28","1.3.29","1.3.3","1.3.30","1.3.31","1.3.32","1.3.33","1.3.34","1.3.35","1.3.36","1.3.37","1.3.38","1.3.39","1.3.4","1.3.40","1.3.41","1.3.42","1.3.43","1.3.44","1.3.45","1.3.46","1.3.47","1.3.48","1.3.49","1.3.5","1.3.50","1.3.51","1.3.52","1.3.53","1.3.54","1.3.55","1.3.56","1.3.58","1.3.59","1.3.6","1.3.60","1.3.61","1.3.62","1.3.63","1.3.64","1.3.65","1.3.66","1.3.67","1.3.68","1.3.8","1.3.9","1.4.0","1.5.0","1.5.1","1.5.10","1.5.11","1.5.12","1.5.13","1.5.14","1.5.15","1.5.16","1.5.17","1.5.18","1.5.19","1.5.2","1.5.20","1.5.21","1.5.22","1.5.23","1.5.24","1.5.25","1.5.26","1.5.27","1.5.28","1.5.29","1.5.3","1.5.30","1.5.4","1.5.5","1.5.6","1.5.7","1.5.8","1.5.9","2.0.0","2.0.0-rc.0","2.0.0-rc.1","2.0.0-rc.10","2.0.0-rc.11","2.0.0-rc.12","2.0.0-rc.13","2.0.0-rc.14","2.0.0-rc.15","2.0.0-rc.2","2.0.0-rc.3","2.0.0-rc.4","2.0.0-rc.5","2.0.0-rc.6","2.0.0-rc.7","2.0.0-rc.8","2.0.0-rc.9","2.0.1","2.0.10","2.0.11","2.0.12","2.0.2","2.0.3","2.0.4","2.0.5","2.0.6","2.0.7","2.0.8","2.0.9","2.1.0","2.1.1","2.1.10","2.1.11","2.1.12","2.1.13","2.1.14","2.1.15","2.1.17","2.1.18","2.1.19","2.1.2","2.1.3","2.1.4","2.1.5","2.1.6","2.1.8","2.1.9","2.10.0","2.11.0","2.12.0","2.2.0","2.2.1","2.2.2","2.2.3","2.2.4","2.2.5","2.3.0","2.3.1","2.4.0","2.4.1","2.4.10","2.4.11","2.4.12","2.4.13","2.4.14","2.4.15","2.4.16","2.4.17","2.4.18","2.4.19","2.4.2","2.4.20","2.4.21","2.4.3","2.4.4","2.4.5","2.4.6","2.4.7","2.4.8","2.4.9","2.5.0","2.5.1","2.5.10","2.5.11","2.5.12","2.5.13","2.5.14","2.5.15","2.5.16","2.5.17","2.5.18","2.5.19","2.5.2","2.5.20","2.5.21","2.5.22","2.5.3","2.5.4","2.5.5","2.5.6","2.5.7","2.5.8","2.5.9","2.6.0","2.6.1","2.6.10","2.6.11","2.6.12","2.6.13","2.6.14","2.6.15","2.6.16","2.6.17","2.6.18","2.6.19","2.6.2","2.6.20","2.6.21","2.6.22","2.6.23","2.6.24","2.6.25","2.6.26","2.6.27","2.6.28","2.6.29","2.6.3","2.6.30","2.6.31","2.6.32","2.6.4","2.6.5","2.6.6","2.6.7","2.6.8","2.6.9","2.7.0","2.8.0","2.9.0","2.9.1"]}],"products":[{"vendor":"ash-project","product":"ash_postgres"}],"references":[{"url":"https://github.com/ash-project/ash_postgres/security/advisories/GHSA-6fqq-j9c4-5766","tags":["vendor-advisory","related","exploit","advisory"]},{"url":"https://cna.erlef.org/cves/CVE-2026-78699.html","tags":["related","web"]},{"url":"https://osv.dev/vulnerability/EEF-CVE-2026-78699","tags":["related","web"]},{"url":"https://github.com/ash-project/ash_postgres/commit/8544ab15fe45784553c2d2da8ee1a388eee0174b","tags":["patch","fix"]},{"url":"https://github.com","tags":["web"]},{"url":"https://repo.hex.pm","tags":["web"]},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/78xxx/CVE-2026-78699.json","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-78699","tags":["advisory"]},{"url":"https://github.com/ash-project/ash_postgres","tags":["package"]},{"url":"https://hex.pm/packages/ash_postgres","tags":["package"]}],"sources":{"cve":[{"id":"CVE-2026-78699","title":"rename_tenant returns :ok on a failed rename, enabling cross-tenant access in AshPostgres","description":"Unchecked Return Value vulnerability in ash-project ash_postgres allows a user who can drive a tenant rename to a name that collides with an existing tenant's schema to have their tenant record repointed at that other tenant's live schema, gaining access to its data.\n\nAshPostgres.MultiTenancy.rename_tenant/3 issues the ALTER SCHEMA ... RENAME TO ... with the non-raising Ecto.Adapters.SQL.query/2, discards its {:ok, _} | {:error, _} result, and unconditionally returns :ok. PostgreSQL rejects the rename when the target schema already exists (and on insufficient privilege or lock timeout), but that failure never reaches the caller. The calling manage_tenant update action therefore sees success and commits the tenant row with the new name, which is the schema of a different existing tenant, so subsequent reads and writes for that tenant run against the other tenant's data.\n\nThis issue affects ash_postgres: from 0.25.0 before 2.13.0.","status":"published","published":"2026-08-30T15:13:23.875Z","modified":"2026-09-01T12:30:30.395Z","cvss":[{"version":"4.0","score":7.2,"vector":"CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N","level":"high","assessor":"cna"}],"cwes":["CWE-252"],"updated_at":"2026-11-02T13:34:48.658051Z"}],"euvd":[{"id":"EUVD-2026-68265","description":"Unchecked Return Value vulnerability in ash-project ash_postgres allows a user who can drive a tenant rename to a name that collides with an existing tenant's schema to have their tenant record repointed at that other tenant's live schema, gaining access to its data.\n\nAshPostgres.MultiTenancy.rename_tenant/3 issues the ALTER SCHEMA ... RENAME TO ... with the non-raising Ecto.Adapters.SQL.query/2, discards its {:ok, _} | {:error, _} result, and unconditionally returns :ok. PostgreSQL rejects the rename when the target schema already exists (and on insufficient privilege or lock timeout), but that failure never reaches the caller. The calling manage_tenant update action therefore sees success and commits the tenant row with the new name, which is the schema of a different existing tenant, so subsequent reads and writes for that tenant run against the other tenant's data.\n\nThis issue affects ash_postgres: from 0.25.0 before 2.13.0.","status":"published","published":"2026-08-30T15:13:23Z","modified":"2026-09-01T12:30:30Z","cvss":[{"version":"4.0","score":7.2,"vector":"CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N","level":"high"}],"updated_at":"2026-11-02T18:01:18.76029Z"}],"nvd":[{"id":"CVE-2026-78699","description":"Unchecked Return Value vulnerability in ash-project ash_postgres allows a user who can drive a tenant rename to a name that collides with an existing tenant's schema to have their tenant record repointed at that other tenant's live schema, gaining access to its data.\n\nAshPostgres.MultiTenancy.rename_tenant/3 issues the ALTER SCHEMA ... RENAME TO ... with the non-raising Ecto.Adapters.SQL.query/2, discards its {:ok, _} | {:error, _} result, and unconditionally returns :ok. PostgreSQL rejects the rename when the target schema already exists (and on insufficient privilege or lock timeout), but that failure never reaches the caller. The calling manage_tenant update action therefore sees success and commits the tenant row with the new name, which is the schema of a different existing tenant, so subsequent reads and writes for that tenant run against the other tenant's data.\n\nThis issue affects ash_postgres: from 0.25.0 before 2.13.0.","status":"published","published":"2026-08-30T16:16:42.623Z","modified":"2026-09-01T21:15:00.147Z","cvss":[{"version":"4.0","score":7.2,"vector":"CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X","level":"high","assessor":"secondary"}],"cwes":["CWE-252"],"updated_at":"2026-11-02T14:12:42.691315Z"}],"osv":[{"id":"CVE-2026-78699","title":"rename_tenant returns :ok on a failed rename, enabling cross-tenant access in AshPostgres","description":"Unchecked Return Value vulnerability in ash-project ash_postgres allows a user who can drive a tenant rename to a name that collides with an existing tenant's schema to have their tenant record repointed at that other tenant's live schema, gaining access to its data.\n\nAshPostgres.MultiTenancy.rename_tenant/3 issues the ALTER SCHEMA ... RENAME TO ... with the non-raising Ecto.Adapters.SQL.query/2, discards its {:ok, _} | {:error, _} result, and unconditionally returns :ok. PostgreSQL rejects the rename when the target schema already exists (and on insufficient privilege or lock timeout), but that failure never reaches the caller. The calling manage_tenant update action therefore sees success and commits the tenant row with the new name, which is the schema of a different existing tenant, so subsequent reads and writes for that tenant run against the other tenant's data.\n\nThis issue affects ash_postgres: from 0.25.0 before 2.13.0.","status":"published","published":"2026-08-30T15:13:23.875Z","modified":"2026-10-28T02:30:39.682427311Z","cvss":[{"version":"4.0","score":7.2,"vector":"CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N","level":"high"}],"cwes":["CWE-252"],"updated_at":"2026-11-02T15:45:17.44708Z"},{"id":"EEF-CVE-2026-78699","title":"rename_tenant returns :ok on a failed rename, enabling cross-tenant access in AshPostgres","description":"## Summary\n\nUnchecked Return Value vulnerability in ash-project ash_postgres allows a user who can drive a tenant rename to a name that collides with an existing tenant's schema to have their tenant record repointed at that other tenant's live schema, gaining access to its data.\n\n`AshPostgres.MultiTenancy.rename_tenant/3` issues the `ALTER SCHEMA ... RENAME TO ...` with the non-raising `Ecto.Adapters.SQL.query/2`, discards its `{:ok, _} | {:error, _}` result, and unconditionally returns `:ok`. PostgreSQL rejects the rename when the target schema already exists (and on insufficient privilege or lock timeout), but that failure never reaches the caller. The calling `manage_tenant` update action therefore sees success and commits the tenant row with the new name, which is the schema of a different existing tenant, so subsequent reads and writes for that tenant run against the other tenant's data.\n\nThis issue affects ash_postgres: from 0.25.0 before 2.13.0.\n\n## Configurations\n\nAn application must run ash_postgres schema-based multitenancy with a user-driven tenant rename (for example a `manage_tenant` update on an editable org slug or subdomain), letting a user choose a new tenant name that collides with an existing tenant's schema.","status":"published","published":"2026-08-30T15:13:23.875Z","modified":"2026-09-08T16:15:03.432245789Z","cvss":[{"version":"4.0","score":7.2,"vector":"CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N","level":"high"}],"cwes":["CWE-252"],"updated_at":"2026-11-02T15:46:33.520522Z"}]}}