CVE-2025-14802

Executive Summary

CVE-2025-14802 is an authorization bypass vulnerability in the LearnPress – WordPress LMS Plugin for WordPress, affecting versions up to and including 4.3.2.2. The flaw resides in the /wp-json/lp/v1/material/{file_id} REST API endpoint, where a parameter mismatch between the DELETE operation and its permission callback allows authenticated attackers with teacher-level access to delete arbitrary lesson material files uploaded by other teachers. This is a classic Insecure Direct Object Reference (IDOR) vulnerability (CWE-639) within the WordPress ecosystem, specifically targeting the LearnPress plugin's REST API.

The vulnerability is exploitable by sending a DELETE request with the attacker's own item_id in the request body (to pass authorization) while targeting another teacher's file_id in the URL path. The CVSS score is 5.4 (Medium), with low attack complexity and no user interaction required. No public exploit code or proof-of-concept is currently available, and the patch status remains unknown.

Supply Chain & Package Security

This vulnerability affects the LearnPress WordPress plugin, which is distributed via the official WordPress plugin repository and can be installed directly from the WordPress admin dashboard or via Composer. As a WordPress plugin, it is part of the broader WordPress ecosystem and is not a standalone package manager (NPM, PyPI, Go, Ruby) component. However, administrators should verify the integrity of the plugin files and ensure they are obtained from trusted sources. The lack of a patch increases supply chain risk, as unpatched installations remain vulnerable.

CVSS Breakdown & Threat Level

• CVSS Score: 5.4 (Medium)
• Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L
• Attack Vector (AV): Network – The vulnerability is exploitable remotely via HTTP requests.
• Attack Complexity (AC): Low – No special conditions or race conditions are required.
• Privileges Required (PR): Low – The attacker must have authenticated teacher-level access.
• User Interaction (UI): None – No user action is required for exploitation.
• Scope (S): Unchanged – The vulnerable component and the impacted component are the same.
• Confidentiality Impact (C): None – No data is exposed.
• Integrity Impact (I): Low – Unauthorized deletion of lesson material files.
• Availability Impact (A): Low – Deletion of files can disrupt course content availability.

Threat Level: Medium. While the impact is limited to file deletion (not data exfiltration or remote code execution), the ability to delete arbitrary files uploaded by other teachers can disrupt course operations and cause data loss. The low privileges required (teacher-level) and network-based attack vector make it a realistic threat in multi-tenant WordPress LMS environments.

Deep Dive & Mechanics

The vulnerability stems from a parameter mismatch in the REST API endpoint /wp-json/lp/v1/material/{file_id}. When a DELETE request is processed, the endpoint uses the file_id from the URL path to identify which file to delete. However, the permission callback (authorization check) validates the item_id from the request body, not the file_id from the URL. This allows an attacker to:

1. Obtain a legitimate item_id (e.g., from their own lesson material).
2. Craft a DELETE request with their own item_id in the request body (to pass authorization).
3. Specify a different teacher's file_id in the URL path.
4. The server deletes the file associated with the file_id in the URL, bypassing the intended authorization check.

The core issue is a missing or incorrect authorization check on the file_id parameter. The permission callback should verify that the authenticated user owns the file identified by file_id, but instead it checks the item_id from the body, which is unrelated to the file being deleted.

Affected Component: LearnPress REST API endpoint /wp-json/lp/v1/material/{file_id} (DELETE method).

Root Cause: Insecure Direct Object Reference (CWE-639) due to improper validation of the file_id parameter against the authenticated user's permissions.

Vulnerable vs. Patched Code

Since no patch is available, the following is a hypothetical analysis based on the vulnerability description.

Vulnerable Code (Conceptual):

// In the REST API controller
public function delete_material( $request ) {
    $file_id = $request->get_param( 'file_id' ); // From URL path
    $item_id = $request->get_param( 'item_id' ); // From request body

    // Permission callback checks item_id, not file_id
    if ( ! current_user_can( 'edit_lp_lesson', $item_id ) ) {
        return new WP_Error( 'forbidden', 'You do not have permission.', array( 'status' => 403 ) );
    }

    // Delete the file using file_id without verifying ownership
    $deleted = $this->delete_file_by_id( $file_id );
    // ...
}

Patched Code (Hypothetical):

public function delete_material( $request ) {
    $file_id = $request->get_param( 'file_id' );
    $item_id = $request->get_param( 'item_id' );

    // Retrieve the file record to check ownership
    $file = $this->get_file_by_id( $file_id );
    if ( ! $file ) {
        return new WP_Error( 'not_found', 'File not found.', array( 'status' => 404 ) );
    }

    // Verify that the authenticated user owns the file or has appropriate permissions
    if ( ! current_user_can( 'edit_lp_lesson', $file->item_id ) ) {
        return new WP_Error( 'forbidden', 'You do not have permission.', array( 'status' => 403 ) );
    }

    // Also verify the item_id from the body matches the file's item_id (optional defense)
    if ( $item_id !== $file->item_id ) {
        return new WP_Error( 'mismatch', 'Item ID mismatch.', array( 'status' => 400 ) );
    }

    $deleted = $this->delete_file_by_id( $file_id );
    // ...
}

