Avo Rails Admin: Authorization Bypass in Association Attach Endpoint Enables Privilege Escalation

Vulnerability Description

Avo's association attach workflow contains a critical authorization bypass rooted in missing access control on the write endpoint. The new action (which renders the attach form) includes authorize_attach_action via before_action, but the create action (which performs the actual mutation via POST /resources/:resource/:id/:related) does not execute the same authorization callback. This creates a classic time-of-check-to-time-of-use (TOCTOU) authorization gap where the security boundary exists only at the UI layer, not at the API boundary. An authenticated attacker can directly POST to the create endpoint, bypassing all attach permission checks.

PoC Significance

The PoC proves that the vulnerability is reliably exploitable by any authenticated user with basic API access—no special privileges required. The precondition is simple: attacker must have a valid session/token. The impact is severe in applications where associations model sensitive domain concepts (team membership, role assignment, tenant association, project ownership), because attackers can unilaterally create relationships without authorization, effectually promoting their own privilege level or accessing sibling tenant data. This is particularly dangerous in multi-tenant SaaS deployments.

Detection Guidance

Log Indicators:

• POST requests to /resources/*/[id]/[association] patterns where corresponding authorization logs are absent or show authorize_attach_action was not invoked
• Successful association creates where the creating user lacks attach permissions in the authorization model
• Spike in failed UI attach attempts followed by successful programmatic POST requests (suggesting UI bypass)

Application-Level Monitoring:

• Audit logs showing association mutations without corresponding attach permission checks
• Cross-tenant association discoveries (e.g., user A attaching user B to tenant B's resources)
• Role/membership changes not initiated through normal workflow channels

YARA/Signature: Look for Rails route definitions exposing associations#create without matching before_action guards on create equivalent to those on new.

Mitigation Steps

1. Patch immediately to the latest Avo version that adds authorize_attach_action before_action to the create method
2. Add before_action in custom code: ensure before_action :authorize_attach_action, only: [:create, :new] is enforced
3. Move authorization to model layer: implement authorization checks in Avo::AssociationsController#create as defensive programming, independent of before_actions
4. Audit existing associations: query application database for associations created by low-privilege users without attach permissions, flag for manual review
5. Implement mutual TLS or token rotation to restrict API access if direct endpoint exposure is unavoidable

Risk Assessment

Likelihood: High—the vulnerability is trivially exploitable (single POST), requires no special network access, and affects all Avo deployments without the patch. Automated scanning for this pattern is straightforward.

Threat Actor Interest: Critical—privilege escalation and cross-tenant data exposure directly enable account takeover, data theft, and lateral movement. This is a prime target for insider threats, opportunistic attackers, and competitors in multi-tenant environments.

Wild Exploitation: The simplicity of exploitation (unauthenticated POST, no payload obfuscation) suggests likelihood of active exploitation if disclosure is public. This should be treated as actively exploited in the wild until organizations patch.