diff --git a/gems/crass/GHSA-pq4g-8rxf-4g29.yml b/gems/crass/GHSA-pq4g-8rxf-4g29.yml
new file mode 100644
index 0000000000..a34e68f097
--- /dev/null
+++ b/gems/crass/GHSA-pq4g-8rxf-4g29.yml
@@ -0,0 +1,42 @@
+---
+gem: crass
+ghsa: pq4g-8rxf-4g29
+url: https://github.com/rgrove/crass/security/advisories/GHSA-pq4g-8rxf-4g29
+title: Incorrect tokenization of bad URLs enables CSS sanitizer bypass
+date: 2026-10-21
+description: |
+  ## Summary
+
+  Crass's tokenizer didn't terminate a bad URL token at a ) that followed
+  an escaped backslash (\\). As a result, Crass consumed more input as
+  part of the bad URL than a spec-compliant browser does. CSS sanitizers
+  that parse untrusted CSS with Crass and re-emit it could be tricked
+  into passing through declarations, style rules, or at-rules (including
+  @import) that the sanitizer would otherwise have removed, but that
+  a browser would then parse and apply.
+
+  ## Impact
+
+  Crass by itself only mis-tokenizes input. The security impact is on
+  CSS sanitizers that use Crass to make allow/deny decisions and then
+  re-serialize the CSS. Exploitation requires a sanitizer that doesn't
+  reject bad URL tokens wherever they occur. Confirmed examples:
+
+  - Sanitize (all versions through 7.0.0): Sanitize::CSS.properties,
+    style attributes, Sanitize::CSS.stylesheet, and <style> elements.
+  - Loofah (Loofah::HTML5::Scrub.scrub_css, used for style attributes),
+    and therefore rails-html-sanitizer (sanitize_css, and sanitize when
+    style is a permitted attribute).
+cvss_v4: 5.3
+patched_versions:
+  - ">= 1.0.8"
+related:
+  url:
+    - https://rubygems.org/gems/crass/versions/1.0.8
+    - https://github.com/rgrove/crass/blob/v1.0.8/HISTORY.md#108-2026-10-21
+    - https://github.com/rgrove/crass/compare/v1.0.7...v1.0.8
+    - https://drafts.csswg.org/css-syntax-3/#consume-remnants-of-bad-url
+    - https://github.com/rgrove/crass/security/advisories/GHSA-pq4g-8rxf-4g29
+notes: |
+  - No CVE in GHSA URL.
+  - cvss_v4 from GHSA URL.
diff --git a/gems/view_component/GHSA-8qw7-6phv-7q6p.yml b/gems/view_component/GHSA-8qw7-6phv-7q6p.yml
new file mode 100644
index 0000000000..1c1c7a4568
--- /dev/null
+++ b/gems/view_component/GHSA-8qw7-6phv-7q6p.yml
@@ -0,0 +1,52 @@
+---
+gem: view_component
+ghsa: 8qw7-6phv-7q6p
+url: https://github.com/ViewComponent/view_component/security/advisories/GHSA-8qw7-6phv-7q6p
+title: ViewComponent - Incomplete fix for CVE-2026-54497 — slot and
+  with_content state still leak across reused component instances
+date: 2026-08-28
+description: |
+  ## Summary
+
+  CVE-2026-54497 was fixed by having render_in call __vc_reset_render_state!,
+  which clears exactly three ivars (@__vc_controller, @__vc_helpers,
+  @__vc_request) on every render so a reused ViewComponent::Base instance
+  can't leak the previous request's controller/helpers/request. The
+  fix's own comment admits it deliberately leaves two other pieces of
+  render-scoped state untouched: @__vc_set_slots (populated by with_<slot>
+  setters) and @__vc_content_set_by_with_content (populated by with_content),
+  reasoning that these are "populated by callers before render_in runs."
+  That reasoning only holds for the intended one-instance-per-render
+  usage pattern — it breaks down in exactly the reuse/aliasing scenario
+  the CVE fix was written for, because these two ivars hold the actual
+  content/data being rendered (often user- or session-specific), not
+  just framework plumbing.
+
+  ## IMPACT
+
+  Any application that follows the common ViewComponent idiom of
+  pre-populating a component with request/user data via
+  with_content/with_<slot> and then ends up reusing that same instance
+  across two different requests/users — due to caching, pooling,
+  memoization, or the aliasing pattern the vendor's own fix commit
+  explicitly anticipated — leaks the first user's data to the second,
+  despite the CVE-2026-54497 fix having run.
+
+  ## CREDIT
+
+  Yazan Balawneh, Cystack.ps
+cvss_v3: 6.8
+patched_versions:
+  - ">= 4.14.0"
+related:
+  url:
+    - https://github.com/ViewComponent/view_component/blob/main/docs/CHANGELOG.md#4140
+    - https://github.com/ViewComponent/view_component/compare/v4.13.0...v4.14.0
+    - https://github.com/ViewComponent/view_component/pull/2691
+    - https://github.com/ViewComponent/view_component/security/advisories/GHSA-8qw7-6phv-7q6p
+notes: |
+  - No CVE in GHSA URL.
+  - cvss_v3 from GHSA URL.
+  - Note that gem name in view_component and repo name is ViewComponent.
+  - GHSA affected range is "<= 4.12.0", but 4.13.0 is also vulnerable;
+    the fix shipped in 4.14.0 per the view_component CHANGELOG.