Super-user grants cross-tenant workspace CRUD (authz granularity)

• Severity: Informational (this appears to be intended behavior; flagging for clarity, not a bug)
• CVSS 3.1: N/A — no security control violated
• CWE: CWE-1016 (Comparison Based on Language Boundaries) — weakest applicable
• Asset: admin.corezoid.com/api/2/json authorization model
• Discovered: 2026-04-26
• Status: Informational — confirm intended behavior

Summary

The is_super_user: true flag on the CTO account does NOT bypass company-level metadata access (get company obj_id=<foreign> returns "User has no rights" — good), BUT it DOES grant full-CRUD access to the contents of foreign-company workspaces via list folder with a company_id parameter.

This creates an authorization-granularity mismatch that's valuable to document:

Reproduction

# ATB company — CTO is `is_owner=false, is_admin=false`
$ curl -sk -b cookies.txt -X POST 'https://admin.corezoid.com/api/2/json' \
  -H 'Content-Type: application/json' \
  --data '{"ops":[{"type":"get","obj":"company","obj_id":"i27074631367"}]}'
{"proc":"error","description":"User has no rights"}

# But folders inside ATB — full access
$ curl ... --data '{"ops":[{"type":"list","obj":"folder","obj_id":0,"company_id":"i27074631367"}]}'
{"proc":"ok","list":[{
  "is_shared":true,
  "privs":[
    {"type":"create","list_obj":["all"]},
    {"type":"view","list_obj":["all"]},
    {"type":"modify","list_obj":["all"]},
    {"type":"delete","list_obj":["all"]}
  ],...}]}

Why this matters (even if intended)

1. Insider threat model. The super-user (CTO) has delete-all-workflows power over every customer tenant. A compromised super-user session = full platform wipe capability. This amplifies CRZ-013 (no-confirmation deletes) dramatically — in the worst case, one stolen session could disrupt Corezoid's entire customer base.

2. Visible tenants include regulated financial customers: ATB (retail), Kaspi.KZ (banking), TransferTo (payments), VISA-EPICENTR-ABANK, TBI RO pilot, ABank, WOG fuel, Metro. A breach of the super-user role would require breach notifications to multiple regulators (Ukraine, Kazakhstan, Romania) and likely customer SLAs.

3. Clarity / least-privilege opportunity. If the super-user role is actually only needed for platform operations (billing adjustments, tenant creation, migration), it shouldn't require full CRUD rights on tenant workflows. Consider splitting super_user into two roles:

   • platform_admin — billing, tenant lifecycle, org-level settings; no read on tenant data
   • incident_responder — read-only across tenants, time-limited, logged

4. Consistency check. The mismatch between get company (authz enforced) and list folder company_id=<X> (super_user bypass) is a code-smell. It suggests the authz was added piecemeal rather than via a single unified model — different team members at different times. A systematic review would likely find more such inconsistencies.

What was NOT tested

• Whether a regular user (non-super_user) who is is_owner=false, is_admin=false of ATB can also see ATB's folders. If they can, that's a real cross-tenant data leak. My engagement only had one user account (super-user), so this is out of scope for this pentest.
• Whether any tenant-scoped op (read process contents, execute workflow) lets the super_user cross into a foreign tenant's runtime data (tasks, variables, customer-submitted form data). Likely yes, but not probed to avoid touching customer data.
• Whether API tokens issued by tenant admins have the same cross-tenant reach (probably no — they'd be scoped to their tenant — but should be verified).

Remediation

Priority 1 — verify intended behavior:

1. Decide if super-user workspace CRUD is intended. If yes, document it explicitly in the admin-guide. If no, scope the super_user role down.
2. If intended, add mandatory MFA step-up for destructive ops performed across tenant boundaries (consistent with CRZ-013 recommendation).

Priority 2 — authz model audit:

1. Unified authz module review. Map every op-type × object-type × role combination to expected behavior. Look for inconsistencies like the get company vs list folder mismatch.
2. Add authz tests that assert cross-tenant boundaries hold for every op.
3. Split super_user. Platform operations vs cross-tenant reads should be separate capabilities.

Priority 3 — logging:

1. Any cross-tenant op by a super_user should land in an audit trail that is visible to the tenant's admins (so they can see when platform operators accessed their data).
2. For compliance: SOC 2 Type II and PCI DSS 4.0 both require tenant-visible audit trails of privileged operator access.

References

• CWE-1016 (inconsistent authz across layers)
• NIST SP 800-53 AC-6 (least privilege), AC-16 (auditing privileged access)
• SOC 2 CC6.3 — logical access authorization