Skip to content

GHSA-qc5p-3mg5-9fh8 CVE-2026-42205

Avo: Broken Access Control Through Unauthorized Execution of Arbitrary Action Classes Across Resources

High RubyGems
Severity
8.8 / 10
High · CVSS 3.1
Exploit chance (EPSS)
0.29%
Chance of exploitation in the next 30 days. Higher than 22.13% of scored vulnerabilities.
Known exploited
No
Not in CISA's catalog
Weakness
CWE-284 Improper Access Control
CWE-639 Authorization Bypass Through User-Controlled Key
Fix
3.31.2
Upgrade avo to this version or later

Description

Summary

A critical Broken Access Control vulnerability was identified in the ActionsController of the Avo framework (v3.x). Due to insecure action lookup logic, an authenticated user can execute any Action class (descendants of Avo::BaseAction) on any resource, even if the action is not registered for that specific resource. This leads to Privilege Escalation and unauthorized data manipulation across the entire application.

Details

The vulnerability exists in the action_class method within app/controllers/avo/actions_controller.rb.

Vulnerable Code

def action_class
  # It searches through ALL descendants of BaseAction without resource validation
  Avo::BaseAction.descendants.find do |action|
    action.to_s == params[:action_id]
  end
end

The controller identifies the action class to execute solely based on the params[:action_id] by searching through all BaseAction descendants. It fails to verify whether the requested action is actually permitted or registered for the resource context specified in the request URL (e.g., /admin/resources/posts/actions).

Consequently, an attacker can invoke sensitive actions (e.g., Avo::Actions::ToggleAdmin) through an unrelated resource endpoint (e.g., Post), bypassing the intended resource-action mapping.

Impact

This flaw results in significant security risks:

  • Privilege Escalation: An authenticated user with low privileges can execute administrative actions (like toggling admin roles) to escalate their own or others' permissions.
  • Unauthorized Operations: Actions designed for restricted resources can be triggered against any record ID in the database.
  • Data Integrity Compromise: Attackers can perform unauthorized destructive operations (e.g., Delete, Archive, or Update) on records they should not have access to.

Proof of Concept (PoC)

Steps to Reproduce:

  1. Log in to the Avo admin panel with limited permissions.
  2. Identify a target record ID (e.g., User ID: 1) and a sensitive action class (e.g., Avo::Actions::ToggleAdmin).
  3. Send a POST request to a resource endpoint where the target action is not registered:
    • URL: POST /admin/resources/posts/actions
    • Payload: action_id=Avo::Actions::ToggleAdmin&fields[avo_resource_ids]=1
  4. The server executes the ToggleAdmin logic on User 1, even though the request was made through the posts resource context.

PoC Script Snippet:

# Simulating the unauthorized action execution
data = {
    'action_id': 'Avo::Actions::ToggleAdmin',
    'fields[avo_resource_ids]': '1', # Target Record ID
    'authenticity_token': csrf_token
}
response = session.post(f"{BASE_URL}/admin/resources/posts/actions", data=data)

Remediation

Restrict the action lookup to only those actions explicitly registered for the current resource context:

def action_class
  # Validate that the action is registered for the current resource
  @resource.get_actions.find do |action|
    action.to_s == params[:action_id]
  end
end

Discoverer

Illunight

Affected versions

RubyGems

PackageVulnerableFixed in
avo
< 3.31.2
3.31.2

How to fix

Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.

avo RubyGems → 3.31.2

bundler
bundle update avo # Gemfile: gem "avo", ">= 3.31.2"

Severity breakdown

CVSS 3.1 8.8

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Attack vector
Network
Attack complexity
Low
Privileges required
Low
User interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
High

Weakness

CWE-284: Improper Access Control

The product does not restrict or incorrectly restricts access to a resource from an unauthorized actor.

How to prevent it
  • Architecture and Design, Operation: Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software.
  • Architecture and Design: Compartmentalize the system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area. Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.

CWE-639: Authorization Bypass Through User-Controlled Key

The system's authorization functionality does not prevent one user from gaining access to another user's data or record by modifying the key value identifying the data.

How to prevent it
  • Architecture and Design: For each and every data access, ensure that the user has sufficient privilege to access the record that is being requested.
  • Architecture and Design, Implementation: Make sure that the key that is used in the lookup of a specific user's record is not controllable externally by the user or that any tampering can be detected.
  • Architecture and Design: Use encryption in order to make it more difficult to guess other legitimate values of the key or associate a digital signature with the key so that the server can verify that there has been no tampering.

References

Timeline

  1. Published
  2. Last updated by the source
  3. Latest EPSS score
AdvisorySeverityWhy it's related
GHSA-pqpw-cvm4-8mv9
Avo: Direct attachment upload endpoint lacks upload authorization and bypasses field-level upload policy
Medium Also affects avo
GHSA-8fq9-273g-6mrg
Avo: Missing Authorization in Avo Association Attach Endpoint Allows Unauthorized Relationship Manipulation and Privilege Escalation
Critical Also affects avo
GHSA-762r-27w2-q22j
Avo has a XSS vulnerability on `return_to` param
Medium Also affects avo
GHSA-g8vp-2v5p-9qfh
Cross-site scripting (XSS) in Action messages on Avo
Medium Also affects avo
GHSA-ghjv-mh6x-7q6h
avo vulnerable to stored cross-site scripting (XSS) in key_value field
Medium Also affects avo
GHSA-86h2-2g4g-29qx
avo possible unsafe reflection / partial DoS vulnerability
High Also affects avo
GHSA-5cr9-5jx3-2g39
avo vulnerable to Stored XSS (Cross Site Scripting) in html content based fields
High Also affects avo
GHSA-8g5g-mxqh-grgj
Vite: `server.fs.deny` bypassed with queries
Medium Same weakness, CWE-284
Is this in your code?

MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.

Check your repos with MergeHarbor