[Bug] Critical Session Leak: ThreadLocal CookieStore persists across requests

[QiuYucheng2003]

Description

The CUrl class utilizes a static CookieStore (Line 36) which internally manages cookies using a ThreadLocal field (Line 1113).

The exec() method does not automatically clean up this ThreadLocal storage after a request completes. In a thread-pooled environment (e.g., Servlet containers, ExecutorServices), the thread is reused for subsequent requests.

Impact

If Thread-1 processes a request for User A and receives a Set-Cookie header, that cookie remains bound to Thread-1. When Thread-1 is later reused to process a request for User B, CUrl automatically attaches User A's cookies to User B's outgoing request. This leads to Session Hijacking and data leakage.

Location

File: com.roxstudio.utils.CUrl.java=
Leak Source: Line 1113 (ThreadLocal<Map<String, List>> cookies)
Cause: Missing remove() call in exec() method.

Steps to Reproduce

1. Initialize a FixedThreadPool with 1 thread.

2. Task A: Submit a CUrl request that receives a Set-Cookie (e.g., JSESSIONID=UserA).

3. Task B: Submit a second CUrl request to a dump/echo service using the same pool.

4. Observe: The request in Task B includes Cookie: JSESSIONID=UserA, even though it was a fresh request.

Suggested Fix

Wrap the exec() logic in a try...finally block and ensure cookieStore.removeAll() (or a new method to clear the specific ThreadLocal) is called in the finally block.