GHSA-qc5p-3mg5-9fh8 CVE-2026-42205
Avo: Broken Access Control Through Unauthorized Execution of Arbitrary Action Classes Across Resources
- 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
- 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:
- Log in to the Avo admin panel with limited permissions.
- Identify a target record ID (e.g., User ID: 1) and a sensitive action class (e.g.,
Avo::Actions::ToggleAdmin). - 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
- URL:
- The server executes the
ToggleAdminlogic on User 1, even though the request was made through thepostsresource 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
| Package | Vulnerable | Fixed 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
Advisories
Packages
Other links
Timeline
- Published
- Last updated by the source
- Latest EPSS score
Related advisories
| Advisory | Severity | Why 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 |
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