member_default's * wildcard object grant (C/R/E) union-merges into every org member — app-side explicit-allow object gates are erased on three axes #5491

Part of objectstack-ai/hotcrm#703

Found during HotCRM's 17.0 GA acceptance sweep on @objectstack/* 17.0.0-rc.2, 5-profile permission matrix phase (188 probes, each user with their own Bearer token).

Symptom

The platform's member_default permission set carries object_permissions["*"] = {allowCreate:true, allowRead:true, allowEdit:true, allowDelete:false} and is union-merged (most-permissive) into every org member. An app's explicit-allow object gate is therefore erased on the create, read and edit axes. Only delete stays profile-driven.

security/explain states it outright — for a profile carrying an explicit all-false deny on crm_opportunity:

> create on 'crm_opportunity' is granted by [member_default]

Measured (HotCRM, 17 objects, 5 profiles)

• 21 create-denial probes, ALL returned 201 — every profile creates on every object once validation passes (incl. objects the profile explicitly denies).
• member_default also grants own-row EDIT on objects the profile forbids editing (service_agent edited its own crm_account, profile declares no edit anywhere).
• On public_read objects the wildcard yields 200 with ALL rows for non-holders — real unauthorized reads, not the documented "200 with 0 rows" empty-set pattern.

Reproduction

# as a user whose profile carries an explicit all-false deny on crm_opportunity
POST /api/v1/data/crm_opportunity {"name":"X","stage":"prospecting","amount":1,"close_date":"2026-09-01", ...}
→ 201
GET /api/v1/security/explain?object=crm_opportunity&operation=create
→ "... granted by [member_default]"

Why this matters

The app declares explicit-allow; the platform enforces default-allow-except-delete. App-side authorization test suites validate declarations, so CI is green while the runtime posture is default-open — declared ≠ enforced in the security layer itself. If the wildcard is intentional platform policy, apps need a supported opt-out: explicit deny entries do not win against the union today.

Prior related issues (checked, none open on this defect)

• Builtin member_default carries anchor-forbidden bits — every boot logs 'refusing to bind fallback set to everyone' (platform baseline violates its own D5 tier) #2753 (closed) — member_default anchor-forbidden bits at boot
• 澄清:viewAllRecords / modifyAllRecords 在 public_read_write 下失效,是否为开源版有意设计? #3005 (closed) — clarification of viewAll/modifyAll under public_read_write; this report is about member_default's wildcard under normal OWDs
• [security][P0] Broken access control — any authenticated member can read AND modify other users' records #1985 (closed) — the 16.x-era broad-access defect

Full probe log: HotCRM acceptance run w4/results.jsonl (M1/M9). Sibling findings from the same sweep: objectstack-ai/hotcrm#705 (write gate), objectstack-ai/hotcrm#704 (parent-derived reads, tracked here as #5386).

Blocked-by: #6428