Date 2026-06-21. Target: TaskingAI (TaskingAI/TaskingAI, LLM BaaS). Triage assumed multi-tenancy (projects/workspaces). Result: WALK - the cross-tenant IDOR class does NOT EXIST in the OSS edition.
TaskingAI's docs/marketing describe projects/workspaces (multi-tenant). The OSS code has the IDOR smell: run_action/update_action (services/tool/action/action.py:143,166) resolve a resource by raw global id and IGNORE the required auth_info (never scope by caller). Textbook "missing object-level authz." BUT: grep project_id|owner|tenant over backend/app/models + backend/app/operators = ZERO hits. No resource model (Action/Assistant/Collection/Record/Chat/Apikey) has a project/owner/tenant column. auth_info_required runs in single global-token (WEB) or single global-api-key (API) mode - no project extracted. The OSS edition is SINGLE-TENANT: every authenticated caller is the same global owner. The multi-tenancy (projects/workspaces) lives only in the CLOSED cloud edition. So the "IDOR" is a no-op - there is no second tenant to cross, and the unused auth_info enforces nothing because there's nothing to enforce.
Before hunting cross-tenant/cross-project IDOR on an OSS target, FIRST verify the tenancy boundary EXISTS in the audited (open-source) artifact:
- grep -rn 'project_id|workspace_id|tenant_id|org_id|owner_id|user_id' <models/entities dir> - does the RESOURCE schema actually carry a scoping column?
- Check the auth dependency: does it RESOLVE a tenant/project for the caller (not just authenticate)?
- If NO scoping column on resources AND auth yields no tenant -> the OSS edition is SINGLE-TENANT -> cross-tenant IDOR is NOT APPLICABLE, regardless of how much the route "ignores auth." WALK (the cloud edition might be vulnerable, but it's closed-source / out of scope).
A "raw get(id) that ignores the authenticated user" is only an IDOR if there exists a tenant/owner column the query SHOULD have filtered on. No column -> no boundary -> no finding.
Many AI/SaaS projects are "open-core": the OSS repo is single-tenant (self-host = one org), and multi-tenancy/RBAC is a CLOUD/enterprise feature in closed source. Marketing says "workspaces/projects/teams"; the OSS schema doesn't have them. Hunting cross-tenant IDOR in the OSS source is then a dead end by construction. This is the INVERSE of the RAGFlow disclosure lesson: not "the bug is already reported," but "the boundary the bug depends on isn't in the artifact you're auditing." Add the schema-boundary check to Gate-0/triage so you don't spend a sweep proving a no-op. - Corollary: if the OSS IS single-tenant but the CLOUD is multi-tenant AND the cloud is in the bounty scope, the finding may be real on cloud - but you can't confirm it from OSS source; flag it as "cloud-only, needs the hosted target," don't stage from OSS source alone.
Bisheng (hit): the SSRF needed no tenancy boundary (unauth fetch). RAGFlow/Dify IDORs: those repos DO carry tenant columns (the boundary exists) - that's why their IDORs were real (just disclosed/saturated). TaskingAI: no tenant column in OSS -> the IDOR class is absent. Always check the column exists.