Four new (avo, ransack) advisories

gems/avo/GHSA-h7x6-9mqf-vgmx.yml

@@ -0,0 +1,53 @@
+---
+gem: avo
+ghsa: h7x6-9mqf-vgmx
+url: https://github.com/avo-hq/avo/security/advisories/GHSA-h7x6-9mqf-vgmx
+title: Global Avo.configuration.locale mutation via
+  params[:set_locale] (process-wide state poisoning)
+date: 2026-10-22
+description: |
+  ## SUMAMRY
+
+  ?set_locale= wrote the request's value into Avo.configuration.locale,
+  a setting shared by every request the Ruby process serves. It did
+  so before Avo's authenticate block ran.
+
+  * An unknown locale (?set_locale=zz) was stored, and every later Avo
+    request from every user raised I18n::InvalidLocale (HTTP 500) until
+    the process restarted.
+
+  * A valid locale changed the admin language for every user.
+
+  * In apps that authenticate through config.authenticate_with rather
+    than a route constraint, both worked without signing in.
+
+  ## Impact
+
+  * Persistent corruption of the application-wide locale setting. The most
+    direct fallout is that translation lookups using Avo.configuration.locale
+    (rather than per-request I18n.locale) return missing-translation strings
+    or fall back unpredictably for every user.
+
+  * More importantly, this is a confidentiality-and-integrity-grade bug
+    pattern: query string params should not write to global singletons.
+    Any future code that reads Avo.configuration.locale (e.g. for caching
+    keys, log routing, default behavior) inherits the corruption automatically.
+
+  * Combining locale corruption with params[:force_locale] (set_force_locale)
+    and other I18n.with_locale paths can be used to force missing-translation
+    behavior for other admins (denial-of-service of the UI for the
+    attacker's chosen scope).
+cvss_v3: 8.2
+patched_versions:
+  - "~> 3.33.1"
+  - ">= 4.3.1"
+related:
+  url:
+    - https://rubygems.org/gems/avo/versions/4.3.1
+    - https://github.com/avo-hq/avo/releases/tag/v4.3.1
+    - https://rubygems.org/gems/avo/versions/3.33.1
+    - https://github.com/avo-hq/avo/releases/tag/v3.33.1
+    - https://github.com/avo-hq/avo/security/advisories/GHSA-h7x6-9mqf-vgmx
+notes: |
+  - No CVE in GHSA URL.
+  - cvss_v3 from GHSA URL.

gems/avo/GHSA-x65r-p6hf-94hv.yml

@@ -0,0 +1,56 @@
+---
+gem: avo
+ghsa: x65r-p6hf-94hv
+url: https://github.com/avo-hq/avo/security/advisories/GHSA-x65r-p6hf-94hv
+title: Missing authorization on Avo association show endpoint
+  exposes related records
+date: 2026-10-22
+description: |
+  ## SUMAMRY
+
+  GET /resources/:resource_name/:id/:related_name/:related_id shows
+  one record through its parent, for example /resources/users/42/orders/7.
+  That route checked no policy: not the related resource's show?, not
+  its policy scope, and not the parent's view_<association>?. A signed-in
+  Avo user who could open a parent record could open every record
+  associated with it, including records the related resource's policy
+  denied them. has_one fields on show pages load their content through
+  the same route.
+
+  This affects apps that authorize with a policy client: avo-authorization
+  on Avo 4, avo-pro on Avo 3. Without one, Avo runs no policies, by design.
+
+  The route has lacked this check since avo 2.12.0.
+
+  ## Impact
+
+  The prerequisite is an authenticated Avo session with a configured
+  authorization provider (for example Pundit policies, the documented
+  and expected production setup where explicit_authorization defaults
+  to true). Within that setup, an attacker needs only scope access to
+  a parent record, which is the normal baseline for any authenticated
+  user (for example their own user record). From there they can request
+  the show view of any record associated with that parent, even when
+  the related resource's show? policy would otherwise deny access.
+  The demonstrated capability is unauthorized read of all show-visible
+  fields of the related record. The severity of the exposure depends
+  on the sensitivity of fields configured on the related resource (for
+  example tokens, financial fields, or personal data), since those
+  fields are rendered in the show view. This is a read-only exposure;
+  it does not by itself allow modification of data.
+cvss_v3: 6.5
+unaffected_versions:
+  - "< 2.12.0"
+patched_versions:
+  - "~> 3.33.2"
+  - ">= 4.3.4"
+related:
+  url:
+    - https://rubygems.org/gems/avo/versions/4.3.4
+    - https://github.com/avo-hq/avo/releases/tag/v4.3.4
+    - https://rubygems.org/gems/avo/versions/3.33.2
+    - https://github.com/avo-hq/avo/releases/tag/v3.33.2
+    - https://github.com/avo-hq/avo/security/advisories/GHSA-x65r-p6hf-94hv
+notes: |
+  - No CVE in GHSA URL.
+  - cvss_v3 from GHSA URL.

gems/ransack/GHSA-j3f8-w227-4hh8.yml

@@ -0,0 +1,45 @@
+---
+gem: ransack
+ghsa: j3f8-w227-4hh8
+url: https://github.com/activerecord-hackery/ransack/security/advisories/GHSA-j3f8-w227-4hh8
+title: Ransack - quadratic-time parsing of a single search key
+  enables unauthenticated CPU-exhaustion DoS
+date: 2026-09-22
+description: |
+  ## SUMMARY
+
+  A single Ransack search key is parsed in time quadratic in the number
+  of _-separated segments it contains. The number of segments is
+  attacker-controlled (it is just the length of the key in the query
+  string), and Rack does not limit the length of an individual parameter
+  key, so one crafted request can burn seconds of CPU on a web worker.
+  A handful of concurrent requests exhausts the worker pool, giving
+  an unauthenticated, low-complexity denial of service on any endpoint
+  that calls ransack.
+
+  This is the same class of issue as GHSA-vxc9-rm8f-p56j (crafted params
+  -> resource exhaustion), on a different code path.
+
+  ## Impact
+
+  Unauthenticated denial of service via CPU exhaustion against any
+  application exposing a Ransack search endpoint (the common case).
+  Low attack complexity, no privileges, availability impact only.
+
+  ## Credit
+
+  Found during a security audit of the project.
+patched_versions:
+  - "~> 4.4.3"
+  - "~> 5.0.2"
+  - ">= 6.0.0"
+related:
+  url:
+    - https://rubygems.org/gems/ransack/versions/5.0.1
+    - https://github.com/activerecord-hackery/ransack/releases/tag/v5.0.1
+    - https://rubygems.org/gems/ransack/versions/4.4.2
+    - https://github.com/activerecord-hackery/ransack/releases/tag/v4.4.2
+    - https://github.com/activerecord-hackery/ransack/security/advisories/GHSA-j3f8-w227-4hh8
+notes: |
+  - GHSA URL had "High" severity.
+  - No CVE in GHSA URL.

gems/ransack/GHSA-vxc9-rm8f-p56j.yml

@@ -0,0 +1,43 @@
+---
+gem: ransack
+ghsa: vxc9-rm8f-p56j
+url: https://github.com/activerecord-hackery/ransack/security/advisories/GHSA-vxc9-rm8f-p56j
+title: Ransack has a memory-exhaustion DoS via unbounded
+  attribute position field in query params
+date: 2026-09-22
+description: |
+  ## SUMMARY
+
+  Ransack has a memory-exhaustion DoS via unbounded attribute
+  position field in query params
+
+  ## Impact
+
+  This is (assuming any Ransack-using endpoint is accessible without
+  auth, or any endpoint that performs a query before checking auth)
+  an unauthenticated, low-complexity denial of service attack via
+  memory exhaustion.
+
+  Any application that exposes a Ransack-backed search endpoint to
+  untrusted input (which would be most of them) is affected. A single
+  crafted request crashes the worker process serving it, and the
+  attack depends on very minimal knowledge of the schema, and is not
+  mitigated by any Rails best practices (strong params, ransack
+  attribute whitelisting, etc.) that I am aware of.
+
+  All versions of Ransack since the initial release until the patch
+  which mitigates it are vulnerable to this problem.
+cvss_v3: 7.5
+patched_versions:
+  - "~> 4.4.2"
+  - ">= 5.0.1"
+related:
+  url:
+    - https://rubygems.org/gems/ransack/versions/5.0.1
+    - https://github.com/activerecord-hackery/ransack/releases/tag/v5.0.1
+    - https://rubygems.org/gems/ransack/versions/4.4.2
+    - https://github.com/activerecord-hackery/ransack/releases/tag/v4.4.2
+    - https://github.com/activerecord-hackery/ransack/security/advisories/GHSA-vxc9-rm8f-p56j
+notes: |
+  - cvss_v3 from GHSA URL.
+  - No CVE in GHSA URL.