{
  "affected": [
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "avo"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.28.0"
            },
            {
              "fixed": "3.32.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-53769"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-09T20:54:10Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nAvo\u0027s direct attachment upload endpoint lacks server-side upload authorization and bypasses the documented field-level upload policy methods such as `upload_{FIELD_ID}?`.\n\nAn 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_\u003cfield\u003e?` policies deny the operation.\n\nThis 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.\n\n### Details\n\nAvo exposes a direct attachment upload endpoint:\n\n```text\nPOST /\u003cavo-root\u003e/avo_api/resources/:resource_name/:id/attachments/\n```\n\nThe vulnerable code path is `Avo::AttachmentsController#create`:\n\n- `app/controllers/avo/attachments_controller.rb:9-24`\n\nCurrent behavior:\n\n```ruby\ndef create\n  blob = ActiveStorage::Blob.create_and_upload! io: params[:file].to_io, filename: params[:filename]\n  association_name = BaseResource.valid_attachment_name(@record, params[:attachment_key])\n\n  if association_name\n    @record.send(association_name).attach blob\n  elsif params[:key].blank?\n    raise ActionController::BadRequest.new(...)\n  end\n\n  render json: {\n    url: main_app.url_for(blob),\n    href: main_app.url_for(blob)\n  }\nend\n```\n\nThis 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.\n\nThe controller never calls:\n\n- `@resource.authorization.authorize_action(\"upload_\u003cfield\u003e?\", record: @record, ...)`\n- `@resource.authorization.authorize_action(\"update?\", record: @record, ...)`\n\nThis is inconsistent with the rest of Avo\u0027s file authorization implementation. The field-level file authorization concern defines upload authorization as:\n\n- `lib/avo/fields/concerns/file_authorization.rb:11-12`\n- `lib/avo/fields/concerns/file_authorization.rb:25-27`\n\n```ruby\ndef can_upload_file?\n  authorize_file_action(:upload)\nend\n\ndef authorize_file_action(action)\n  authorize_action(\"#{action}_#{id}?\", record: record, raise_exception: false)\nend\n```\n\nThat 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.\n\nBy contrast, attachment deletion does call attachment-specific authorization:\n\n- `app/controllers/avo/attachments_controller.rb:27-65`\n\n```ruby\ndef destroy\n  if authorized_to :delete\n    ...\n  end\nend\n\ndef authorized_to(action)\n  @resource.authorization.authorize_action(\"#{action}_#{params[:attachment_name]}?\", record: @record, raise_exception: false)\nend\n```\n\nThe asymmetry is:\n\n- `destroy`: calls `delete_\u003cattachment_name\u003e?`\n- `create`: does not call `upload_\u003cattachment_key\u003e?` or `update?`\n\nThe field-level upload authorization intent is also documented by Avo:\n\n- Issue #1624 requested the \"Ability to police each file upload/download/delete\".\n  https://github.com/avo-hq/avo/issues/1624\n- PR #1625 introduced `upload_cover_photo?` as an example upload policy method.\n  https://github.com/avo-hq/avo/pull/1625\n- PR #1667 clarified the policy semantics: \"From now on, only field level\n  authorization will be considered. If it is defined and returns true, the\n  action will be granted; otherwise, it will not.\"\n  https://github.com/avo-hq/avo/pull/1667\n- The current Avo authorization documentation lists `upload_{FIELD_ID}?` as the\n  policy method controlling whether a user can upload an attachment, stating:\n  \"Controls whether the user can upload the attachment.\"\n  https://docs.avohq.io/4.0/authorization.html\n- The same documentation says the same `upload_file?` policy method will be used\n  to \"authorize the file upload\" in action file fields.\n  https://docs.avohq.io/4.0/authorization.html\n\nAffected versions observed:\n\n- PoC-confirmed: Avo `3.31.2`, commit\n  `46aa6b3bc9e3283110c39e58cfec8bb95adc1897`\n- Same vulnerable code path by source inspection: `origin/main` HEAD as of\n  2026-05-29,\n  `9e23ddc88f2b1e762e4a5ec35a6f86370ac16c73`\n- Same vulnerable code path by source inspection: Avo `v4.0.0.beta.26`,\n  `6d339595a27f8779cb99b4aa38ddc97cb702b30f`\n- Same vulnerable code path by source inspection: `origin/4-dev` at version\n  `4.0.0.beta.40`,\n  `7ab9794f8b044b11b9677cdc57547d99cf96c3f3`\n\nSuggested affected range for the GitHub Security Advisory form:\n\n```text\n\u003e= 2.28.0\n```\n\nRationale:\n\n- The direct attachment upload endpoint exists without upload authorization from\n  commit `ab5f5970e2aa76e6ca0a95bf04f510ba7ed5e858` (`feature: trix\n  attachments`, 2021-04-24), first included in tag `v1.4.0`.\n- The documented field-level upload policy bypass is confirmed from commit\n  `667049ceeda838394214489693d088708d9da77d` (`feature: field level file\n  authorization`, 2023-03-12), first included in tag `v2.28.0`.\n- PR #1667 later clarified the field-level-only grant/deny semantics in commit\n  `31b6ef94f8cc4c340a2a75eec36c838cda933ce7`, first included in tag\n  `v2.30.1`.\n\nFrom a narrow missing-authorization perspective, the issue exists from\n`v1.4.0`; the `\u003e= 2.28.0` range is a conservative submission range anchored to\nthe documented field-level upload policy boundary.\n\nFixed version: to be determined by maintainers.\n\n### PoC\n\nA local request spec was used to reproduce the issue. The PoC adds `pundit` to\nthe test group and replaces\n`Avo::Services::AuthorizationService` with a test double. The test double\nrecords every `authorize_action` invocation and, when invoked, delegates the\ndecision to a `PostPolicy` resolved via `Pundit.policy!`.\n\nThe policy setup is:\n\n- `PostPolicy#update?` returns `false`\n- `PostPolicy#upload_attachments?` returns `false`\n- `PostPolicy#upload_cover_photo?` returns `false`\n- `PostPolicy#method_missing` returns `true` for all other policy methods ending\n  in `?`, simulating a user with general read access but explicit update/upload\n  denial\n- the replacement authorization service records all `authorize_action` calls\n\nThe open-source repository does not include Avo Pro\u0027s authorization client. The\ncritical observation is independent of which client is plugged in: the vulnerable\nendpoint never invokes `authorize_action` at all, so the call list remains empty.\n\nThe PoC user has `roles: {admin: true}`, which is required only to pass the\ndummy app\u0027s coarse route-level guard:\n\n```ruby\nauthenticate :user, -\u003e(user) { user.is_admin? }\n```\n\nThe vulnerability under test is one layer below that guard: the fine-grained\nrecord/field authorization that Avo Pro/Pundit deployments would normally\nenforce. The dummy route gate is not part of Avo\u0027s upload policy decision. In a\ndeployment where non-admin operators reach Avo through a different\nauthentication rule, `AttachmentsController#create` would still skip\n`authorize_action` for the upload.\n\nPolicy scoping is orthogonal to this finding. Even if `apply_policy` filtered\nthe record set during lookup, `AttachmentsController#create` would still not\nauthorize the upload action itself for records that survive the scope.\n\nThe spec demonstrates:\n\n1. Normal record update is denied by policy and does not persist changes.\n2. Direct upload with `attachment_key=cover_photo` succeeds even though\n   `PostPolicy#upload_cover_photo?` returns `false`, replacing the existing\n   `has_one_attached` `cover_photo` blob.\n3. Direct upload with `attachment_key=attachments` succeeds even though\n   `PostPolicy#upload_attachments?` returns `false`, adding to a\n   `has_many_attached` association.\n4. Direct upload with `params[:key]` and no attachment association succeeds,\n   creates an `ActiveStorage::Blob`, and returns `url`/`href` without attaching\n   the blob to the record.\n5. The direct upload requests do not invoke the replacement authorization\n   service at all.\n\nThe full request-spec patch can be provided in this advisory thread if useful.\n\nVerification environment:\n\n- Ruby `3.3.1`\n- Avo `3.31.2`\n- Commit `46aa6b3bc9e3283110c39e58cfec8bb95adc1897`\n\n### Impact\n\nThis is a missing server-side authorization vulnerability in Avo\u0027s direct\nattachment upload endpoint.\n\nThe primary affected deployments are Avo Pro/Advanced-style multi-role\ndeployments where non-administrator or restricted operator users can reach Avo,\nand per-record/per-field operations are expected to be enforced by policies.\n\nIn such deployments, an authenticated Avo user can add or replace attachment\ncontent on a resolved record even when the host application policy denies both:\n\n- record update, for example `update?`\n- field-level upload, for example `upload_cover_photo?` or\n  `upload_attachments?`\n\nFor `has_one_attached` fields, the demonstrated impact is replacement of a\nprotected attachment field with attacker-controlled content. The attacker\ncontrols the uploaded binary content, filename, and content-type metadata for\nthe reachable field.\n\nFor key-based/Trix upload flows, the endpoint can persist a blob and return a\nURL even when no attachment association is resolved. This means the endpoint\nshould not be left as an unauthenticated blob creation and URL return path for\nauthenticated Avo users.\n\nIn admin-only deployments following the Avo Community pattern, practical\nexposure is much lower because the only users who can reach the endpoint are\nalready trusted to perform record updates through the normal CRUD path.\n\nSuggested fix direction:\n\n- validate the requested `attachment_key` before any blob is stored\n- perform upload authorization before `ActiveStorage::Blob.create_and_upload!`\n- derive the policy method from the validated association name rather than raw\n  request input\n- apply an equivalent authorization decision to supported `params[:key]` / Trix\n  upload flows before blob creation or URL return\n- return a JSON-compatible `403 Forbidden` response when upload authorization is\n  denied\n\nThe default `Avo::Services::AuthorizationService#authorize_action` returns\n`true` in `lib/avo/services/authorization_service.rb:34-35`, so applications\nwithout a custom authorization client should not see a behavior change from\nadding an authorization call. Deployments with custom/Pro authorization clients\nthat explicitly deny upload would gain enforcement at this endpoint.\n\nNo official Avo-level workaround was confirmed in this review. Until a fix is\navailable, applications can reduce exposure by ensuring only fully trusted\nadministrators can access Avo routes.\n\nApplications needing an immediate mitigation may override or monkey-patch\n`Avo::AttachmentsController#create` to authorize uploads before blob creation.\nAny mitigation should be tested against the application\u0027s Avo authorization\nclient and upload UI, because the endpoint is used by Trix/file upload flows.\nIf a mitigation falls back to `update?` for key-based/Trix uploads, that is a\nconservative behavior change for applications that currently allow read-only\noperators to use those uploads; those deployments should replace the fallback\nwith an explicit rich-text upload policy.",
  "id": "GHSA-pqpw-cvm4-8mv9",
  "modified": "2026-07-09T20:54:10Z",
  "published": "2026-07-09T20:54:10Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/avo-hq/avo/security/advisories/GHSA-pqpw-cvm4-8mv9"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/avo-hq/avo"
    },
    {
      "type": "WEB",
      "url": "https://github.com/avo-hq/avo/releases/tag/v3.32.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Avo: Direct attachment upload endpoint lacks upload authorization and bypasses field-level upload policy"
}