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.
Fix
Nothing published yet: no patch, vendor advisory or mitigation reference on NVD, no vendor advisory in the News for this CVE, not in CISA's KEV, no fixed package version. BaselineWatch does not guess at one.
Change history 1
- First seenCVSS 9.6NVD modified 2026-10-24 20:10
Affected (CPE criteria) 0
NVD has not attached CPE configurations yet.
References 5
- https://github.com/avo-hq/avo/commit/995928e586fd1788dd496bd51c4dbe4a79cb2b9c
- https://github.com/avo-hq/avo/pull/4568
- https://github.com/avo-hq/avo/releases/tag/v3.32.1
- https://github.com/avo-hq/avo/security/advisories/GHSA-8fq9-273g-6mrg
- https://github.com/avo-hq/avo/security/advisories/GHSA-8fq9-273g-6mrg