GHSA-pqpw-cvm4-8mv9 Avo: Direct attachment upload endpoint lacks upload authorization and bypasses field-level upload policy
SummaryAvo'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.DetailsAvo exposes a direct attachment upload endpoint:The vulnerable code path is `Avo::AttachmentsController#create`:`app/controllers/avo/attachments_controller.rb:9-24`Current behavior: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`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`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:Issue #1624 requested the "Ability to police each file upload/download/delete".
https://github.com/avo-hq/avo/issues/1624PR #1625 introduced `upload_cover_photo?` as an example upload policy method.
https://github.com/avo-hq/avo/pull/1625PR #1667 clarified the policy semantics: "From now on, only field level
authorization will be considered. If it is defined and returns true, the
action will be granted; otherwise, it will not."
https://github.com/avo-hq/avo/pull/1667The current Avo authorization documentation lists `upload_{FIELD_ID}?` as the
policy method controlling whether a user can upload an attachment, stating:
"Controls whether the user can upload the attachment."
https://docs.avohq.io/4.0/authorization.htmlThe same documentation says the same `upload_file?` policy method will be used
to "authorize the file upload" in action file fields.
https://docs.avohq.io/4.0/authorization.htmlAffected 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: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.PoCA 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
denialthe replacement authorization service records all `authorize_action` callsThe 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: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:Normal record update is denied by policy and does not persist changes.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.Direct upload with `attachment_key=attachments` succeeds even though
`PostPolicy#upload_attachments?` returns `false`, adding to a
`has_many_attached` association.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.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`ImpactThis 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 storedperform upload authorization before `ActiveStorage::Blob.create_and_upload!`derive the policy method from the validated association name rather than raw
request inputapply an equivalent authorization decision to supported `params[:key]` / Trix
upload flows before blob creation or URL returnreturn a JSON-compatible `403 Forbidden` response when upload authorization is
deniedThe 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.
CVSS v3.1 score: 6.5