T09 · Insecure Skill Coding Practices
Warning
- Location
- index.ts:30
- Finding
- Unbounded Review Storage and Batch Processing Can Exhaust Process Resources## Vulnerability Details **File Location**: `index.ts`, lines 30 and 79–119 **Vulnerability Type**: Unbounded memory consumption and unrestricted batch processing **Risk Level**: Medium ### Vulnerable Code ```typescript private reviews: Map<string, Review> = new Map(); ``` ```typescript this.reviews.set(id, newReview); ``` ```typescript async batchReview(reviews: Array<{ taskId: string; materialId: string; score: number; passed: boolean; comments?: string; issues?: string[]; }>): Promise<{submitted: number; ids: string[]}> { const ids: string[] = []; for (const review of reviews) { const id = await this.submitReview(review); ids.push(id); } this.api.log(`info`, `Batch review completed: ${ids.length} reviews submitted`); return { submitted: ids.length, ids }; } ``` ### Technical Analysis Every submitted review is retained indefinitely in an in-memory `Map`. There is no maximum record count, expiration policy, eviction mechanism, or persistence strategy that would bound process memory usage. The batch review method also processes the entire caller-controlled array without enforcing a maximum batch size. Each item creates a review, adds it to the map, writes a log entry, and emits at least one event. Rejected reviews emit an additional event. Consequently, a large batch has both immediate CPU and event-processing costs and a permanent memory cost for the lifetime of the skill process. Repeated requests compound the issue because records are never removed. Even if an individual request is constrained by an upstream transport, repeated submissions can still grow the map until the process experiences excessive garbage collection, degraded responsiveness, or heap exhaustion. ### Attack Path 1. An attacker or untrusted caller invokes the `review batch` command with a very large `materialIds` array. 2. The command converts every material ident ...[truncated 892 chars]
- Remediation
- ## Remediation Suggestions - Enforce a strict maximum batch size at the command boundary and again inside `batchReview`. - Apply per-user and global rate limits to submission and batch commands. - Limit the total number of records retained in memory. - Add time-based expiration or least-recently-used eviction if in-memory storage is intentional. - Prefer durable storage with quotas, pagination, retention policies, and indexed queries. - Reject requests before processing if their serialized size exceeds an established limit. - Limit event and log volume, especially for batch operations. - Process approved batches in bounded chunks and apply backpressure to downstream event consumers. - Add monitoring for record count, heap usage, batch size, and event queue depth.