PT-2026-57041 · Rubygems · Avo

Published

2026-07-09

·

Updated

2026-07-09

·

CVE-2026-53769

CVSS v3.1

6.5

Medium

VectorAV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N

Summary

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.

Details

Avo exposes a direct attachment upload endpoint:
text
POST /<avo-root>/avo api/resources/:resource name/:id/attachments/
The vulnerable code path is Avo::AttachmentsController#create:
  • app/controllers/avo/attachments controller.rb:9-24
Current behavior:
ruby
def create
 blob = ActiveStorage::Blob.create and upload! io: params[:file].to io, filename: params[:filename]
 association name = BaseResource.valid attachment name(@record, params[:attachment key])

 if association name
  @record.send(association name).attach blob
 elsif params[:key].blank?
  raise ActionController::BadRequest.new(...)
 end

 render json: {
  url: main app.url for(blob),
  href: main app.url for(blob)
 }
end
This endpoint creates an ActiveStorage::Blob before validating the requested attachment association and before any upload authorization could be enforced. If attachment key resolves to an association, the blob is attached to the target record. If the request uses the key-based/Trix path, the endpoint can still persist the blob and return url/href even when no attachment association is resolved on the target record.
The controller never calls:
  • @resource.authorization.authorize action("upload <field>?", record: @record, ...)
  • @resource.authorization.authorize action("update?", record: @record, ...)
This is inconsistent with the rest of Avo's file authorization implementation. The field-level file authorization concern defines upload authorization as:
  • lib/avo/fields/concerns/file authorization.rb:11-12
  • lib/avo/fields/concerns/file authorization.rb:25-27
ruby
def can upload file?
 authorize file action(:upload)
end

def authorize file action(action)
 authorize action("#{action} #{id}?", record: record, raise exception: false)
end
That upload policy is used by UI components to decide whether to render upload controls, but the server-side upload endpoint does not enforce the same policy. A user can therefore bypass the policy by directly POSTing to the endpoint.
By contrast, attachment deletion does call attachment-specific authorization:
  • app/controllers/avo/attachments controller.rb:27-65
ruby
def destroy
 if authorized to :delete
  ...
 end
end

def authorized to(action)
 @resource.authorization.authorize action("#{action} #{params[:attachment name]}?", record: @record, raise exception: false)
end
The asymmetry is:
  • destroy: calls delete <attachment name>?
  • create: does not call upload <attachment key>? or update?
The field-level upload authorization intent is also documented by Avo:
Affected versions observed:
  • PoC-confirmed: Avo 3.31.2, commit 46aa6b3bc9e3283110c39e58cfec8bb95adc1897
  • Same vulnerable code path by source inspection: origin/main HEAD as of 2026-05-29, 9e23ddc88f2b1e762e4a5ec35a6f86370ac16c73
  • Same vulnerable code path by source inspection: Avo v4.0.0.beta.26, 6d339595a27f8779cb99b4aa38ddc97cb702b30f
  • Same vulnerable code path by source inspection: origin/4-dev at version 4.0.0.beta.40, 7ab9794f8b044b11b9677cdc57547d99cf96c3f3
Suggested affected range for the GitHub Security Advisory form:
text
>= 2.28.0
Rationale:
  • The direct attachment upload endpoint exists without upload authorization from commit ab5f5970e2aa76e6ca0a95bf04f510ba7ed5e858 (feature: trix attachments, 2021-04-24), first included in tag v1.4.0.
  • The documented field-level upload policy bypass is confirmed from commit 667049ceeda838394214489693d088708d9da77d (feature: field level file authorization, 2023-03-12), first included in tag v2.28.0.
  • PR #1667 later clarified the field-level-only grant/deny semantics in commit 31b6ef94f8cc4c340a2a75eec36c838cda933ce7, first included in tag v2.30.1.
From a narrow missing-authorization perspective, the issue exists from v1.4.0; the >= 2.28.0 range is a conservative submission range anchored to the documented field-level upload policy boundary.
Fixed version: to be determined by maintainers.

PoC

A local request spec was used to reproduce the issue. The PoC adds pundit to the test group and replaces Avo::Services::AuthorizationService with a test double. The test double records every authorize action invocation and, when invoked, delegates the decision to a PostPolicy resolved via Pundit.policy!.
The policy setup is:
  • PostPolicy#update? returns false
  • PostPolicy#upload attachments? returns false
  • PostPolicy#upload cover photo? returns false
  • PostPolicy#method missing returns true for all other policy methods ending in ?, simulating a user with general read access but explicit update/upload denial
  • the replacement authorization service records all authorize action calls
