Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
8 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Avo's direct attachment upload endpoint lacks server-side upload authorization and bypasses the documented field-level upload policy methods such as upload{FIELDID}?. An authenticated Avo user who can reach the Avo attachment upload endpoint can replace or add attachment content, including binary content, filename, and content-type metadata, on a resolved record even when both update? and upload<field? policies deny the operation. This primarily affects multi-role Avo Pro/Advanced-style deployments where non-administrator or restricted operator users can reach Avo and per-record or per-field operations are expected to be enforced by policies. Details Avo exposes a direct attachment upload endpoint: The vulnerable code path is Avo::AttachmentsController#create: - app/controllers/avo/attachmentscontroller.rb:9-24 Current behavior: This endpoint creates an ActiveStorage::Blob before validating the requested attachment association and before any upload authorization could be…
Recommended action: Upgrade to 3.32.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 4.0.0.beta.51 or 3.32.1 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 actionclass method within app/controllers/avo/actionscontroller.rb. Vulnerable Code The controller identifies the action class to execute solely based on the params[:actionid] 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…
Recommended action: Upgrade to 3.31.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A reflected cross-site scripting (XSS) vulnerability exists in the returnto query parameter used in the avo interface. An attacker can craft a malicious URL that injects arbitrary JavaScript, which is executed when he clicks a dynamically generated navigation button. Impact This vulnerability may allow execution of arbitrary JavaScript in the context of the application. Impact varies depending on deployment: - In unauthenticated setups: exploitable via crafted links sent to users - In authenticated setups: limited to authenticated users and requires interaction
Recommended action: Upgrade to 3.30.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Avo is a framework to create admin panels for Ruby on Rails apps. In Avo 3 pre12, any HTML inside text that is passed to error or succeed in an Avo::BaseAction subclass will be rendered directly without sanitization in the toast/notification that appears in the UI on Action completion. A malicious user could exploit this vulnerability to trigger a cross site scripting attack on an unsuspecting user. This issue has been addressed in the 3.3.0 and 2.47.0 releases of Avo. Users are advised to upgrade.
Recommended action: Upgrade to 3.3.0 or 2.47.0 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A stored cross-site scripting (XSS) vulnerability was found in the keyvalue field of Avo v3.2.3. This vulnerability could allow an attacker to execute arbitrary JavaScript code in the victim's browser. Details The value of the keyvalue is inserted directly into the HTML code. In the current version of Avo (possibly also older versions), the value is not properly sanitized before it is inserted into the HTML code. This vulnerability can be exploited by an attacker to inject malicious JavaScript code into the keyvalue field. When a victim views the page containing the malicious code, the code will be executed in their browser. In avo/fields/common/keyvaluecomponent.html.erb the value is taken in lines 38 and 49 and seems to be interpreted directly as html in lines 44 and 55. PoC To reproduce the vulnerability, follow these steps: 1. Edit an entry with a keyvalue field. 2. Enter the following payload into the value field: 3. Save the entry. 4. Go to the index page and click on…
Recommended action: Upgrade to 3.2.4 or 2.47.0 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The polymorphic field type stores the classes to operate on when updating a record with user input, and does not validate them in the back end. This can lead to unexpected behavior, remote code execution, or application crashes when viewing a manipulated record. Details After reviewing the polymorphic field implementation and performing some black box approaches, we identified a potential security issue related to the use of safeconstantize / constantize. This Rails functionality is capable of searching for classes within the Rails context and returning the class for further use. Because Avo does not validate user input when updating or creating a new polymorphic resource, it is possible to create database entries with completely different or invalid class names than the preselected ones. Avo assumes that the class specified by the user request is a valid one and attempts to work with it, which may result in dangerous behavior and code execution. PoC In the test scenario we…
Recommended action: Upgrade to 2.33.3; some affected versions have no fix yet, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Some avo fields are vulnerable to XSS when rendering html based content. Details During the analysis of the web application, a rendered field was discovered that did not filter JS / HTML tags in a safe way and can be abused to execute js code on a client side. The trix field uses the trix editor in the backend to edit rich text data which basically operates with html tags. To display the stored data in a rendered view, the HasHTMLAttributes concern is used. This can be exploited by an attacker to store javascript code in any trix field by intercepting the request and modifying the post data, as the trix editor does not allow adding custom html or js tags on the frontend. PoC Adding javascript in the post request which is used when editing a "post" resource (body is declared as a trix field) Successful execution of JS code on live demo environment Impact Unlike non-persistent XSS, persistent XSS does not require a social engineering phase. Victims of this attack do not need to…
Recommended action: Upgrade to 2.33.3; some affected versions have no fix yet, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.