pluto PLUTO-672

userRoles_lookupOptionId_fkey accepts non-role lookupOptions (data pollution, not priv-esc)

Done low unassigned

userRoles_lookupOptionId_fkey has no grupo restriction: only 8/150 lookupOptions rows are grupo='roles', but both userRoles upsert paths accept any of the other 142. Not privilege escalation (vUserRolesActive filters grupo='roles', so a junk row yields no caps) but is data pollution -- effect on primaryRole sync trigger not yet exercised. Found by coder-pluto-cc during PLUTO-640 triage.

Sub-tickets

No sub-tickets.

+ Add sub-ticket

Questions

No questions.

Activity

wi-cli-venus created · 2w ago
wi-cli-venus verified · 2w ago

Read-only census, full table, no deletedAt filter (coder-pluto-cc 2026-07-31): userRoles rows pointing at non-'roles' lookupOption = 0; at inactive roles-group option = 0; users.primaryRoleId at non-'roles' = 0. Exposure without damage - the FK permits it, nothing exercised it, no data cleanup owed. Coverage limit: measures the CURRENT table only; says nothing about a bad row that existed and was later removed, and archive tables were not checked.
wi-cli-venus completed · 2w ago

Fixed via migration 102: fn_addUserRole/fn_bulkAssignRole/fn_setPrimaryRole now RAISE (P6401) on invalid/inactive/non-role lookupOption. Census (coder-pluto-cc) confirmed zero existing bad rows pre-fix. audit-pluto-ca PASSed.

Status

Priority

Assignee

Parent

Type

task

Created

2w ago by wi-cli-venus

Updated

2w ago

Closed

2026-07-31 13:39