Description

KitchenOwl through 0.7.10 fails to verify that category IDs belong to the caller's household in expense and item operations. Authenticated attackers can enumerate category IDs from other households to read their category names, budgets, and colors, breaking household isolation.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "4.3",
  "pubDate": "2026-09-27T14:16:29.273Z",
  "pubdate": "2026-09-27T14:16:29.273Z",
  "executiveSummary": "KitchenOwl versions through 0.7.10 contain a critical Broken Access Control vulnerability stemming from a failure to validate object ownership at the database or application level.\nThe vulnerability allows authenticated users to bypass logical household isolation boundaries.\nBy manipulating category ID parameters during expense and item-related API requests, an attacker can perform unauthorized read operations on resources belonging to other households.\nThis flaw results in the exposure of sensitive metadata, including category names, financial budget allocations, and UI-specific color configurations associated with private households.\nThe risk is categorized as high due to the potential for large-scale information harvesting, as the vulnerability facilitates the enumeration of cross-tenant data without requiring administrative privileges.\nExploitation requires only an active authenticated session within the application, making it accessible to any registered user.",
  "technicalDetails": "The root cause of the vulnerability lies in the application's backend logic when processing expense and item operations. Specifically, the API endpoints responsible for interacting with category resources fail to perform server-side validation to ensure that the provided category ID is associated with the authenticated caller's household context.\nIn a secure multi-tenant architecture, the application should enforce a strict authorization check, verifying that the requested resource ID belongs to the tenant (household) assigned to the current user's session token. KitchenOwl's implementation omits this verification, treating category ID references as globally accessible or failing to scope the database queries by the household_id attribute during the fetch operation.\nThe attack flow proceeds as follows: 1. The attacker authenticates as a standard user within the KitchenOwl platform. 2. The attacker identifies the API endpoints used for expense or item management that accept category ID parameters. 3. By performing horizontal enumeration, the attacker systematically increments or modifies the category ID parameters within the request body or URL path. 4. Because the backend processes these requests without validating ownership, the server executes a database query that retrieves object details—specifically names, budgets, and interface colors—from records belonging to other households. 5. The application returns the requested data in the response body, successfully leaking information across household boundaries.\nThis flaw constitutes a clear instance of Insecure Direct Object Reference (IDOR). Since the backend fails to implement a secondary check—such as a SQL join with a household mapping table or an application-layer permission check—the request is blindly honored as long as the session is valid. The lack of input validation regarding resource ownership allows an attacker to map the internal data structures of other households. The impact is significant as it compromises the confidentiality of household data, specifically revealing sensitive information regarding spending habits and budgetary constraints, which could be used for reconnaissance or further targeting of specific tenants within the ecosystem."
}