Summary

A critical missing authorization flaw exists in Avo's association attach workflow. The UI and GET /resources/:resource/:id/:related/new path can check attach_<association>?, but the actual write endpoint, POST /resources/:resource/:id/:related, does not run the same authorization check before mutating the association.

As a result, an authenticated low-privileged Avo user can bypass hidden/disabled attach controls and directly attach related records to a parent record by sending a crafted POST request. In applications where associations represent teams, tenants, roles, projects, users, memberships, ownership, or other authorization-bearing relationships, this can lead to privilege escalation and cross-tenant data exposure.

Impact

This vulnerability allows unauthorized relationship manipulation through Avo.

Depending on the affected association, the impact can include:

• Privilege escalation by attaching a user to an admin group, privileged project, tenant, organization, role, or membership record.
• Cross-tenant data exposure when tenant/user/project membership determines record visibility.
• Integrity loss by changing ownership, assignment, access-control relationships, or business workflow state.
• Policy bypass even when Avo UI controls correctly hide the attach button or deny the attach form.