CVE-2024-5977

Executive Summary

CVE-2024-5977 is an Insecure Direct Object Reference (IDOR) vulnerability in the GiveWP – Donation Plugin and Fundraising Platform plugin for WordPress. The flaw exists in the handleRequest function, which fails to validate a user-controlled key, allowing authenticated attackers with GiveWP Worker-level access or higher to delete and update arbitrary posts. This vulnerability affects all versions up to and including 3.13.0. The CVSS score is 5.4 (Medium), and the EPSS probability is 0.0%, indicating low exploitation likelihood at this time. No public proof-of-concept or exploit code is available.

Supply Chain & Package Security

This vulnerability is specific to the WordPress ecosystem and the GiveWP plugin. It is not related to NPM, PyPI, Go, or Ruby packages. The risk is limited to WordPress sites running the vulnerable plugin version.

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: 5.4 (Medium)
• Attack Vector: Network (AV:N)
• Attack Complexity: Low (AC:L)
• Privileges Required: Low (PR:L) – authenticated as GiveWP Worker or higher
• User Interaction: None (UI:N)
• Scope: Unchanged (S:U)
• Confidentiality Impact: None (C:N)
• Integrity Impact: Low (I:L) – unauthorized post updates/deletions
• Availability Impact: Low (A:L) – post deletions affect availability

The threat level is Medium due to the requirement for authentication, but the impact is limited to post manipulation.

Deep Dive & Mechanics

The vulnerability resides in the handleRequest function of the GiveWP plugin. This function processes API requests and uses a user-controlled key to identify the target post. Due to missing validation, an attacker can supply arbitrary post IDs, bypassing authorization checks. The function does not verify that the authenticated user has permission to modify or delete the specified post.

The attack flow:

1. An attacker authenticates with GiveWP Worker-level access.
2. The attacker crafts a request to the vulnerable endpoint, manipulating the post_id parameter.
3. The handleRequest function processes the request without verifying ownership or capabilities.
4. The attacker can delete or update any post on the WordPress site, including posts from other users or protected content.

This is a classic IDOR (CWE-639) vulnerability, where the application fails to enforce proper access controls on object references.

Vulnerable vs. Patched Code

Vulnerable Code (simplified):

function handleRequest($request) {
    $post_id = $request->get_param('post_id');
    // Missing capability check
    $post = get_post($post_id);
    if ($request->get_method() === 'DELETE') {
        wp_delete_post($post_id, true);
    } else {
        wp_update_post(array('ID' => $post_id, ...));
    }
}

Patched Code (expected):

function handleRequest($request) {
    $post_id = $request->get_param('post_id');
    $post = get_post($post_id);
    if (!$post || !current_user_can('edit_post', $post_id)) {
        return new WP_Error('forbidden', 'You do not have permission.', array('status' => 403));
    }
    if ($request->get_method() === 'DELETE') {
        if (!current_user_can('delete_post', $post_id)) {
            return new WP_Error('forbidden', 'You do not have permission.', array('status' => 403));
        }
        wp_delete_post($post_id, true);
    } else {
        wp_update_post(array('ID' => $post_id, ...));
    }
}

The patch adds capability checks using current_user_can() before performing any post operations.

Exploitation & Lab Setup

Red Team

Since no public exploit code is available, the following is a conceptual exploitation approach:

1. Prerequisites: Authenticated session with GiveWP Worker-level access.
2. Craft Request: Send a POST or DELETE request to the vulnerable endpoint with a manipulated post_id.
3. Example Request:

   POST /wp-json/givewp/v1/posts HTTP/1.1
   Host: target-site.com
   Cookie: wordpress_logged_in_xxx=...
   Content-Type: application/json
   
   {
     "post_id": 123,
     "action": "delete"
   }
   

4. Verification: Check if the target post (ID 123) is deleted or modified.

Blue Team

1. Detection: Monitor for unusual API requests to GiveWP endpoints with varying post_id values.
2. Logging: Enable WordPress audit logging to track post deletions/updates.
3. Honeypot: Create a dummy post and monitor for unauthorized modifications.
4. WAF Rules: Block requests to /wp-json/givewp/v1/posts with suspicious post_id patterns.

Indicators of Compromise (IOCs)

• Network: HTTP requests to /wp-json/givewp/v1/posts with post_id parameter.
• Logs: WordPress audit logs showing post deletions/updates by unexpected users.
• File: Modified or deleted posts without corresponding author activity.
• Behavior: Multiple rapid post deletions from a single authenticated session.

Detection Engineering

YARA Rule

rule CVE_2024_5977_GiveWP_IDOR {
    meta:
        description = "Detects exploitation attempts of CVE-2024-5977 in GiveWP plugin"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2024-5977"
    strings:
        $s1 = "handleRequest" ascii wide nocase
        $s2 = "givewp" ascii wide nocase
        $s3 = "post_id" ascii wide nocase
    condition:
        all of them
}

Sigma Rule

title: CVE-2024-5977 GiveWP IDOR Exploitation Attempt
id: 8f3a2b1c-4d5e-6f7a-8b9c-0d1e2f3a4b5c
status: experimental
description: Detects attempts to exploit Insecure Direct Object Reference in GiveWP plugin
author: Valters IT
date: 2025-04-10
logsource:
    category: webserver
    product: apache
    service: access_combined
detection:
    selection:
        cs-method: 'POST'
        cs-uri-query|contains: '/wp-json/givewp/v1/posts'
        cs-uri-query|contains: 'post_id='
    condition: selection
falsepositives:
    - Legitimate GiveWP API usage
level: medium

Suricata Rule

alert http any any -> any any (msg:"CVE-2024-5977 GiveWP IDOR Exploitation Attempt"; flow:to_server,established; content:"POST"; http_method; content:"/wp-json/givewp/v1/posts"; http_uri; content:"post_id"; http_client_body; classtype:attempted-user; sid:1000001; rev:1;)

Remediation & Mitigation

1. Immediate: Disable the GiveWP plugin if not essential, or restrict access to the vulnerable endpoint via .htaccess or WAF rules.
2. Short-term: Apply the vendor patch when available. Monitor the GiveWP plugin page for updates.
3. Long-term: Implement capability checks in all API endpoints. Use nonces and permission callbacks in WordPress REST API development.
4. Workaround: If patching is not possible, remove GiveWP Worker-level access from untrusted users.

Valters IT
DevSecOps & Cyber Threat Intelligence