T05 · Unauthorized Access and Privilege Escalation
- Location
src/api.ts:65- Finding
Overprivileged Supabase Service-Role Credential Bypasses Tenant Security
- Content
View full analysis
Vulnerability Details
File Location:
src/api.ts:65-67
Related Documentation:SKILL.md:17,skill.json:17-20
Vulnerability Type: Excessive database privileges and RLS bypass
Risk Level: HighVulnerable Code
typescript this.supabase = createClient(config.supabaseUrl, config.supabaseKey, { auth: { persistSession: false } })The project explicitly instructs operators to provide a service-role credential:
markdown **Important:** Use the Service Role Key, not the Anon Key, for full database access.Technical Analysis
The Supabase service-role credential provides broad database access and bypasses Row Level Security. This conflicts with the project's stated reliance on RLS for multi-organization isolation.
Tenant isolation therefore depends entirely on every application query correctly applying an
org_idpredicate. Any missing or defective predicate becomes a cross-tenant access vulnerability. A compromise of the skill process or disclosure of this credential would also provide substantially more database authority than the lead-management task requires.Attack Path
- An attacker obtains code execution in the skill process, gains access to its configuration, or reaches an operation containing an insufficiently scoped query.
- The attacker uses the initialized Supabase client backed by the service-role credential.
- Supabase RLS does not constrain the request because service-role access bypasses RLS.
- The attacker reads, modifies, or deletes records beyond the configured organization wherever application-level filtering is absent or defective.
Impact Assessment
The affected privileges can include broad read and write access to the configured Supabase project. Depending on the service-role permissions and database schema, exposure may include leads, contact details, conversation histories, metadata, and records belonging to other organizations.
T ...[truncated 108 chars]
- Remediation
View remediation
Remediation Suggestions
- Replace the service-role credential with a restricted anonymous or authenticated user token.
- Enforce RLS policies using authenticated organization claims rather than trusting a caller-supplied organization identifier alone.
- If privileged database operations are unavoidable, place them behind a narrowly scoped server-side API that authorizes each operation and exposes no general-purpose database credential to the agent process.
- Store credentials in a managed secret store, rotate existing service-role keys, and prevent them from appearing in logs or returned errors.
- Add automated tests confirming that every read, update, and delete operation is denied for records outside the authenticated organization.
- Apply least-privilege database grants so the integration can access only the required tables, columns, and operations.
