CVE-2026-110772 in Sure
Summary
by MITRE • 10/15/2026
Sure 0.7.0 through 0.7.6-alpha.6 contains a missing authorization vulnerability in Transactions::BulkUpdatesController#create that allows family members to bypass account sharing permissions. Authenticated members with read_only or no share can submit arbitrary entry_ids to modify other members' transaction dates, names, notes, categories, merchants and tags, corrupting budgets and reports.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/15/2026
The vulnerability identified in Sure versions 0.7.0 through 0.7.6-alpha.6 represents a critical failure in access control mechanisms within the Transactions::BulkUpdatesController#create endpoint. This flaw is classified as an Insecure Direct Object Reference, which falls under CWE-639 in the Common Weakness Enumeration standard. The core issue lies in the application's inability to properly validate whether the authenticated user initiating the bulk update request has sufficient privileges to modify the specific transaction records referenced by the provided entry_ids. Instead of enforcing strict ownership or role-based permissions for each individual record being updated, the system relies on a flawed authorization logic that permits any logged-in family member to execute modifications regardless of their assigned share level.
In a typical multi-user financial application like Sure, account sharing is governed by granular permission sets such as read_only, no_share, or full_access. Users with limited permissions are expected to have restricted visibility and write access to ensure data integrity across shared budgets. However, due to this missing authorization check, an authenticated user possessing only read-only privileges or even no share at all can submit arbitrary transaction identifiers to the bulk update endpoint. The server processes these requests without verifying if the target transactions belong to a different account holder who has restricted their sharing settings. This effectively allows unauthorized users to bypass the intended isolation boundaries between family members' financial data.
The operational impact of this vulnerability is significant, as it enables malicious or compromised accounts to corrupt shared budgets and distort financial reports. By modifying transaction dates, names, notes, categories, merchants, and tags for other members, an attacker can manipulate expense tracking metrics, alter income categorization, and create false historical records. This not only compromises the accuracy of personal finance management but also undermines trust within family or group accounts where accurate data sharing is essential. The ability to arbitrarily change transaction metadata means that financial audits become unreliable, and users cannot depend on their budgeting tools for decision-making purposes.
From a threat modeling perspective using the MITRE ATT&CK framework, this vulnerability aligns with T1078 Valid Accounts, as it exploits legitimate credentials to perform unauthorized actions, and potentially relates to data manipulation techniques that could be used in later stages of an attack chain if combined with other flaws. The lack of proper object-level authorization checks is a common pitfall in web applications where bulk operations are implemented without iterating through each item to verify individual permissions. This oversight allows for mass modification attacks that would otherwise require multiple distinct requests, thereby increasing the efficiency and impact of the exploitation.
To mitigate this vulnerability, developers must implement rigorous server-side validation within the Transactions::BulkUpdatesController#create method. Each entry_id submitted in a bulk update request should be individually checked against an authorization policy that confirms the requesting user has write access to that specific transaction record. This involves querying the database or application state to verify ownership and permission levels before allowing any modifications. Additionally, implementing principle of least privilege ensures that users with read_only or no_share permissions are explicitly denied write operations at the API level, regardless of how many records they attempt to update in a single request. Regular security audits focusing on access control logic for bulk endpoints can prevent similar issues from arising in future updates.