Avo: Direct attachment upload endpoint lacks upload authorization and bypasses field-level upload policy
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_? 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.
- Products
- Not specified
- Affected versions
- Not specified
- Fixed versions
- Not specified
- CVEs
- CVE-2026-53769
- Confirmed fixed CVEs
- Not specified
- Updated in this feed
- 3 Nov 2026, 04:28 UTC · Revision 1
Source evidence
Avo: Direct attachment upload endpoint lacks upload authorization and bypasses field-level upload policy
core-osv · Original sourcePublished 4 Sept 2026, 20:02 UTC
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_? 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.
osv:CVE-2026-53769
Complete source record
{
"id": "31a0903a64f07094c290f76d3c6eba0a0d41cffc7bf71e47fe2e054e8d837a72",
"url": "https://osv.dev/vulnerability/CVE-2026-53769",
"method": "structured",
"payload": {
"kind": "advisory",
"title": "Avo: Direct attachment upload endpoint lacks upload authorization and bypasses field-level upload policy",
"summary": "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_? 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.",
"evidence": "osv:CVE-2026-53769",
"products": [],
"severity": "medium",
"structured": {
"id": "CVE-2026-53769",
"aliases": [
"CVE-2026-53769",
"GHSA-pqpw-cvm4-8mv9"
],
"metrics": [
{
"type": "CVSS_V3",
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N"
}
],
"affected": [
{
"ranges": [
{
"repo": "https://github.com/avo-hq/avo",
"type": "GIT",
"events": [
{
"introduced": "39f6f8e1d24247749fdad1e1d1be13323f09f7c7"
},
{
"fixed": "2aa06624ef6cf7bfd6657cf5b25a2afab29e189d"
},
{
"fixed": "de12070dbac0cb6a7e2bea357f9697f99e92554c"
}
],
"database_specific": {
"extracted_events": [
{
"range": [
{
"introduced": "2.28.0"
},
{
"fixed": "3.32.0"
}
],
"source": "AFFECTED_FIELD",
"strategy": "StringRangeExpression"
},
{
"range": [
{
"fixed": "de12070dbac0cb6a7e2bea357f9697f99e92554c"
}
],
"source": "REFERENCES_COMMIT"
},
{
"range": [
{
"fixed": "2aa06624ef6cf7bfd6657cf5b25a2afab29e189d"
}
],
"source": "REFERENCES_TAG",
"original_tag": "v3.32.0"
}
]
}
}
],
"versions": [
"v3.31.2",
"v3.31.1",
"v3.31.0",
"v3.30.4",
"v3.30.3",
"v3.30.2",
"v3.30.1",
"v3.30.0",
"v3.29.1",
"v3.29.0",
"v3.28.0",
"v3.27.0",
"v3.26.4",
"v3.26.3",
"v3.26.2",
"v3.26.1",
"v3.26.0",
"v3.25.3",
"v3.25.2",
"v3.25.1",
"v3.25.0",
"v3.24.1",
"v3.24.0",
"v3.23.1",
"v3.23.0",
"v3.22.5",
"v3.22.4",
"v3.22.3",
"v3.22.2",
"v3.22.1",
"v3.22.0",
"v3.21.0",
"v3.20.3",
"v3.20.2",
"v3.20.1",
"v3.20.0",
"v3.19.3",
"v3.19.2",
"v3.19.1",
"v3.19.0",
"v3.18.2",
"v3.18.0",
"v3.17.9",
"v3.17.8",
"v3.17.7",
"v3.17.6",
"v3.17.5",
"v3.17.4",
"v3.17.3",
"v3.17.2",
"v3.17.1",
"v3.17.0",
"v3.16.7",
"v3.16.6",
"v3.16.5",
"v3.16.4",
"v3.16.3",
"v3.16.2",
"v3.16.1",
"v3.16.0",
"v3.15.7",
"v3.15.6",
"v3.15.5",
"v3.15.4",
"v3.15.3",
"v3.15.2",
"v3.15.1",
"v3.14.3",
"v3.15.0",
"v3.14.5",
"v3.14.4",
"v3.14.2",
"v3.14.1",
"v3.14.0",
"v3.13.7",
"v3.13.6",
"v3.13.5",
"v3.13.4",
"v3.13.3",
"v3.13.2",
"v3.13.1",
"v3.13.0",
"v3.12.0",
"v3.11.10",
"v3.11.9",
"v3.11.8",
"v3.11.7",
"v3.11.6",
"v3.11.5",
"v3.11.4",
"v3.11.3",
"v3.11.2",
"v3.11.1",
"v3.11.0",
"v3.10.10",
"v3.10.9",
"v3.10.8",
"v3.10.7",
"v3.10.6",
"v3.10.5",
"v3.10.4",
"v3.10.3",
"v3.10.2",
"v3.10.1",
"v3.10.0",
"v3.9.2",
"v3.9.1",
"v3.8.2",
"v3.8.1",
"v3.8.0",
"v3.7.4",
"v3.7.3",
"v3.7.2",
"v3.7.1",
"v3.7.0",
"v3.6.4",
"v3.6.3",
"v3.6.2",
"v3.4.4",
"v3.4.3",
"v3.4.2",
"v3.4.1",
"v3.4.0",
"v3.3.6",
"v3.3.5",
"v3.3.4",
"v3.3.3",
"v3.3.2",
"v3.3.1",
"v3.3.0",
"v3.2.4",
"v3.2.3",
"v3.2.2",
"v3.2.1",
"v3.2.0",
"v3.1.7",
"v3.1.6",
"v3.1.5",
"v3.1.4",
"v3.1.3",
"v3.1.2",
"v3.1.1",
"v3.1.0",
"v3.0.8",
"v3.0.7",
"v3.0.6",
"v3.0.5",
"v3.0.4",
"v3.0.2",
"v2.44.0",
"v2.43.0",
"v2.42.2",
"v2.42.1",
"v2.42.0",
"v2.41.0",
"v2.40.0",
"v2.39.0",
"v2.38.0",
"v2.37.2",
"v2.37.1",
"v2.37.0",
"v2.36.3",
"v2.36.2",
"v2.36.1",
"v2.36.0",
"v2.35.0",
"v2.34.6",
"v2.34.5",
"v2.34.4",
"v2.34.3",
"v2.34.2",
"v2.34.1",
"v2.34.0",
"v2.33.3",
"v2.33.2",
"v2.33.1",
"v2.33.0",
"v2.32.6",
"v2.32.5",
"v2.32.4",
"v2.32.3",
"v2.32.2",
"v2.32.1",
"v2.32.0",
"v2.31.0",
"v2.30.2",
"v2.30.1",
"v2.30.0",
"v2.29.1",
"v2.29.0",
"v2.28.0"
],
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-53769.json"
}
}
],
"modified": "2026-10-28T02:30:25.741612759Z",
"provider": "osv",
"references": [
"https://github.com/avo-hq/avo/releases/tag/v3.32.0",
"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/53xxx/CVE-2026-53769.json",
"https://github.com/avo-hq/avo/security/advisories/GHSA-pqpw-cvm4-8mv9",
"https://nvd.nist.gov/vuln/detail/CVE-2026-53769",
"https://github.com/avo-hq/avo/commit/de12070dbac0cb6a7e2bea357f9697f99e92554c",
"https://github.com/avo-hq/avo/pull/4520"
],
"provider_metadata": {
"cwe_ids": [
"CWE-862",
"CWE-863"
],
"cna_assigner": "GitHub_M",
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/53xxx/CVE-2026-53769.json"
}
},
"related_cves": [
{
"value": "CVE-2026-53769",
"evidence": "/id"
}
],
"security_relevant": true,
"severity_evidence": "/severity/0/score"
},
"source_id": "core-osv",
"document_id": 492454,
"published_at": "2026-09-04T20:02:01.456+00:00"
}