diff --git a/advisories/github-reviewed/2026/07/GHSA-xvcm-6775-5m9r/GHSA-xvcm-6775-5m9r.json b/advisories/github-reviewed/2026/07/GHSA-xvcm-6775-5m9r/GHSA-xvcm-6775-5m9r.json
index 2fc493972399..106209d114be 100644
--- a/advisories/github-reviewed/2026/07/GHSA-xvcm-6775-5m9r/GHSA-xvcm-6775-5m9r.json
+++ b/advisories/github-reviewed/2026/07/GHSA-xvcm-6775-5m9r/GHSA-xvcm-6775-5m9r.json
@@ -1,12 +1,12 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-xvcm-6775-5m9r",
-  "modified": "2026-07-21T19:02:33Z",
+  "modified": "2026-07-21T19:02:34Z",
   "published": "2026-07-21T19:02:33Z",
   "aliases": [
     "CVE-2026-59880"
   ],
-  "summary": "Immutabl: Hash-collision algorithmic complexity denial of service in Immutable.Map/Set",
+  "summary": "Immutable: Hash-collision algorithmic complexity denial of service in Immutable.Map/Set",
   "details": "## Summary\n\n`Immutable.Map` and `Immutable.Set` keep keys that share the same 32-bit hash in a collision bucket that is scanned linearly. The string hash is public and deterministic, so an attacker who controls the **keys** inserted into a Map can craft many keys that all collide, degrading insertion and lookup from amortized O(1) to O(n) per operation — and O(n²) to build or read the whole set. A small, attacker-shaped payload can therefore consume disproportionate CPU and, on a single-threaded runtime such as Node.js, stall the event loop and deny service.\n\n## Details\n\nThe string hash uses the JVM-style polynomial `hashed = (31 * hashed + charCode) | 0`. Strings such as `\"Aa\"` and `\"BB\"` hash to the same value (`65*31+97 == 66*31+66 == 2112`), and concatenating such blocks yields `2^n` distinct strings sharing one hash (40 characters ⇒ >1,000,000 colliding keys). \nAll such keys route to a single `HashCollisionNode`, whose `get`/`update` walk the entire bucket testing `is()`. There is no per-process salt, so the colliding set is fully precomputable from the open-source algorithm.\n\n## Proof of concept\n\nInserting N colliding keys (e.g. via `Immutable.Map(obj)` / `Immutable.fromJS(obj)`) is O(N²). Measured on one machine, ~8,000 colliding\nkeys take ~0.7 s to build and ~0.6 s to read, scaling ×4 per doubling; ~16,000 keys exceed several seconds.\n\n## Impact\n\nCPU-bound denial of service in applications that ingest attacker-controlled object **keys** into Immutable structures, e.g. `Immutable.Map(req.body)`, `Immutable.fromJS(req.body)`, `state.merge(userObject)` / `mergeDeep(...)`. Applications that only store attacker input as **values** under fixed keys are not affected.\n\n## Affected versions\n\nAll versions through `5.1.7` (the deterministic string hash and linear collision bucket have existed since the 4.x line).\n\n## Patches\n\nFixed in `5.1.8` _(adjust to the actual release)_: large collision buckets are indexed by a per-process **seeded** secondary hash, restoring near-linear behavior for the affected paths. The public `hash()` is unchanged (no breaking change), and `is()` remains the sole authority on key equality.\n\n## Workarounds\n\nBefore passing untrusted data to Immutable.js: cap request body size, limit object key count/length, and reject high-cardinality payloads; avoid building Maps directly from untrusted object keys.\n\n## References\n\n- CWE-407 (Inefficient Algorithmic Complexity), CWE-400 (Uncontrolled Resource Consumption)\n- OWASP API4:2023 (Unrestricted Resource Consumption)",
   "severity": [
     {