The patch ensures that the permission check is performed against the file_id's associated item_id, not the attacker-supplied item_id from the request body.

Exploitation & Lab Setup

Red Team

Prerequisites:

• Authenticated teacher-level account on a WordPress site with LearnPress plugin version <= 4.3.2.2.
• Knowledge of another teacher's file_id (can be obtained via enumeration or other means).

Exploitation Steps:

1. Obtain a valid item_id: As an authenticated teacher, create a lesson material and note the item_id returned in the response (e.g., from the REST API response or database).

2. Identify target file_id: Enumerate or guess another teacher's file_id. This could be done by observing file IDs in the REST API responses or by brute-forcing (if IDs are sequential).

3. Craft the DELETE request:

   DELETE /wp-json/lp/v1/material/123 HTTP/1.1
   Host: target-wordpress-site.com
   Content-Type: application/json
   Authorization: Bearer <attacker_token>
   
   {
     "item_id": 456
   }
   

   Where 123 is the target teacher's file_id and 456 is the attacker's own item_id.

4. Send the request: The server will authorize based on item_id (456, which the attacker owns) and delete the file associated with file_id (123, which belongs to another teacher).

Expected Outcome: The target teacher's lesson material file is deleted without authorization.

Blue Team

Detection & Prevention:

• Monitor REST API logs: Look for DELETE requests to /wp-json/lp/v1/material/{file_id} where the item_id in the request body does not match the file_id's associated item_id.
• Audit user permissions: Ensure that teacher-level accounts have the minimum necessary permissions. Consider restricting the ability to delete materials to administrators only.
• Implement additional validation: If possible, apply a temporary workaround by adding a custom filter or hook to validate the file_id against the authenticated user's ownership before deletion.
• Web Application Firewall (WAF): Create rules to block DELETE requests to this endpoint where the item_id in the body differs from the expected item_id for the given file_id.

Indicators of Compromise (IOCs)

• Network IOCs:
  • HTTP DELETE requests to /wp-json/lp/v1/material/{file_id} with a JSON body containing an item_id that does not correspond to the file_id.
  • Repeated 403 Forbidden responses followed by successful 200 OK responses for DELETE requests to the same endpoint (indicating authorization bypass attempts).
• File System IOCs:
  • Unexpected deletion of lesson material files (e.g., PDFs, videos) from the WordPress uploads directory.
  • Missing files in the /wp-content/uploads/learnpress/ directory (or similar).
• Log IOCs:
  • WordPress debug log entries showing WP_Error with message "forbidden" or "You do not have permission" for DELETE requests.
  • REST API logs showing DELETE requests with mismatched file_id and item_id.

Detection Engineering

YARA Rule

rule CVE_2025_14802_LearnPress_File_Deletion {
    meta:
        description = "Detects exploitation attempts of CVE-2025-14802 in LearnPress plugin"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2025-14802"
        severity = "medium"
    strings:
        $rest_endpoint = "/wp-json/lp/v1/material/"
        $delete_method = "DELETE"
        $item_id_param = "\"item_id\""
    condition:
        $rest_endpoint and $delete_method and $item_id_param
}

Sigma Rule

title: CVE-2025-14802 LearnPress Unauthorized File Deletion
id: 8a4b3c2d-1e5f-6a7b-8c9d-0e1f2a3b4c5d
status: experimental
description: Detects exploitation attempts of CVE-2025-14802 in LearnPress WordPress plugin
author: Valters IT
date: 2025-04-10
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2025-14802
logsource:
    category: webserver
    product: apache
    service: access_log
detection:
    selection:
        cs-method: 'DELETE'
        cs-uri-stem|startswith: '/wp-json/lp/v1/material/'
    condition: selection
falsepositives:
    - Legitimate teacher deleting their own materials
level: medium

Suricata Rule

alert http any any -> any any (msg:"CVE-2025-14802 LearnPress Unauthorized File Deletion Attempt"; flow:to_server; http.method; content:"DELETE"; http.uri; content:"/wp-json/lp/v1/material/"; http.request_body; content:"\"item_id\""; classtype:attempted-user; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Disable the REST API endpoint if not required: Add a filter to block DELETE requests to /wp-json/lp/v1/material/ for non-admin users.
2. Restrict teacher permissions: Remove the ability for teachers to delete materials via the REST API. Only allow administrators to perform deletions.
3. Apply a temporary workaround: Use a custom plugin or theme functions.php to add a permission check that validates the file_id against the authenticated user's ownership before deletion.

Long-term Fix:

• Update the plugin: Once a patch is released by the vendor (LearnPress), update to the latest version immediately.
• Implement proper authorization: Ensure that all REST API endpoints validate the resource owner against the authenticated user, not just a user-supplied parameter.
• Conduct security audit: Review all REST API endpoints in the LearnPress plugin for similar parameter mismatch vulnerabilities.

Valters IT Signature: This report was generated by Valters IT – DevSecOps & Cyber Threat Intelligence Division. For further inquiries, contact threatintel@valtersit.com.