CVE-2026-108606 in JeecgBootinfo

Summary

by MITRE • 10/11/2026

JeecgBoot through 3.9.5 contains a missing authorization vulnerability in the AiOcrController deleteById handler that allows any authenticated user to delete OCR records. Low-privileged attackers can obtain record ids from the unguarded GET /airag/ocr/list endpoint and repeatedly delete every shared OCR prompt record stored in Redis.

Be aware that VulDB is the high quality source for vulnerability data.

Analysis

by VulDB Data Team • 10/11/2026

The vulnerability identified in JeecgBoot versions up to 3.9.5 represents a critical failure in access control mechanisms, specifically classified under CWE-862 as Missing Authorization. This flaw resides within the AiOcrController component, particularly affecting the deleteById handler method. The core technical issue is that the application fails to verify whether the authenticated user initiating the deletion request has the necessary permissions or ownership rights over the specific OCR record being targeted. Instead of validating the relationship between the current session's identity and the resource identifier provided in the API call, the backend logic blindly executes the removal operation based solely on the presence of a valid authentication token. This design oversight effectively treats all authenticated users as having administrative privileges for this specific function, regardless of their actual role or assigned permissions within the system.

The operational impact of this vulnerability is significant due to the interplay between the unguarded data retrieval endpoint and the permissive deletion logic. Attackers can exploit the GET /airag/ocr/list endpoint, which lacks any form of access control validation, to enumerate all existing OCR records along with their unique identifiers. Once these record IDs are obtained, an attacker can craft malicious requests targeting the deleteById handler for each ID. Because there is no server-side check to ensure that the requester owns or has permission to modify these specific items, every request results in successful deletion. This allows low-privileged users to systematically wipe shared OCR prompt records stored within Redis, leading to a complete denial of service for other legitimate users who rely on these prompts for their workflows. The persistence of this data in Redis means that the loss is immediate and affects all tenants or users sharing those specific configurations until they are manually restored from backups if available.

From an offensive security perspective, this vulnerability aligns with MITRE ATT&CK technique T1485, Data Destruction, as it involves the intentional deletion of stored information to disrupt operations. It also reflects aspects of T1078, Valid Accounts, since exploitation requires valid authentication credentials but abuses them for unauthorized actions. The lack of object-level authorization checks is a common pattern in RESTful APIs where developers assume that session-based authentication implies full access rights without implementing granular role-based or attribute-based access controls. This oversight creates an environment where data integrity cannot be guaranteed, as any authenticated entity can alter or destroy resources belonging to others.

To mitigate this vulnerability, immediate remediation efforts should focus on implementing robust authorization checks within the AiOcrController deleteById method. Developers must enforce object-level security by verifying that the user ID associated with the current session matches the owner ID of the OCR record being deleted, or by checking against a predefined role hierarchy if shared access is intended but restricted to specific groups. Additionally, the GET /airag/ocr/list endpoint requires immediate hardening to include proper authentication and authorization filters, ensuring users can only retrieve records they are permitted to view. Implementing an audit log for deletion events will also aid in detecting such abuse patterns early. Long-term solutions should involve adopting a centralized access control framework that automatically applies security policies based on user roles and resource ownership, thereby preventing similar missing authorization flaws across other endpoints within the JeecgBoot application.

Responsible

VulnCheck

Reservation

10/10/2026

Disclosure

10/11/2026

Moderation

accepted

EPSS

0.00000

KEV

no

Activities

low

Sources

Interested in the pricing of exploits?

See the underground prices here!