The vulnerability in Avo affects the direct attachment upload endpoint (POST /avo_api/resources/:resource_name/:id/attachments/) where the server-side code creates and attaches ActiveStorage blobs before validating attachment associations or enforcing upload authorization policies. The controller does not call the expected authorization methods such as upload_<field>? or update? before attaching files, allowing authenticated users with access to the endpoint to bypass field-level upload policies. This contrasts with the attachment deletion endpoint, which properly enforces delete_<attachment_name>? authorization. The issue impacts versions from 2.28.0 up to but not including 3.32.0, including later beta versions, and has been confirmed by proof-of-concept. The vulnerability is documented in Avo's GitHub issues and pull requests, which clarify that upload authorization should be enforced at the field level but currently is not on this endpoint.

Authenticated users who can access the vulnerable upload endpoint can upload or replace attachments on records regardless of field-level upload policies or update restrictions. This can lead to unauthorized modification of attachment content, including binary data, filenames, and content-type metadata, potentially violating data integrity and access control expectations in multi-role environments. There is no impact on confidentiality or availability indicated, but integrity is affected.

Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. Until an official fix is released, restrict access to the direct attachment upload endpoint to trusted users only and consider implementing additional access controls or request filtering to prevent unauthorized uploads. Monitor Avo's official channels for updates and apply patches promptly once available.