⚠️ErisPulse Security Advisory EPSA-2026-001

ErisPulse Security Advisory EPSA-2026-001

Severity: HIGH | Affected Versions: < 2.5.5 | Fixed Version: 2.5.5 | Date: 2026-07-10

严重程度: 高危 | 受影响版本: < 2.5.5 | 修复版本: 2.5.5 | 发布日期: 2026-07-10

---

storage.set() Triggers OOM Kill When Nested Key Contains Large Numeric Field

storage.set() 嵌套键包含大数字段时触发 OOM Kill

The ErisPulse storage module Core.storage's _set_nested_value() function misinterprets numeric segments in nested key paths (e.g., mymodule.groups.871684833) as list indices when processing dot-separated keys. When the numeric value is large, a single call can allocate several gigabytes of memory, causing the process to be terminated by the OOM Killer (exit code -9).

ErisPulse 存储模块 Core.storage 的 _set_nested_value() 在处理点分隔的嵌套键路径（如 mymodule.groups.871684833）时，会将纯数字段误判为 list index 并执行 list.extend([None] * N)。当数字较大时，单次调用即可分配数 GB 内存，导致进程被 OOM Killer 终止（exit code -9）。

This issue can be triggered by a single storage.set() call — no loop, no recursion, no special privileges required.

此问题可由单次 storage.set() 调用触发——无需循环、无需递归、无需特殊权限。

---

Affected Versions / 受影响版本

Version / 版本	Status / 状态
< 2.5.5	❌ Vulnerable / 存在漏洞
>= 2.5.5	✅ Fixed / 已修复

---

Trigger Condition / 触发条件

Any sdk.storage.set() call where the dot-separated key path contains a numeric segment ≥ 10,000:

任何 sdk.storage.set() 调用，当点分隔的键路径中包含 ≥ 10000 的纯数字段时：

# 💥 Single call allocates ~7GB, triggers OOM
# 💥 单次调用即分配 ~7GB，触发 OOM
sdk.storage.set("mymodule.groups.871684833", {"enable_ai": True})

Internal call chain / 内部调用链：

storage.set("mymodule.groups.871684833", value)
  → _parse_nested_key() → root="mymodule", path=["groups", "871684833"]
  → _set_nested_value()
    → "871684833".isdigit() == True → creates list[] instead of dict{}
    → 创建 list[] 而非 dict{}
    → list.extend([None] * 871684834)   ← 💥 6.97 GB allocated / 分配 6.97 GB

---

Mitigation / Temporary Workarounds / 临时缓解方案

Before upgrading to 2.5.5, module developers are advised to use one of the following alternative approaches:

在升级到 2.5.5 之前，建议所有模块开发者采用以下替代方案：

✅ Option A — Use colon as separator (recommended)
✅ 方案 A — 使用冒号作为分隔符（推荐）

sdk.storage.set(f"mymodule:group:{group_id}", config)
# Colon is NOT parsed as nested path separator by _parse_nested_key()
# 冒号不会被 _parse_nested_key 解析为嵌套路径分隔符

✅ Option B — Store ID inside the value
✅ 方案 B — 将 ID 存入 value 中

sdk.storage.set("mymodule.groups", {group_id: config})

❌ Avoid the following pattern
❌ 避免以下写法

sdk.storage.set(f"mymodule.groups.{group_id}", config)

Note / 注意：

storage.get() is NOT affected by this issue — reading paths does not create large lists.

storage.get() 不受此问题影响 — 读取路径不会创建大列表。

Paths with non-numeric segments are also safe: storage.set("app.config.theme", "dark") ✅

包含非数字段的路径同样安全：storage.set("app.config.theme", "dark") ✅

---

Root Cause Analysis / 根因分析

StorageManager._set_nested_value() contains two defects:

StorageManager._set_nested_value() 中存在两处缺陷：

Defect 1 / 缺陷 1 — Line 787 creates intermediate containers based on whether next_key.isdigit() is true:

第 787 行，创建中间层时根据下一段是否 isdigit() 决定容器类型：

# BUG: next_key "871684833" isdigit() → creates list, should be dict
# BUG: next_key "871684833" isdigit() → 创建 list，实际应为 dict
current[key] = {} if not next_key.isdigit() else []

Nested key paths come from dot-separated strings (e.g., "mymodule.groups.871684833"). Each segment is fundamentally a dict key — the implementation should not guess the container type based on whether it looks like a number. This heuristic is fundamentally flawed — a numeric string in a dotted path is still a dictionary key, not an array index.

嵌套键路径来自点分隔字符串（如 "mymodule.groups.871684833"），每一段本质上都是 dict key，不应根据是否为数字来猜测容器类型。这种启发式判断存在根本性缺陷——点分隔路径中的数字字符串仍然是字典键，而非数组索引。

Defect 2 / 缺陷 2 — Lines 809-813 extend lists without any upper-bound protection:

第 809-813 行，对 list 扩展没有上限保护：

# BUG: index can reach hundreds of millions, no safety boundary
# BUG: index 可达数亿，无安全边界
current.extend([None] * (index - len(current) + 1))

Additional risk / 附加风险 — Recursive calls at lines 801-803 and 817-818 may trigger infinite recursion when current is an immutable scalar type.

第 801-803 行和 817-818 行的递归调用存在潜在无限递归风险，当 current 为不可变标量类型时可能触发。

---

Fix in 2.5.5 / 2.5.5 修复方案

Version 2.5.5 applies the following fixes to _set_nested_value():

2.5.5 版本将对 _set_nested_value() 做以下修复：

1. Intermediate containers always use dict — no longer guess type based on isdigit()
   新建中间层始终使用 dict — 不再根据 isdigit() 猜测类型