The open-source repository does not include Avo Pro's authorization client. The critical observation is independent of which client is plugged in: the vulnerable endpoint never invokes authorize action at all, so the call list remains empty.
The PoC user has roles: {admin: true}, which is required only to pass the dummy app's coarse route-level guard:
ruby
authenticate :user, ->(user) { user.is admin? }
The vulnerability under test is one layer below that guard: the fine-grained record/field authorization that Avo Pro/Pundit deployments would normally enforce. The dummy route gate is not part of Avo's upload policy decision. In a deployment where non-admin operators reach Avo through a different authentication rule, AttachmentsController#create would still skip authorize action for the upload.
Policy scoping is orthogonal to this finding. Even if apply policy filtered the record set during lookup, AttachmentsController#create would still not authorize the upload action itself for records that survive the scope.
The spec demonstrates:
  1. Normal record update is denied by policy and does not persist changes.
  2. Direct upload with attachment key=cover photo succeeds even though PostPolicy#upload cover photo? returns false, replacing the existing has one attached cover photo blob.
  3. Direct upload with attachment key=attachments succeeds even though PostPolicy#upload attachments? returns false, adding to a has many attached association.
  4. Direct upload with params[:key] and no attachment association succeeds, creates an ActiveStorage::Blob, and returns url/href without attaching the blob to the record.
  5. The direct upload requests do not invoke the replacement authorization service at all.
The full request-spec patch can be provided in this advisory thread if useful.
Verification environment:
  • Ruby 3.3.1
  • Avo 3.31.2
  • Commit 46aa6b3bc9e3283110c39e58cfec8bb95adc1897

Impact

This is a missing server-side authorization vulnerability in Avo's direct attachment upload endpoint.
The primary affected deployments are Avo Pro/Advanced-style multi-role deployments where non-administrator or restricted operator users can reach Avo, and per-record/per-field operations are expected to be enforced by policies.
In such deployments, an authenticated Avo user can add or replace attachment content on a resolved record even when the host application policy denies both:
  • record update, for example update?
  • field-level upload, for example upload cover photo? or upload attachments?
For has one attached fields, the demonstrated impact is replacement of a protected attachment field with attacker-controlled content. The attacker controls the uploaded binary content, filename, and content-type metadata for the reachable field.
For key-based/Trix upload flows, the endpoint can persist a blob and return a URL even when no attachment association is resolved. This means the endpoint should not be left as an unauthenticated blob creation and URL return path for authenticated Avo users.
In admin-only deployments following the Avo Community pattern, practical exposure is much lower because the only users who can reach the endpoint are already trusted to perform record updates through the normal CRUD path.
Suggested fix direction:
  • validate the requested attachment key before any blob is stored
  • perform upload authorization before ActiveStorage::Blob.create and upload!
  • derive the policy method from the validated association name rather than raw request input
  • apply an equivalent authorization decision to supported params[:key] / Trix upload flows before blob creation or URL return
  • return a JSON-compatible 403 Forbidden response when upload authorization is denied
The default Avo::Services::AuthorizationService#authorize action returns true in lib/avo/services/authorization service.rb:34-35, so applications without a custom authorization client should not see a behavior change from adding an authorization call. Deployments with custom/Pro authorization clients that explicitly deny upload would gain enforcement at this endpoint.
No official Avo-level workaround was confirmed in this review. Until a fix is available, applications can reduce exposure by ensuring only fully trusted administrators can access Avo routes.
Applications needing an immediate mitigation may override or monkey-patch Avo::AttachmentsController#create to authorize uploads before blob creation. Any mitigation should be tested against the application's Avo authorization client and upload UI, because the endpoint is used by Trix/file upload flows. If a mitigation falls back to update? for key-based/Trix uploads, that is a conservative behavior change for applications that currently allow read-only operators to use those uploads; those deployments should replace the fallback with an explicit rich-text upload policy.

Fix

Incorrect Authorization

Missing Authorization

Found an issue in the description? Have something to add? Feel free to write us 👾
dbugs@ptsecurity.com

Weakness Enumeration

CWE-863CWE-862

Related Identifiers

CVE-2026-53769
GHSA-PQPW-CVM4-8MV9

Affected Products

Avo