diff --git a/gems/dalli/GHSA-3553-vcg5-72jw.yml b/gems/dalli/GHSA-3553-vcg5-72jw.yml
new file mode 100644
index 0000000000..6f59f5ced4
--- /dev/null
+++ b/gems/dalli/GHSA-3553-vcg5-72jw.yml
@@ -0,0 +1,43 @@
+---
+gem: dalli
+ghsa: 3553-vcg5-72jw
+url: https://github.com/petergoldstein/dalli/security/advisories/GHSA-3553-vcg5-72jw
+title: Unbounded decompression and reply sizes allow memory exhaustion
+date: 2026-10-05
+description: |
+  1. Values flagged as compressed were inflated with no size limit. A
+     ~130 KB stored item expands to 128 MB on read (about 1000:1),
+     regardless of the client's `compress` or `serializer` settings.
+  2. The size in a reply (a meta `VA <size>`, or a binary body length) was
+     used to read or buffer that many bytes, so a hostile or compromised
+     server could make the client allocate gigabytes.
+
+  Exploiting either requires write access to the memcached instance (a
+  shared or exposed instance, another tenant), or a malicious server or
+  proxy. Patched versions add a `decompressed_max_bytes` option (default
+  128 MiB) and reject reply sizes over 1 GiB.
+patched_versions:
+  - "~> 3.2.12"
+  - "~> 4.3.6"
+  - "~> 5.0.9"
+  - "~> 5.1.3"
+  - ">= 5.2.1"
+related:
+  url:
+    - https://github.com/petergoldstein/dalli/security/advisories/GHSA-3553-vcg5-72jw
+    - https://github.com/petergoldstein/dalli/commit/39d2f72
+    - https://rubygems.org/gems/dalli/versions/5.2.1
+    - https://github.com/petergoldstein/dalli/releases/tag/v5.2.1
+    - https://rubygems.org/gems/dalli/versions/5.1.3
+    - https://github.com/petergoldstein/dalli/releases/tag/v5.1.3
+    - https://rubygems.org/gems/dalli/versions/5.0.9
+    - https://github.com/petergoldstein/dalli/releases/tag/v5.0.9
+    - https://rubygems.org/gems/dalli/versions/4.3.6
+    - https://github.com/petergoldstein/dalli/releases/tag/v4.3.6
+    - https://rubygems.org/gems/dalli/versions/3.2.12
+    - https://github.com/petergoldstein/dalli/releases/tag/v3.2.12
+notes: |
+  - No CVE in GHSA.
+     - "A CVE has been requested through GitHub but not yet
+        assigned, so the entry has no cve: field."
+  - No CVSS score in GHSA; GitHub severity is medium.
diff --git a/gems/dalli/GHSA-4qp6-2jcr-596v.yml b/gems/dalli/GHSA-4qp6-2jcr-596v.yml
new file mode 100644
index 0000000000..d2f639f789
--- /dev/null
+++ b/gems/dalli/GHSA-4qp6-2jcr-596v.yml
@@ -0,0 +1,51 @@
+---
+gem: dalli
+ghsa: 4qp6-2jcr-596v
+url: https://github.com/petergoldstein/dalli/security/advisories/GHSA-4qp6-2jcr-596v
+title: Routing tokens can inject meta protocol flags, and failed requests can
+  retry forever
+date: 2026-10-05
+description: |
+  1. `p_token` and `l_token` were checked only for CR, LF and NUL. A token
+     containing spaces added arbitrary meta flags to the command: for
+     example changing an item's TTL on a read, creating stub items on a
+     miss, turning a delete into a stale tombstone, choosing `incr`'s
+     initial value, or reading a different key. Affects 5.1.0 and later.
+  2. Failed requests were retried without a limit. Each retry reconnected
+     successfully, which reset the failure count, so `socket_max_failures`
+     was never reached and requests to a server that accepts connections
+     but never replies (or drops the connection on a request) hung
+     forever. Affects all versions.
+  3. Errors raised by application code inside a `get_multi` block
+     (`Errno::*`, `Timeout::Error`) were treated as socket errors and
+     retried the whole `get_multi`, causing duplicate yields, swallowed
+     exceptions, or an endless loop. Affects 4.x and 5.x.
+
+  ### Workarounds
+
+  Don't pass untrusted input as a routing token.
+patched_versions:
+  - "~> 3.2.12"
+  - "~> 4.3.6"
+  - "~> 5.0.9"
+  - "~> 5.1.3"
+  - ">= 5.2.1"
+related:
+  url:
+    - https://github.com/petergoldstein/dalli/security/advisories/GHSA-4qp6-2jcr-596v
+    - https://github.com/petergoldstein/dalli/commit/f8f7a21
+    - https://rubygems.org/gems/dalli/versions/5.2.1
+    - https://github.com/petergoldstein/dalli/releases/tag/v5.2.1
+    - https://rubygems.org/gems/dalli/versions/5.1.3
+    - https://github.com/petergoldstein/dalli/releases/tag/v5.1.3
+    - https://rubygems.org/gems/dalli/versions/5.0.9
+    - https://github.com/petergoldstein/dalli/releases/tag/v5.0.9
+    - https://rubygems.org/gems/dalli/versions/4.3.6
+    - https://github.com/petergoldstein/dalli/releases/tag/v4.3.6
+    - https://rubygems.org/gems/dalli/versions/3.2.12
+    - https://github.com/petergoldstein/dalli/releases/tag/v3.2.12
+notes: |
+  - No CVE in GHSA.
+     - "A CVE has been requested through GitHub but not yet
+        assigned, so the entry has no cve: field."
+  - No CVSS score in GHSA; GitHub severity is medium.
diff --git a/gems/dalli/GHSA-m252-9cgf-vx2w.yml b/gems/dalli/GHSA-m252-9cgf-vx2w.yml
new file mode 100644
index 0000000000..3b22a1c027
--- /dev/null
+++ b/gems/dalli/GHSA-m252-9cgf-vx2w.yml
@@ -0,0 +1,49 @@
+---
+gem: dalli
+ghsa: m252-9cgf-vx2w
+url: https://github.com/petergoldstein/dalli/security/advisories/GHSA-m252-9cgf-vx2w
+title: With a namespace, a retried request reads or writes a different key
+date: 2026-10-05
+description: |
+  When a client is configured with a `namespace`, a request that hits a
+  transient network error (a timeout, or a connection closed by memcached
+  or a proxy, such as stale connections after a memcached restart) was
+  retried with the namespace applied a second time, so `app:x` became
+  `app:app:x`. A retried read could return a different key's value, and a
+  retried write could overwrite a different key. Where cache keys include
+  user input, a user who can choose a key of the form `app:<something>`
+  can arrange for another user's retried read to return attacker-chosen
+  data.
+
+  Affected: every single-key operation since 5.0.3, single-server
+  `get_multi` since 5.1.0, and `get_with_metadata` and `fetch_with_lock`
+  since 4.1.0. Clients without a namespace are not affected, and 3.2.x is
+  not affected.
+
+  ### Workarounds
+
+  Don't configure a `namespace`; prefix keys in application code instead.
+unaffected_versions:
+  - "< 4.1.0"
+patched_versions:
+  - "~> 4.3.7"
+  - "~> 5.0.10"
+  - "~> 5.1.4"
+  - ">= 5.2.2"
+related:
+  url:
+    - https://github.com/petergoldstein/dalli/security/advisories/GHSA-m252-9cgf-vx2w
+    - https://github.com/petergoldstein/dalli/commit/61a9813
+    - https://rubygems.org/gems/dalli/versions/5.2.2
+    - https://github.com/petergoldstein/dalli/releases/tag/v5.2.2
+    - https://rubygems.org/gems/dalli/versions/5.1.4
+    - https://github.com/petergoldstein/dalli/releases/tag/v5.1.4
+    - https://rubygems.org/gems/dalli/versions/5.0.10
+    - https://github.com/petergoldstein/dalli/releases/tag/v5.0.10
+    - https://rubygems.org/gems/dalli/versions/4.3.7
+    - https://github.com/petergoldstein/dalli/releases/tag/v4.3.7
+notes: |
+  - No CVE in GHSA.
+     - "A CVE has been requested through GitHub but not yet
+        assigned, so the entry has no cve: field."
+  - No CVSS score in GHSA; GitHub severity is high.
diff --git a/gems/dalli/GHSA-p6pm-ch9v-44vx.yml b/gems/dalli/GHSA-p6pm-ch9v-44vx.yml
new file mode 100644
index 0000000000..5958ddc5ba
--- /dev/null
+++ b/gems/dalli/GHSA-p6pm-ch9v-44vx.yml
@@ -0,0 +1,55 @@
+---
+gem: dalli
+ghsa: p6pm-ch9v-44vx
+url: https://github.com/petergoldstein/dalli/security/advisories/GHSA-p6pm-ch9v-44vx
+title: Pipelined get_multi can return another key's value after an error reply
+date: 2026-10-05
+description: |
+  Dalli's pipelined reply parser treated any reply line without a value
+  body (for example `CLIENT_ERROR` or `SERVER_ERROR`) as the `MN` that
+  ends the batch. It stopped reading that server's replies and left the
+  rest on the connection, where later commands read them as their own
+  replies, so a later `get` could return a different key's value.
+
+  memcached answers `CLIENT_ERROR` for a key over 250 bytes on the wire.
+  Dalli checked key length in characters, before base64-encoding keys
+  that need it, so a key of under 250 characters could still be too long.
+  If any part of a cache key comes from user input, a user can trigger
+  this and, in an application that caches per-user data, see another
+  user's data. Affects multi-server `get_multi` (including Rails
+  `read_multi`), `get_multi` with a block, and `get_multi_cas`, with the
+  meta protocol (3.2.0 and later; the default since 5.0.0).
+
+  With the binary protocol (the default before 5.0), the same over-long
+  key made memcached drop the connection, and `get` or `get_multi` with
+  it retried forever, so a user-supplied key could hang requests.
+
+  ### Workarounds
+
+  Keep user-controlled cache keys well under 250 bytes, for example by
+  hashing them.
+patched_versions:
+  - "~> 3.2.12"
+  - "~> 4.3.6"
+  - "~> 5.0.9"
+  - "~> 5.1.3"
+  - ">= 5.2.1"
+related:
+  url:
+    - https://github.com/petergoldstein/dalli/security/advisories/GHSA-p6pm-ch9v-44vx
+    - https://github.com/petergoldstein/dalli/commit/e35c7ad
+    - https://rubygems.org/gems/dalli/versions/5.2.1
+    - https://github.com/petergoldstein/dalli/releases/tag/v5.2.1
+    - https://rubygems.org/gems/dalli/versions/5.1.3
+    - https://github.com/petergoldstein/dalli/releases/tag/v5.1.3
+    - https://rubygems.org/gems/dalli/versions/5.0.9
+    - https://github.com/petergoldstein/dalli/releases/tag/v5.0.9
+    - https://rubygems.org/gems/dalli/versions/4.3.6
+    - https://github.com/petergoldstein/dalli/releases/tag/v4.3.6
+    - https://rubygems.org/gems/dalli/versions/3.2.12
+    - https://github.com/petergoldstein/dalli/releases/tag/v3.2.12
+notes: |
+  - No CVE in GHSA.
+     - "A CVE has been requested through GitHub but not yet
+        assigned, so the entry has no cve: field."
+  - No CVSS score in GHSA; GitHub severity is high.
diff --git a/gems/dalli/GHSA-w39f-xq2m-4g8x.yml b/gems/dalli/GHSA-w39f-xq2m-4g8x.yml
new file mode 100644
index 0000000000..508e061301
--- /dev/null
+++ b/gems/dalli/GHSA-w39f-xq2m-4g8x.yml
@@ -0,0 +1,60 @@
+---
+gem: dalli
+ghsa: w39f-xq2m-4g8x
+url: https://github.com/petergoldstein/dalli/security/advisories/GHSA-w39f-xq2m-4g8x
+title: Forking can resend buffered memcached requests and desynchronize the
+  parent's connection
+date: 2026-10-05
+description: |
+  Dalli buffered request bytes in Ruby's IO write buffer, and quiet
+  (`multi`) blocks don't flush until they end. When the process forks,
+  the child inherits the buffer, and Ruby flushes it when the child closes
+  or finalizes the socket, even if the child never uses Dalli, so the
+  request is sent twice: a buffered write is applied twice, or a buffered
+  non-quiet request leaves the parent's connection off by one reply, so
+  later reads return the previous key's value. Affects 4.2.0 and later.
+
+  With TLS, the child's close sends close_notify on the shared connection
+  and tears down the parent's session. Affects all versions with TLS.
+
+  Applications that fork while threads use a shared client are affected
+  (pre-forking servers, job runners).
+
+  The first fix was incomplete on 4.3.6 and 3.2.12: when another
+  library's fork hook (such as connection_pool's, loaded before Dalli) ran
+  first in the child, the parent's TLS session could still be ended, and
+  4.3.6's write buffer kept a reference to the caller's value string with
+  the meta protocol. Both are fixed in 4.3.7 and 3.2.13.
+
+  ### Workarounds
+
+  Call `close` on Dalli clients before forking, outside any quiet block.
+patched_versions:
+  - "~> 3.2.13"
+  - "~> 4.3.7"
+  - "~> 5.0.9"
+  - "~> 5.1.3"
+  - ">= 5.2.1"
+related:
+  url:
+    - https://github.com/petergoldstein/dalli/security/advisories/GHSA-w39f-xq2m-4g8x
+    - https://github.com/petergoldstein/dalli/commit/62d5ad1
+    - https://rubygems.org/gems/dalli/versions/4.3.7
+    - https://github.com/petergoldstein/dalli/releases/tag/v4.3.7
+    - https://rubygems.org/gems/dalli/versions/3.2.13
+    - https://github.com/petergoldstein/dalli/releases/tag/v3.2.13
+    - https://rubygems.org/gems/dalli/versions/5.2.1
+    - https://github.com/petergoldstein/dalli/releases/tag/v5.2.1
+    - https://rubygems.org/gems/dalli/versions/5.1.3
+    - https://github.com/petergoldstein/dalli/releases/tag/v5.1.3
+    - https://rubygems.org/gems/dalli/versions/5.0.9
+    - https://github.com/petergoldstein/dalli/releases/tag/v5.0.9
+    - https://rubygems.org/gems/dalli/versions/4.3.6
+    - https://github.com/petergoldstein/dalli/releases/tag/v4.3.6
+    - https://rubygems.org/gems/dalli/versions/3.2.12
+    - https://github.com/petergoldstein/dalli/releases/tag/v3.2.12
+notes: |
+  - No CVE in GHSA.
+     - "A CVE has been requested through GitHub but not yet
+        assigned, so the entry has no cve: field."
+  - No CVSS score in GHSA; GitHub severity is medium.
diff --git a/gems/dalli/GHSA-wr87-m4jw-29x5.yml b/gems/dalli/GHSA-wr87-m4jw-29x5.yml
new file mode 100644
index 0000000000..cfdab3cae9
--- /dev/null
+++ b/gems/dalli/GHSA-wr87-m4jw-29x5.yml
@@ -0,0 +1,71 @@
+---
+gem: dalli
+ghsa: wr87-m4jw-29x5
+url: https://github.com/petergoldstein/dalli/security/advisories/GHSA-wr87-m4jw-29x5
+title: Per-request raw and the JSON serializer don't prevent unsafe
+  deserialization
+date: 2026-10-05
+description: |
+  1. Per-request `raw: true` was ignored by some read methods, which still
+     ran the configured serializer's `load` (Marshal by default) on values
+     whose flags say they're serialized: in 5.1 and 5.2, `get_multi`,
+     `get_multi_cas`, `get_multi_with_metadata`, `get_cas` and
+     `get_with_metadata`; in 5.0, `get_with_metadata`; in 4.x, `get`,
+     `gat` and `fetch` with the binary protocol, and `get_with_metadata`;
+     in 3.x, `get`, `gat` and `fetch`.
+  2. `serializer: JSON` resolves to `JSON.load`. With the json gem before
+     3.0, `JSON.load` honors `json_class` when the json additions are
+     loaded, so a crafted value can instantiate classes that define
+     `json_create`.
+
+  Exploiting either requires write access to the memcached instance and
+  an application relying on per-request `raw: true` or `serializer: JSON`
+  to avoid unsafe deserialization. Patched versions add
+  `Dalli::JSONSerializer`, which reads with `JSON.parse`.
+
+  The first fix (5.2.1, 5.1.3, 5.0.9, 4.3.6 and 3.2.12) was incomplete:
+  on 5.0, 4.3 and 3.2, `cas` and `cas!` (and `fetch_with_lock` on 5.0,
+  and on 4.3 with the meta protocol) still deserialized values read with
+  `raw: true`, and on every line but 3.2 a raw read still honored flags a
+  reply carried unasked. Both are fixed in 5.2.2, 5.1.4, 5.0.10, 4.3.7
+  and 3.2.13.
+
+  ### Workarounds
+
+  Use a serializer that only parses data, such as one wrapping
+  `JSON.parse`, instead of `serializer: JSON`.
+patched_versions:
+  - "~> 3.2.13"
+  - "~> 4.3.7"
+  - "~> 5.0.10"
+  - "~> 5.1.4"
+  - ">= 5.2.2"
+related:
+  url:
+    - https://github.com/petergoldstein/dalli/security/advisories/GHSA-wr87-m4jw-29x5
+    - https://github.com/petergoldstein/dalli/commit/8529428
+    - https://rubygems.org/gems/dalli/versions/5.2.2
+    - https://github.com/petergoldstein/dalli/releases/tag/v5.2.2
+    - https://rubygems.org/gems/dalli/versions/5.1.4
+    - https://github.com/petergoldstein/dalli/releases/tag/v5.1.4
+    - https://rubygems.org/gems/dalli/versions/5.0.10
+    - https://github.com/petergoldstein/dalli/releases/tag/v5.0.10
+    - https://rubygems.org/gems/dalli/versions/4.3.7
+    - https://github.com/petergoldstein/dalli/releases/tag/v4.3.7
+    - https://rubygems.org/gems/dalli/versions/3.2.13
+    - https://github.com/petergoldstein/dalli/releases/tag/v3.2.13
+    - https://rubygems.org/gems/dalli/versions/5.2.1
+    - https://github.com/petergoldstein/dalli/releases/tag/v5.2.1
+    - https://rubygems.org/gems/dalli/versions/5.1.3
+    - https://github.com/petergoldstein/dalli/releases/tag/v5.1.3
+    - https://rubygems.org/gems/dalli/versions/5.0.9
+    - https://github.com/petergoldstein/dalli/releases/tag/v5.0.9
+    - https://rubygems.org/gems/dalli/versions/4.3.6
+    - https://github.com/petergoldstein/dalli/releases/tag/v4.3.6
+    - https://rubygems.org/gems/dalli/versions/3.2.12
+    - https://github.com/petergoldstein/dalli/releases/tag/v3.2.12
+notes: |
+  - No CVE in GHSA.
+     - "A CVE has been requested through GitHub but not yet
+        assigned, so the entry has no cve: field."
+  - No CVSS score in GHSA; GitHub severity is low.