2. Add _MAX_LIST_INDEX = 10000 safety upper bound — automatically convert list to dict when exceeded
   添加 _MAX_LIST_INDEX = 10000 安全上限 — 超出时自动将 list 转换为 dict

3. Replace recursion with iterative implementation — eliminate infinite recursion risk
   递归调用改为迭代实现 — 消除无限递归风险

---

Credit / 致谢

Reported by a third-party module development team during production deployment (Docker, 8GB memory limit) via TRACE-level diagnostic logs. Reported with full root-cause analysis and reproduction steps.

由第三方模块开发团队在生产环境部署（Docker，8GB 内存限制）期间通过 TRACE 级别诊断日志发现并报告。提供了完整的根因分析和复现步骤。

---

ErisPulse Core Team — 2026-07-10

[wsu2059q]

修复后，数字字段的行为说明 / Behavior of Numeric Fields After Fix

以下分三种情况说明修复后的实际行为：

---

① 已存在的 list → 数字仍作为索引（行为不变）

① Existing list → Numeric still treated as index (unchanged)

storage.set("data", {"items": ["a", "b", "c"]})
storage.set("data.items.1", "UP")
# Result / 结果: {"items": ["a", "UP", "c"]}  ← Still list index / 仍然是 list 索引

只要容器本身已经是 list（由用户显式创建），数字段照样作为索引使用。唯一新增的是 10000 的安全上限（_MAX_LIST_INDEX）——索引超过上限时，操作会被安全拦截，不会分配大内存。

As long as the container is already a list (explicitly created by the user), numeric segments continue to be treated as indices. The only new addition is the 10000 safety upper bound (_MAX_LIST_INDEX) — indices exceeding this limit will be safely rejected without allocating large memory.

---

② 首次创建的中间层 → 数字变为字典的字符串键（唯一的行为变化）

② Newly created intermediate layers → Numeric becomes string key in dict (the only behavior change)

storage.set("QvQChat.groups.871684833", {"ai": True})
# Before / 修复前: groups = [] → treats 871684833 as index → 💥 OOM
# After / 修复后: groups = {"871684833": {"ai": True}}  ← String key / 字符串键

storage.set("a.b.123.c", "val")
# After / 修复后: {"b": {"123": {"c": "val"}}}  ← "123" is dict key, not index
# "123" 是字典键，不是索引

---

③ 隐式自动创建 list 的场景（不再支持）

③ Implicit auto-creation of lists (no longer supported)

storage.set("mylist.0", "first")
# Before / 修复前: {"mylist": [None, ..., "first"]}  ← Auto-creates list (dangerous & ambiguous)
# 自动建 list（危险且有歧义）
# After / 修复后: {"mylist": {"0": "first"}}          ← Creates dict, "0" is string key
# 建成 dict，"0" 是字符串键

这是本次修复中唯一的语义变化：修复前，系统会根据下一段是否全是数字来「猜测」容器类型；修复后，所有新创建的中间层统一使用 dict。

This is the only semantic change in this fix: Previously, the system would "guess" the container type based on whether the next segment was all digits; after the fix, all newly created intermediate layers uniformly use dict.

---

为什么这个变化是合理的？ / Why This Change Is Justified

1. 原逻辑本身就是 Bug 的根源

1. The original logic is the root cause of the bug

那个「自动猜成 list」的判断根本没有可靠的语义依据：

The "auto-guess as list" logic has no reliable semantic basis:

• "mylist.0" 到底是指 mylist[0]（列表索引）还是 mylist["0"]（字典键）？无从得知。
• Does "mylist.0" mean mylist[0] (list index) or mylist["0"] (dict key)? Impossible to know.

2. 真正需要 list 的用户应该显式创建

2. Users who truly need a list should create it explicitly

# ✅ Correct / 正确做法
storage.set("mylist", ["first"])
storage.set("mylist.0", "updated")  # Now works as index / 此时按索引工作

而不是依赖点路径隐式创建，这种隐式行为既不直观也不安全。

Rather than relying on implicit creation via dotted paths, which is neither intuitive nor safe.

3. get/set 行为在修复后更为一致

3. get/set behavior is now more consistent

关键事实——storage.get() 从来就不会自动创建 list：

Key fact — storage.get() never auto-creates lists:

# 假设 "mylist" 不存在 / Assume "mylist" does not exist
storage.get("mylist.0")  # 返回 None，不会创建任何东西 / Returns None, creates nothing

修复前，set 会自动建 list 而 get 不建，两者本身就是不对称的。修复后，set 不再「猜」类型，统一使用 dict，与 get 的行为哲学保持一致。

Before the fix, set would auto-create lists while get would not — the two were inherently asymmetric. After the fix, set no longer "guesses" types and uniformly uses dict, aligning with get's behavioral philosophy.

---

总结 / Summary

场景 / Scenario	修复前 / Before	修复后 / After
容器已是 list，数字索引 < 10000	✅ 按索引操作	✅ 按索引操作（不变）
容器已是 list，数字索引 ≥ 10000	💥 OOM	✅ 安全拦截，不分配内存
中间层不存在，首次创建	🔮 猜（isdigit → list / 否则 dict）	✅ 统一 dict
显式创建 list 后操作	✅ 正常工作	✅ 正常工作（不变）

唯一需要注意的迁移场景：如果你的代码依赖「通过点路径首次创建时自动生成 list」的隐式行为，请改为显式 storage.set("key", []) 初始化。

The only migration concern: If your code relies on the implicit behavior of "auto-creating a list via dotted path on first write", please change to explicit storage.set("key", []) initialization.