Threat Intelligence Database

Avo is a framework to create admin panels for Ruby on Rails apps. Prior to 3.32.1 and 4.0.0.beta.51, Avo's association attach workflow checks attach_<association>? in the UI and GET /resources/:resource/:id/:related/new path, but the actual write endpoint, POST /resources/:resource/:id/:related, does not run the same authorization check before mutating the association through Avo::AssociationsController#create. An authenticated low-privileged Avo user can bypass hidden or disabled attach controls and directly attach related records to a parent record by sending a crafted POST request, which can lead to privilege escalation and cross-tenant data exposure where associations represent authorization-bearing relationships. This issue is fixed in versions 3.32.1 and 4.0.0.beta.51.

Avo's direct attachment upload endpoint lacks proper server-side upload authorization, allowing authenticated users to upload or replace attachments on records even when field-level upload policies deny such actions. This affects multi-role Avo Pro/Advanced deployments where per-record or per-field upload restrictions are expected. The vulnerability arises because the upload endpoint creates and attaches files without enforcing the documented upload authorization methods, unlike the deletion endpoint which correctly enforces authorization. This inconsistency enables bypassing intended upload restrictions via direct POST requests to the upload endpoint.