Key Findings

1. Celestia：主网版本同时收紧共识身份、反序列化与缓存三层边界

v9.0.8 明确用于 Mainnet，并将 celestia-core 升至 v0.40.9。共识层不再只按 block hash 识别 valid/locked/committed block，而是绑定完整 BlockID 与 part-set header，避免 stale proposal block 与重置 part set 被错误组合；blocksync 还阻断 maxPeerHeight poisoning，并在 evidence 的 validator/signature 集合进入完整 protobuf unmarshal 前先做边界检查。网络资源层对 abusive mempool Txs 在完整反序列化前拒绝，对重型 HTTP/WebSocket/gRPC RPC 使用进程级并发上限。应用层 PFB cache 此前是无界 map，且在 ante 检查前写入，使从未进入 mempool 的无效交易也能永久驻留；新版本只缓存完整 CheckTx 通过的交易并限制为 10,000 项 LRU。官方没有单项 vulnerability severity，本报告的 High 是主网工程处置优先级。

2. Aptos：validators 被要求安装私有热修，但公开证据不足以独立验证风险

主网 v1.49.1-hotfix 的公开说明只有四个关键事实：这是 private hotfix；source code 不可用；validators 标记为 YES；fullnodes 标记为 Recommended。官方同时给出 hotfix commit b5756b2…，但没有可检查的 diff、root cause、受影响版本、利用条件、回滚策略或正式 severity。前一周 watchlist 中的 v1.48.7 private hotfix 也仍未补充公开披露，因此不能把任意相邻主分支 commit 猜成漏洞原因。节点团队应把这类升级视为高优先级供应链事件：核对镜像 digest、签名/来源、canary 行为和 validator/fullnode 版本兼容性，并保留可回滚 artifact。

3. Teku：recommended release 把 fork-transition 正确性和 gossip validation 一次带入稳定线

26.9.0 修复了多条互相独立但都可能造成客户端分歧或 validator duty 缺失的路径。fork 在 genesis 后激活时，首个 epoch 可能因状态类型判断错误而没有 attestation duties；已排期 Gloas 的网络上，Fulu-era data-column sidecar 曾用最高支持 milestone 的 schema 解码，导致收到的 sidecar 全部反序列化失败；BeaconBlocksByRoot 响应此前也未逐项绑定请求 roots。发布还纳入上期追踪的 Snappy 边界修复：压缩 payload 应与 max_compressed_len(MAX_PAYLOAD_SIZE) 比较，而非直接与未压缩上限比较，否则合法消息会被判 Invalid 并伤害转发 peer。项目称这是 recommended update，但没有给这些 bug 单独评级。

4. Reth：同一稳定版覆盖 peer-triggered task stop、状态读取与跨链签名语义

v2.6.0 的 Security and Networking 修复把 transaction recovery failure 归类为 block validation error，使 malformed peer-served downloaded/buffered block 不再停止 engine tree task；h2 升到 0.4.16 以纳入 RUSTSEC-2026-0258 修复。执行 overlay 现在记录 storage wipe，避免 pre-Dencun SELFDESTRUCT 后缺失 slot 回落到 durable state；RPC 则拒绝 caller-supplied chainId 与节点不匹配的请求，不再静默改写并签往另一个网络。虽然这些边界值得立即回归，官方对 payload builder 与非 builder 都给出 Low update priority，因此本报告保留 Watch，不把“Security”章节自动等同于 High。

5. NEAR：标记为非安全升级，不代表其中没有值得迁移到威胁模型的资源边界

2.14.0-rc.1 面向 testnet，release metadata 明确写明 SECURITY_UPGRADE: FALSE，因此不能宣称存在已披露漏洞或主网已受影响。但 protocol v87 系统性补齐了 witness/receipt 资源边界：resolved promise inputs 总量此前会在 per-receipt storage-proof limit 开始计数前读入 state witness；storage proof limit 过去只由 VM 内的 FunctionCall 观察，其他 action 可在同一 receipt 中继续累积；state-init 只限制单个 key/value 而未限制 entries 总数。版本还拒绝 nested WithdrawFromGasKey，因为 SPICE pending queue 只扫描顶层 action，嵌套提款会减少余额而队列仍认为资金存在。作为 RC，这些变化应先用于跨 action、嵌套 delegation 与 witness-amplification corpus。

6. Prysm：无 column 工作的正常 backfill 状态也必须走 nil-safe 路径

当一个 backfill batch 不需要 column 工作时，例如全部 blocks 都在 Fulu 之前或超出 column retention window，newColumnSync 会返回非 nil 的 wrapper，但其中 embedded *columnBatch 为 nil。旧调用解析到 promoted (*columnBatch).needed()，而不是 wrapper 上带 nil guard 的 columnsNeeded()，因此触发 nil pointer SIGSEGV。修复只需改走正确方法，但暴露的测试盲点很典型：零工作量不是异常输入，而是 fork 和 retention 边界上的正常状态。该改动已合并 develop，未见对应稳定 release 或远程触发条件说明。

7. Cosmos EVM：API 接受的全零 hash 不应变成内部 nil dereference

Geth 的 FilterCriteria JSON 解码器接受全零 blockHash，但 Cosmos EVM 的 Filter.Logs 用零值判断是否进入单块分支；全零 hash 因而落入 range 分支并解引用 block filter 中本来就不存在的 FromBlock。任何 RPC client 都能让 eth_getLogs 或 eth_getFilterLogs 返回 method handler crashed，节点日志出现 nil pointer。修复在 BlockHash 非 nil 的分支内把全零值作为 unknown block 返回且不调用 backend。公开证据只证明单次 handler panic，未证明整节点进程退出或稳定版交付，因此列为 Watch。