Avo, a Ruby on Rails admin panel framework, had a significant authorization oversight between versions 2.28.0 and just before 3.32.0. The direct attachment upload endpoint did not enforce server‑side upload authorization and ignored the documented field‑level policy methods such as upload_{FIELD_ID}?. As a result, any authenticated Avo user who could reach this endpoint could replace or add attachment content—including binary data, filenames, and content‑type metadata—on a record even when both the general update? policy and the specific upload_<field>? policies denied the operation. This flaw effectively bypasses the intended per‑record and per‑field security controls, allowing users with limited roles to manipulate data that should be protected.

Avo application deployments built with avo‑hq:avo are affected. The vulnerability exists in any release from version 2.28.0 up to but excluding 3.32.0. Administrators or non‑administrator users who have access to the admin panel and can issue upload requests are impacted, especially in multi‑role configurations where policies are expected to enforce per‑field restrictions.

The CVSS score of 6.5 indicates a moderate severity, and the vulnerability is not yet listed in the CISA KEV catalog. The EPSS score is < 1%, indicating a very low likelihood of exploitation. The likely attack vector requires an authenticated session with access to the Avo attachment upload endpoint; once granted, the attacker can bypass policy checks entirely. Because the flaw allows unauthorized data modification, the risk to confidentiality, integrity, and availability is significant, particularly in environments where sensitive attachments are managed through Avo.