#19761: fix(security): OC-69 cap ACP session creation to prevent memory exhaustion DoS — Aether AI Agent

## Attack Vector OC-69: No rate limiting on ACP session creation. **Vector:** A network attacker rapidly creates thousands of ACP sessions via the session creation endpoint. Without any cap on concurrent sessions, the in-memory session Map grows without bound, eventually exhausting available memory and causing the process to crash (Denial of Service). **CWE:** CWE-400 (Uncontrolled Resource Consumption) **Severity:** Medium **GHSA:** GHSA-386r-5vvv-5g44 ## Fix Added a MAX_SESSIONS (1000) hard cap. When the limit is reached, new session creation requests are rejected with an error, preventing memory exhaustion. ## Impact Prevents network-accessible DoS via unbounded session creation. --- *Discovered and remediated by [Aether AI Agent](https://tryaether.ai) — automated security research.* <!-- greptile_comment --> <h3>Greptile Summary</h3> This PR adds a `MAX_SESSIONS = 1000` hard cap to `createInMemorySessionStore()` to prevent unbounded memory growth from ACP session creation (CWE-400 / DoS mitigation). - The cap correctly rejects new session creation with an error when the limit is reached - **Key concern**: The `AcpSessionStore` has no mechanism to delete individual sessions. Sessions are added via `createSession` but never removed (only `clearAllSessionsForTest` clears the entire map). In a long-running ACP server, after 1000 cumulative sessions, the cap becomes permanently reached and all future `newSession`/`loadSession` calls will fail — trading one denial-of-service for another - Consider pairing this cap with a session cleanup or eviction strategy (e.g., LRU eviction, TTL-based expiry, or a `deleteSession` API) so the limit is recoverable without a process restart <h3>Confidence Score: 3/5</h3> - The cap prevents unbounded growth but introduces a permanent session creation ceiling due to missing cleanup, which could cause issues in long-running deployments. - The fix addresses the stated DoS vector (unbounded session map growth) but introduces a new availability risk: without any session deletion or eviction mechanism, the 1000-session cap becomes permanently reached in long-running processes, effectively creating a self-imposed DoS. The change is small and isolated, so merge risk is low in the short term, but the design gap should be addressed. - src/acp/session.ts — needs a session removal or eviction mechanism to complement the cap _{Last reviewed commit: 5c12375} <!-- greptile_other_comments_section --> <!-- /greptile_comment -->