Description

DataEase before 2.10.26 contains multiple access control defects in the sharing link module. Tickets are not bound to the target share UUID, so a valid ticket issued for one share can be reused against another (ShareTicketManage.validateTicket / POST /de2api/share/proxyInfo). The POST /de2api/share/validate endpoint issues a LinkToken after password verification without requiring a ticket, bypassing the 'ticket mandatory' policy. Additionally, the ticket create and delete endpoints (POST /de2api/ticket/saveTicket, POST /de2api/ticket/delTicket) lack share-ownership checks, allowing an authenticated user who knows another user's ticket to modify, rebind, or delete it (denial of service), and GET /de2api/share/queryRelationByUserId/{uid} allows authenticated users to enumerate other users' share mappings.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.3",
  "pubDate": "2026-08-31T11:16:41.603Z",
  "pubdate": "2026-08-31T11:16:41.603Z",
  "executiveSummary": "DataEase versions prior to 2.10.26 are affected by multiple access control and authorization defects within the sharing link and ticket management modules.\nThese vulnerabilities allow authenticated and unauthenticated attackers to bypass security policies, perform unauthorized actions on sharing objects, and enumerate user data.\nThe primary impact includes the potential for unauthorized access to shared resources through ticket reuse, denial of service (DoS) against other users' tickets, and sensitive information disclosure via unauthorized mapping enumeration.\nThe flaws stem from improper validation of share UUID bindings, missing ownership checks during ticket lifecycle operations, and incomplete enforcement of mandatory token policies.\nExploitation ranges from the unauthorized access of shared links to the manipulation of administrative ticket states by authenticated users who possess knowledge of target identifiers.\nThe risk is significant as it undermines the integrity and confidentiality of the sharing mechanism within the DataEase platform.",
  "technicalDetails": "The vulnerability resides in the core architectural handling of sharing links and ticket validation logic within DataEase. Multiple distinct flaws contribute to the overall security degradation.\nFirst, the ShareTicketManage.validateTicket function and the POST /de2api/share/proxyInfo endpoint fail to perform proper cryptographic or referential binding between a valid ticket and a specific share UUID. Consequently, a ticket generated for one share object is accepted as valid for any other share object, enabling cross-share unauthorized access.\nSecond, the POST /de2api/share/validate endpoint exhibits a broken authentication workflow. After password verification, it issues a LinkToken without enforcing the 'ticket mandatory' policy, allowing an attacker to bypass legitimate authorization flows intended to protect shared content.\nThird, the system lacks adequate resource ownership authorization for the ticket management endpoints: POST /de2api/ticket/saveTicket and POST /de2api/ticket/delTicket. The application fails to verify if the requesting user holds the necessary permissions for the target ticket ID. As a result, an authenticated user can perform unauthorized modifications, rebind existing tickets to different share parameters, or perform a denial of service by explicitly deleting tickets they do not own, provided they can guess or acquire the target identifier.\nFourth, the GET /de2api/share/queryRelationByUserId/{uid} endpoint lacks sufficient authorization checks, allowing any authenticated user to enumerate share mappings associated with arbitrary user IDs (uids). This facilitates the discovery of private share relationships across the platform.\nAttack flow for ticket reuse involves an attacker intercepting a valid ticket from one session and injecting it into requests targeting sensitive shares protected by other tickets. In the case of DoS, an attacker iterates through known ticket IDs and issues deletion requests to the /de2api/ticket/delTicket endpoint. Information disclosure occurs via systematic enumeration of the {uid} parameter in the queryRelationByUserId path, which exposes internal mappings to unauthorized actors. These vulnerabilities collectively demonstrate a systemic failure in enforcing access control at the service layer for the shared resource management module."
}