Four new alchemy_cms advisories

gems/alchemy_cms/GHSA-3v87-v27q-vf34.yml

@@ -0,0 +1,61 @@
+---
+gem: alchemy_cms
+ghsa: 3v87-v27q-vf34
+url: https://github.com/AlchemyCMS/alchemy_cms/security/advisories/GHSA-3v87-v27q-vf34
+title: Mass-assignment in ingredients_attributes enables STI type
+  confusion and polymorphic-association tampering, leading to
+  stored XSS and Author -> Admin privilege escalation
+date: 2026-11-09
+description: |
+  Alchemy::Admin::ElementsController' permitted nested ingredient
+  attributes with an open hash (ingredients_attributes: {}), and
+  Alchemy::Element accepted them for every ingredient column. A
+  user allowed to edit elements, which in the default role set
+  includes author, the lowest content role, could send a modified
+  PATCH /admin/elements/:id request and:
+
+  * change an ingredient's STI type, for example turn a Text ingredient
+    into an Html ingredient, whose view renders its value unescaped;
+  * point an ingredient's polymorphic related_object at a record of
+    any model in the application;
+  * create ingredients of any type and role that the element's
+    definition does not declare;
+  * replace an ingredient's whole data store.
+
+  No crafted code is needed. The request is an ordinary authenticated
+  form submission, and type and related_object_type only have to name
+  classes that already exist, such as Alchemy::Ingredients::Html.
+
+  ## Impact
+
+  Changing the type gives an author a way to store markup that is
+  rendered unescaped, both on the public site and in the admin page
+  preview where editors and administrators review drafts. A script
+  stored this way runs with the privileges of whoever views the page,
+  so an administrator reviewing an author's draft can have actions
+  performed in their session.
+
+  This adds the most risk on sites that deliberately keep authors
+  from storing HTML, by using only text-like ingredients or by
+  configuring a sanitizer for Richtext ingredients. Richtext
+  ingredients without a sanitizer setting render their HTML as
+  entered, so on sites using them authors can already store markup.
+
+  Pointing related_object at an unrelated record mostly breaks
+  rendering of that ingredient. It exposes data only where the
+  ingredient's view renders something of the related record, for
+  example its to_s.
+cvss_v3: 5.4
+unaffected_versions:
+  - "<= 6.0.0"
+patched_versions:
+  - ">= 8.4.3"
+related:
+  url:
+    - https://rubygems.org/gems/alchemy_cms/versions/8.4.3
+    - https://github.com/AlchemyCMS/alchemy_cms/releases/tag/v8.4.3
+    - https://github.com/AlchemyCMS/alchemy_cms/compare/v8.4.2...v8.4.3
+    - https://github.com/AlchemyCMS/alchemy_cms/security/advisories/GHSA-3v87-v27q-vf34
+notes: |
+  - No CVE from GHSA URL.
+  - cvss_v3 from GHSA URL.

gems/alchemy_cms/GHSA-cqh4-xxr9-qc73.yml

@@ -0,0 +1,40 @@
+---
+gem: alchemy_cms
+ghsa: cqh4-xxr9-qc73
+url: https://github.com/AlchemyCMS/alchemy_cms/security/advisories/GHSA-cqh4-xxr9-qc73
+title: CSRF protection bypassed in admin controllers when
+  current_user_method memoizes the user
+date: 2026-11-09
+description: |
+  Since 8.4.0, Alchemy::BaseController loads the current user in a
+  before_action that runs before the CSRF check. With the default
+  null_session forgery strategy, a forged cross-site request still
+  runs as the signed-in user in apps whose current_user_method memoizes
+  the user (for example the Rails 8 authentication generator or
+  @current_user ||= ...). An attacker can make a signed-in editor or
+  admin change content in the Alchemy admin by getting them to
+  visit a malicious page.
+
+  ## Impact
+
+  Cross-site request forgery against the Alchemy admin. An attacker who
+  gets a signed-in Alchemy user to visit a malicious page can perform
+  any state-changing admin action that user is allowed to do: edit,
+  publish or delete pages and elements, manage attachments and pictures,
+  and, for admins, manage sites, languages and users where the host
+  app exposes that. Only apps whose current_user_method memoizes the
+  user are affected. Devise-based apps appear to be safe.
+cvss_v3: 6.5
+unaffected_versions:
+  - "<= 8.3.10"
+patched_versions:
+  - ">= 8.4.3"
+related:
+  url:
+    - https://rubygems.org/gems/alchemy_cms/versions/8.4.3
+    - https://github.com/AlchemyCMS/alchemy_cms/releases/tag/v8.4.3
+    - https://github.com/AlchemyCMS/alchemy_cms/compare/v8.4.2...v8.4.3
+    - https://github.com/AlchemyCMS/alchemy_cms/security/advisories/GHSA-cqh4-xxr9-qc73
+notes: |
+  - No CVE from GHSA URL.
+  - cvss_v3 from GHSA URL.

