🔒 Aisle Security Analysis

We found 1 potential security issue(s) in this PR:

1. 🟡 Potential CPU/IO DoS from per-event O(n) pruning and full-state JSON persistence in Matrix inbound dedupe cache

Description

The Matrix inbound dedupe implementation performs linear-time pruning on the hot path and periodically persists the entire cache to disk as formatted JSON.

• claimEvent() and commitEvent() both call pruneSeenEvents(), which iterates over all entries in the seen Map to remove TTL-expired entries.
• With the default maxEntries = 20_000, an attacker (or any high-volume room) can keep seen near the cap by sending many unique events, making each inbound message pay an O(maxEntries) cost.
• commitEvent() schedules persistence; persistence serializes the full state (Array.from(seen.entries())) and writes it atomically. Under sustained traffic this can become significant CPU (JSON stringify) and disk IO amplification.
• Keys are built from roomId|eventId with only .trim() normalization, so if upstream IDs are unexpectedly large, both in-memory and on-disk costs increase further.

Vulnerable code (hot-path prune + full-state persistence):

pruneSeenEvents({ seen, ttlMs, maxEntries, nowMs: nowMs() });
...
entries: Array.from(params.seen.entries()).map(([key, ts]) => ({ key, ts })),

Recommendation

Reduce worst-case per-event work and persistence amplification:

1. Amortize pruning instead of scanning the entire map on every event.

   • Prune on a timer (e.g., once every N seconds), or
   • Prune only a bounded number of entries per call, or
   • Maintain an auxiliary queue/min-heap for expirations.

2. Avoid rewriting the entire state too frequently:

   • Persist less often under load (adaptive backoff), or
   • Persist incremental updates (append-only log) and compact occasionally.

3. Bound key size defensively (even if upstream typically limits IDs):

   • Reject or hash overly long roomId/eventId when building the key.

Example (amortized prune + key length cap):

const MAX_KEY_PART = 512;
let lastPruneMs = 0;
const PRUNE_INTERVAL_MS = 5_000;

function buildEventKey({ roomId, eventId }: { roomId: string; eventId: string }): string {
  const r = roomId.trim().slice(0, MAX_KEY_PART);
  const e = eventId.trim().slice(0, MAX_KEY_PART);
  return r && e ? `${r}|${e}` : "";
}

function maybePrune(nowMs: number) {
  if (nowMs - lastPruneMs < PRUNE_INTERVAL_MS) return;
  lastPruneMs = nowMs;
  pruneSeenEvents({ seen, ttlMs, maxEntries, nowMs });
}

​// in claimEvent/commitEvent: call maybePrune(nowMs()) instead of pruneSeenEvents(...)

Analyzed PR: #50922 at commit 10d9770

_{Last updated on: 2026-03-20T19:46:59Z}

Greptile Summary

This PR introduces durable deduplication for inbound Matrix room events, keyed by roomId + eventId, so that previously handled messages are not replayed as new events after a gateway restart. The implementation adds inbound-dedupe.ts, a file-backed dedupe store with a claim/commit/release lifecycle, and integrates it into the existing monitor handler and startup flow.

Key changes:

• New createMatrixInboundEventDeduper factory: maintains an in-memory seen Map and an in-flight pending Set, backed by a debounced atomic JSON write, with configurable TTL (default 30 days) and max-entries (default 20,000) pruning.
• claimEvent is called synchronously after fast-path early filters (pre-startup age, self-events, redacted events, etc.) but before any expensive async work that could produce side effects.
• commitEvent is called on all deliberate-ignore paths (policy-blocked, no-mention, no body, etc.) and after successful reply dispatch, ensuring idempotent events are durably marked.
• releaseEvent is called in a finally block so that transient failures (disk errors, upstream failures) release the claim and allow retry on the next restart.
• stop() flushes any pending debounced write before the client is torn down.

The claim/commit/release lifecycle is consistently applied across all ~15 return paths in the handler. Test coverage directly exercises ordering guarantees, failure-release paths, and persistence across restarts.

Confidence Score: 4/5

• This PR is safe to merge — the dedupe logic is well-structured and extensively tested, with no identified correctness issues.
• The claim/commit/release lifecycle is correctly applied across all ~15 return paths in the handler. The finally block provides a reliable safety net for transient failures. Test coverage is thorough for ordering guarantees, failure-release paths, and persistence across restarts. A score of 4 (rather than 5) reflects the inherent complexity of a multi-path lifecycle integration that is hard to exhaustively verify by reading alone, and the fact that persist-failure recovery relies on the next commitEvent call to reschedule rather than an explicit retry.
• No files require special attention; handler.ts is the most complex integration point but has been carefully audited.

_{Last reviewed commit: "Matrix: dedupe repla..."}

Merged via squash.

• Prepared head SHA: 10d9770aa61d864686e4ba20fbcffb8a8dd68903
• Merge commit: a05da767180f82b90389bd7cfa7087131e4ecc00

Thanks @gumadeiras!