Description

Avo is a framework to create admin panels for Ruby on Rails apps. From version 2.28.0 to before version 3.32.0, Avo's direct attachment upload endpoint lacks server-side upload authorization and bypasses the documented field-level upload policy methods such as upload_{FIELD_ID}?. An authenticated Avo user who can reach the Avo attachment upload endpoint can replace or add attachment content, including binary content, filename, and content-type metadata, on a resolved record even when both update? and upload_<field>? policies deny the operation. This primarily affects multi-role Avo Pro/Advanced-style deployments where non-administrator or restricted operator users can reach Avo and per-record or per-field operations are expected to be enforced by policies. This issue has been patched in version 3.32.0.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.5",
  "pubDate": "2026-09-04T21:17:25.300Z",
  "pubdate": "2026-09-04T21:17:25.300Z",
  "executiveSummary": "The Avo framework for Ruby on Rails contains an authorization bypass vulnerability within its direct attachment upload endpoint. Versions 2.28.0 through 3.31.x are susceptible to unauthorized file operations, allowing authenticated users to bypass intended field-level and record-level security policies.\nThe vulnerability allows an authenticated attacker to inject, replace, or manipulate attachment content—including binary data, filenames, and MIME types—even when specific application policies (update? or upload_{FIELD_ID}?) explicitly forbid such actions.\nThis flaw primarily impacts multi-tenant or multi-role environments where granular access control is enforced for administrative interfaces. The risk is significant as it permits unauthorized modification of system resources by users who should otherwise be restricted. Exploitation requires authenticated access to the Avo admin panel, but bypasses the application's internal security logic, rendering field-level protections ineffective. Organizations utilizing Avo Pro/Advanced in environments with diverse user roles are at the highest risk and are advised to prioritize the upgrade to version 3.32.0 or later.",
  "technicalDetails": "The vulnerability originates from a failure in the Avo framework's direct attachment upload controller to properly invoke or honor server-side authorization checks before processing file uploads. In Ruby on Rails, security policies are typically enforced via policy objects that check methods like 'update?' or field-specific 'upload_{FIELD_ID}?' hooks. The affected component fails to bridge these policy definitions with the underlying upload request handler, resulting in a bypass of the application's authorization workflow.\nSpecifically, the attachment upload endpoint accepts multipart requests that include binary file blobs, filename metadata, and content-type headers. Because the framework does not perform a secondary validation against the record's policy context during the execution of this endpoint, an attacker can manipulate these parameters to overwrite or append attachments to existing database records. Even if a user is restricted from editing a record via the standard Rails policy, the direct upload endpoint processes the payload independently of the record's state or the user's defined permissions.\nThe attack flow proceeds as follows: An authenticated user with access to the Avo dashboard identifies the direct attachment upload endpoint. The attacker constructs a malicious request containing a crafted attachment payload, including arbitrary binary content and metadata. The request is transmitted to the server, which proceeds to persist the attachment to the storage backend (e.g., Active Storage) associated with the target record. The application fails to verify if the user possesses the 'upload_{FIELD_ID}?' privilege, effectively granting the attacker the ability to perform write operations on restricted fields. This persistence occurs regardless of the actual permission set associated with the user's role or the record itself.\nThis behavior exposes the application to risks such as unauthorized data injection, potential remote code execution (if server-side file execution is possible through file naming or MIME type manipulation), and data corruption. Because the framework ignores the developer-defined policy methods, it invalidates the security model intended to govern multi-user administrative panel access. The root cause is the decoupling of the upload request processing logic from the authorization enforcement middleware within the Avo framework."
}