gems/alchemy_cms/GHSA-pfx8-f77c-5gp5.yml

@@ -0,0 +1,43 @@
+---
+gem: alchemy_cms
+ghsa: pfx8-f77c-5gp5
+url: https://github.com/AlchemyCMS/alchemy_cms/security/advisories/GHSA-pfx8-f77c-5gp5
+title: CSS Injection via Unescaped Cookie in AlchemyCMS Admin Layout
+date: 2026-11-09
+description: |
+  The admin layout wrote the value of the alchemy-elements-window-width
+  cookie into the style attribute of the admin <body> without checking it:
+
+  <%= content_tag :body, id: 'alchemy',
+    class: alchemy_body_class,
+    style: cookies["alchemy-elements-window-width"] &&
+    "--elements-window-width: #{cookies["alchemy-elements-window-width"]}px" do %>
+
+  The admin JavaScript sets this cookie to the width the user dragged
+  the elements window to. A cookie value like 1; background:
+  url(//attacker.example) ends the custom property and adds further
+  CSS declarations to the body's inline style.
+
+  ## Impact
+
+  Rails escapes the attribute value, so the cookie cannot add HTML or
+  script, only CSS declarations on the <body> element. With those an
+  attacker can change how the admin interface looks, for example hide
+  or cover parts of it, or load a background image from a server they
+  control and learn when the page was opened. Inline styles have no
+  selectors, so CSS techniques that read form values or other page
+  content do not apply.
+cvss_v3: 3.1
+unaffected_versions:
+  - "<= 7.4.0"
+patched_versions:
+  - ">= 8.4.3"
+related:
+  url:
+    - https://rubygems.org/gems/alchemy_cms/versions/8.4.3
+    - https://github.com/AlchemyCMS/alchemy_cms/releases/tag/v8.4.3
+    - https://github.com/AlchemyCMS/alchemy_cms/compare/v8.4.2...v8.4.3
+    - https://github.com/AlchemyCMS/alchemy_cms/security/advisories/GHSA-pfx8-f77c-5gp5
+notes: |
+  - No CVE from GHSA URL.
+  - cvss_v3 from GHSA URL.

gems/alchemy_cms/GHSA-x84w-hjc5-6pqw.yml

@@ -0,0 +1,33 @@
+---
+gem: alchemy_cms
+ghsa: x84w-hjc5-6pqw
+url: https://github.com/AlchemyCMS/alchemy_cms/security/advisories/GHSA-x84w-hjc5-6pqw
+title: Stored XSS via unvalidated URL schemes in menu nodes
+  and linkable ingredients
+date: 2026-11-09
+description: |
+  Alchemy::Node validated its url with a pattern that accepted any URI
+  scheme, and the linkable ingredients (Link, Text, Picture) never
+  validated their url at all. A user with permission to edit menus or
+  element content could therefore store a javascript: url, which the
+  menu template and the ingredient view components render as the href
+  of an <a> element. Activating such a link executes the stored script
+  in the site's origin, with the privileges of whoever clicked it.
+cvss_v3: 5.4
+patched_versions:
+  - ">= 8.4.0"
+related:
+  url:
+    - https://rubygems.org/gems/alchemy_cms/versions/8.4.0
+    - https://github.com/AlchemyCMS/alchemy_cms/releases/tag/v8.4.0
+    - https://github.com/AlchemyCMS/alchemy_cms/pull/4416
+    - https://github.com/AlchemyCMS/alchemy_cms/pull/4233
+    - https://github.com/AlchemyCMS/alchemy_cms/pull/4234
+    - https://github.com/AlchemyCMS/alchemy-devise/pull/312
+    - https://github.com/AlchemyCMS/alchemy_cms/security/advisories/GHSA-x84w-hjc5-6pqw
+notes: |
+  - No CVE from GHSA URL.
+  - cvss_v3 from GHSA URL.
+  - See commit below: "Note that alchemy-devise moved into alchemy_cms"
+    - See README at https://github.com/AlchemyCMS/alchemy-devise
+    - https://github.com/AlchemyCMS/alchemy-devise/commit/fbc106641d0e312b3c5f9c09c6ae191a211534ce