Ruben Fiszel 6739211dbc fix(security): rebind forked app run-as to the fork creator (GHSA-r7x4-qj3p-jfvr) ...

Forking a workspace clones its apps. `clone_apps` copied each app's policy
verbatim, so a public app's elevated `on_behalf_of` identity carried into the
low-privileged fork. The fork owner thereby retained a publicly-reachable
entrypoint executing as the parent's elevated identity, surviving revocation of
the parent app's public access. Any non-admin member can create a (non-dev)
fork.

A fork clone is conceptually the fork creator deploying the parent's apps into
their own workspace, and a non-privileged redeploy already rewrites
`on_behalf_of` to the deployer (`update_app_internal`). The clone just skipped
that step. Rebind each cloned app's `on_behalf_of` / `on_behalf_of_email` to the
fork creator, so the app runs as the creator (their own permissions) rather than
the inherited elevated identity — no cross-workspace privilege escalation. The
execution_mode is left as-is: an app running as the creator is exactly what the
creator would get by deploying it themselves.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

2026-07-15 10:55:51 +00:00

..

src

fix(security): rebind forked app run-as to the fork creator (GHSA-r7x4-qj3p-jfvr)

2026-07-15 10:55:51 +00:00

Cargo.toml

feat: add SQL migrations for data tables (#9693)

2026-07-07 08:25:16 +00:00