CVE-2025-32795

Executive Summary

CVE-2025-32795 is an access control vulnerability in Dify, an open-source LLM app development platform. The flaw allows authenticated non-admin users to modify application names, descriptions, and icons, despite being restricted from viewing the apps. This violates the principle of least privilege and can lead to unauthorized changes to application metadata, potentially confusing users or masking malicious activity. The vulnerability is present in versions prior to 0.6.12 and has been patched in that release. The CVSS score is 6.5 (Medium), and no public exploit code is available.

Supply Chain & Package Security

Dify is a Python-based platform. The vulnerability is in the application logic, not in a dependency. However, organizations using Dify should verify they are running version 0.6.12 or later to mitigate this risk.

CVSS Breakdown & Threat Level

• CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L
• Base Score: 6.5 (Medium)
• Attack Vector: Network (AV:N)
• Attack Complexity: Low (AC:L)
• Privileges Required: Low (PR:L) – attacker must be an authenticated user
• User Interaction: None (UI:N)
• Scope: Unchanged (S:U)
• Confidentiality Impact: None (C:N)
• Integrity Impact: Low (I:L) – app name, description, icon can be altered
• Availability Impact: Low (A:L) – potential for service disruption if app metadata is corrupted

Deep Dive & Mechanics

The vulnerability stems from improper permission checks in the API endpoints responsible for updating app metadata. In Dify, normal users are assigned roles that should restrict them from modifying app details. However, the access control logic fails to enforce these restrictions, allowing any authenticated user to send a PUT/PATCH request to the app update endpoint and change the name, description, or icon of any app.

The root cause is a missing or insufficient role-based access control (RBAC) check in the backend code. The application likely checks if the user is authenticated but does not verify if the user has the admin or editor role for the specific app. This allows a low-privilege user to modify app metadata even if they cannot view the app's internal data.

Vulnerable vs. Patched Code

Vulnerable Code (pre-0.6.12):

# Example vulnerable endpoint
@app.route('/api/apps/<app_id>', methods=['PATCH'])
@login_required
def update_app(app_id):
    data = request.get_json()
    app = App.query.get(app_id)
    if not app:
        return jsonify({'error': 'App not found'}), 404
    # Missing role check
    app.name = data.get('name', app.name)
    app.description = data.get('description', app.description)
    app.icon = data.get('icon', app.icon)
    db.session.commit()
    return jsonify({'message': 'App updated'})

Patched Code (0.6.12):

# Example patched endpoint
@app.route('/api/apps/<app_id>', methods=['PATCH'])
@login_required
@admin_required  # New decorator
def update_app(app_id):
    data = request.get_json()
    app = App.query.get(app_id)
    if not app:
        return jsonify({'error': 'App not found'}), 404
    # Role check enforced
    if not current_user.is_admin:
        return jsonify({'error': 'Insufficient permissions'}), 403
    app.name = data.get('name', app.name)
    app.description = data.get('description', app.description)
    app.icon = data.get('icon', app.icon)
    db.session.commit()
    return jsonify({'message': 'App updated'})

Exploitation & Lab Setup

Red Team

1. Prerequisites: Authenticated user account on a Dify instance (version < 0.6.12).
2. Steps:
   • Obtain a valid session token or API key.
   • Identify an app ID (e.g., via enumeration or guessing).
   • Send a PATCH request to /api/apps/<app_id> with modified metadata.
   • Example using curl:

     curl -X PATCH https://target-dify.com/api/apps/123 \
       -H "Authorization: Bearer <token>" \
       -H "Content-Type: application/json" \
       -d '{"name": "Malicious App", "description": "This app has been compromised"}'
     

3. Impact: The app's name and description are changed, potentially misleading users or hiding malicious activity.

Blue Team

1. Detection: Monitor API logs for unauthorized PATCH requests to /api/apps/* from non-admin users.
2. Mitigation: Update to Dify 0.6.12 or apply the workaround by enforcing RBAC at the application level.
3. Forensics: Check for unexpected changes to app metadata in the database. Look for audit logs showing modification events without corresponding admin privileges.

Indicators of Compromise (IOCs)

• Network: HTTP PATCH requests to /api/apps/<app_id> with modified JSON payloads.
• Logs: Audit logs showing app metadata changes by non-admin users.
• Database: Unexpected changes to name, description, or icon fields in the apps table.

Detection Engineering

YARA Rule

rule detect_dify_access_control_bypass {
    meta:
        description = "Detects attempts to exploit CVE-2025-32795 by modifying app metadata"
        author = "Valters IT"
        date = "2025-04-01"
        reference = "CVE-2025-32795"
    strings:
        $s1 = "PATCH /api/apps/" ascii wide nocase
        $s2 = "name" ascii wide
        $s3 = "description" ascii wide
        $s4 = "icon" ascii wide
    condition:
        all of ($s*) and #s1 > 0
}

Sigma Rule

title: Dify App Metadata Modification by Non-Admin User
id: 8a9b7c6d-5e4f-3a2b-1c0d-9e8f7a6b5c4d
status: experimental
description: Detects unauthorized modification of app metadata in Dify (CVE-2025-32795)
author: Valters IT
date: 2025-04-01
logsource:
    category: application
    product: dify
detection:
    selection:
        http_method: PATCH
        url_path: /api/apps/*
        user_role: user
    condition: selection
falsepositives:
    - Legitimate admin actions (should be filtered by user_role)
level: high

Suricata Rule

alert http any any -> any any (msg:"CVE-2025-32795 Dify App Metadata Modification Attempt"; flow:to_server; content:"PATCH"; http_method; content:"/api/apps/"; http_uri; pcre:"/\/api\/apps\/\d+/"; classtype:attempted-recon; sid:1000001; rev:1;)

Remediation & Mitigation

1. Immediate: Update Dify to version 0.6.12 or later.
2. Workaround: If immediate update is not possible, enforce RBAC at the application level by modifying the access control logic to restrict app metadata modification to admin users only.
3. Long-term: Implement proper role-based access controls (RBAC) and conduct regular security audits of API endpoints.

Valters IT
Securing Digital Frontiers