### 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 ```ruby 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:** 01. Log in to the Avo admin panel with limited permissions. 02. Identify a target record ID (e.g., User ID: 1) and a sensitive action class (e.g., `Avo::Actions::ToggleAdmin`). 03. 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` 04. The server executes the `ToggleAdmin` logic on User 1, even though the request was made through the `posts` resource context. **PoC Script Snippet:** ```python # 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: ```ruby 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
### 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 ```ruby 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:** 01. Log in to the Avo admin panel with limited permissions. 02. Identify a target record ID (e.g., User ID: 1) and a sensitive action class (e.g., `Avo::Actions::ToggleAdmin`). 03. 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` 04. The server executes the `ToggleAdmin` logic on User 1, even though the request was made through the `posts` resource context. **PoC Script Snippet:** ```python # 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: ```ruby 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
Update avo to 3.31.2 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanAvo: Broken Access Control Through Unauthorized Execution of Arbitrary Action Classes Across Resources affects avo (rubygems). Severity is high. ### 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 ```ruby 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:** 01. Log in to the Avo admin panel with limited permissions. 02. Identify a target record ID (e.g., User ID: 1) and a sensitive action class (e.g., `Avo::Actions::ToggleAdmin`). 03. 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` 04. The server executes the `ToggleAdmin` logic on User 1, even though the request was made through the `posts` resource context. **PoC Script Snippet:** ```python # 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: ```ruby 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
AI coding agents often install or upgrade packages automatically in rubygems. A high vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| avorubygems | <3.31.2 | 3.31.2 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL GuardUpdate avo to 3.31.2 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanAvo: Broken Access Control Through Unauthorized Execution of Arbitrary Action Classes Across Resources affects avo (rubygems). Severity is high. ### 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 ```ruby 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:** 01. Log in to the Avo admin panel with limited permissions. 02. Identify a target record ID (e.g., User ID: 1) and a sensitive action class (e.g., `Avo::Actions::ToggleAdmin`). 03. 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` 04. The server executes the `ToggleAdmin` logic on User 1, even though the request was made through the `posts` resource context. **PoC Script Snippet:** ```python # 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: ```ruby 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
AI coding agents often install or upgrade packages automatically in rubygems. A high vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| avorubygems | <3.31.2 | 3.31.2 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL Guard