CVE-2026-55518 is a critical-severity missing authorization vulnerability in avo (rubygems), affecting versions <= 3.32.0. It is fixed in 3.32.1, 4.0.0.beta.51.
Summary A critical missing authorization flaw exists in Avo's association attach workflow. The UI and GET /resources/:resource/:id/:related/new path can check attach<association>?, but the actual write endpoint, POST /resources/:resource/:id/:related, does not run the same authorization check before mutating the association. As a result, an authenticated low-privileged Avo user can bypass hidden/disabled attach controls and directly attach related records to a parent record by sending a crafted POST request. In applications where associations represent teams, tenants, roles, projects, users, memberships, ownership, or other authorization-bearing relationships, this can lead to privilege escalation and cross-tenant data exposure. Details The association attach route writes relationships through Avo::AssociationsController#create: The controller registers an attach authorization callback only for new, not for create: The new action is only the form-rendering step. The actual mutation happens in create: createassociation then attaches the attacker-supplied related record to the parent: The only attach-specific authorization helper is: Because this helper is bound only to new, a policy that denies attachusers?, attachteams?, attachroles?, or similar methods blocks the UI/form path but does not protect the write path. This is inconsistent with the detach path, which does authorize the mutating destroy action: The bug is especially dangerous because Avo already treats association authorization as an access-control boundary in UI components: However, server-side enforcement is missing on the actual attach POST endpoint. Proof of Concept Prerequisites: A Rails application mounts Avo, for example at /admin. Avo authorization is enabled. A low-privileged user can authenticate to Avo. A parent record and a related record are both reachable by ID. The relevant policy denies attaching the relationship, for example: Example target scenario: Parent resource: projects Parent ID: 1 Related association: users Related user ID to attach: 42 Expected policy: low-privileged users must not be able to attach users to projects. The UI/form request may be blocked: But the direct write endpoint can still be invoked: Run the attached PoC: If GET /new is forbidden or redirected but the direct POST succeeds, the authorization bypass is confirmed. To perform the actual attach: Expected vulnerable result: The low-privileged user can attach the related record despite attach<association>? being denied. The parent record now includes the related record. Impact This vulnerability allows unauthorized relationship manipulation through Avo. Depending on the affected association, the impact can include: Privilege escalation by attaching a user to an admin group, privileged project, tenant, organization, role, or membership record. Cross-tenant data exposure when tenant/user/project membership determines record visibility. Integrity loss by changing ownership, assignment, access-control relationships, or business workflow state. Policy bypass even when Avo UI controls correctly hide the attach button or deny the attach form. Recommended Fix Enforce attach authorization on the mutating endpoint. At minimum: Additionally: Authorize against the parent record and the selected related record before writing the relationship. Ensure create fails closed when attach<association>? is missing and explicitauthorization is enabled. Add regression tests that directly POST to /resources/:resourcename/:id/:relatedname while attach<association>? returns false. Verify hasmany, hasone, hasmany :through, and hasandbelongstomany association paths all enforce the same server-side authorization.
The application does not perform an authorization check before performing a sensitive operation. Typical impact: unauthorized access to restricted functionality or data.
CVE-2026-55518 has a CVSS score of 9.6 (Critical). The vector is network-reachable, low privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment.
A fixed version is available (3.32.1, 4.0.0.beta.51). Upgrading removes the vulnerable code path.
rubygems
avo (<= 3.32.0)avo (>= 4.0.0.beta.1, < 4.0.0.beta.51)avo → 3.32.1 (rubygems)avo → 4.0.0.beta.51 (rubygems)Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter instead of chasing every advisory.
Kodem's runtime-powered SCA identifies whether CVE-2026-55518 is reachable in your applications. Explore open-source security for your team.
See if CVE-2026-55518 is reachable in your applications. Get a demo
Upgrade the following packages to resolve this vulnerability:
avo to 3.32.1 or lateravo to 4.0.0.beta.51 or laterKodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.
CVE-2026-55518 is a critical-severity missing authorization vulnerability in avo (rubygems), affecting versions <= 3.32.0. It is fixed in 3.32.1, 4.0.0.beta.51. The application does not perform an authorization check before performing a sensitive operation.
CVE-2026-55518 has a CVSS score of 9.6 (Critical). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
avo (rubygems) versions <= 3.32.0 is affected.
Yes. CVE-2026-55518 is fixed in 3.32.1, 4.0.0.beta.51. Upgrade to this version or later.
Whether CVE-2026-55518 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
avo to 3.32.1 or lateravo to 4.0.0.beta.51 or later