Is this urgent?
Yes
What parts are affected
Backend
What is the server version
source commit ab4530e
What is the client version
source commit ab4530e
What platform are you using
No response
What's the problem 馃
Summary
An authenticated user can supply another household's integer category ID while creating or updating an expense or item. KitchenOwl resolves the category globally, and the response discloses its name. Expense responses also disclose its budget and owning household ID.
Details
expense_controller.py calls ExpenseCategory.find_by_id(args["category"]), and item_controller.py uses ItemCategory.find_by_id the same way. Neither checks which household the category belongs to.
The surrounding code does know how. Nearby member and item lookups use household-aware methods, and the direct category routes correctly return 403 across households.
Proof of concept
Create distinct categories in two households. As the attacker, submit the victim's category ID in an otherwise attacker-owned expense or item request.
The verified expense response included the victim category's name, budget, and household_id, and the item response included its name. Requesting that same category directly as the attacker returned 403. poc.sh (available at the following Gist: https://gist.github.com/Koukyosyumei/72db4f395c9e120044a8ecd2e266fa21) runs both attacks alongside the direct request that is correctly refused.
Impact
Any registered user can enumerate integer IDs and disclose category metadata across households. The demonstrated data is limited category metadata rather than all household financial records.
Remediation
Resolve every supplied category through a query constrained by the current household_id, and reject or return 404 for foreign IDs. Apply the check before assigning the relationship.
Share your logs
Share your configuration
Is this urgent?
Yes
What parts are affected
Backend
What is the server version
source commit ab4530e
What is the client version
source commit ab4530e
What platform are you using
No response
What's the problem 馃
Summary
An authenticated user can supply another household's integer category ID while creating or updating an expense or item. KitchenOwl resolves the category globally, and the response discloses its name. Expense responses also disclose its budget and owning household ID.
Details
expense_controller.pycallsExpenseCategory.find_by_id(args["category"]), anditem_controller.pyusesItemCategory.find_by_idthe same way. Neither checks which household the category belongs to.The surrounding code does know how. Nearby member and item lookups use household-aware methods, and the direct category routes correctly return 403 across households.
Proof of concept
Create distinct categories in two households. As the attacker, submit the victim's category ID in an otherwise attacker-owned expense or item request.
The verified expense response included the victim category's name, budget, and
household_id, and the item response included its name. Requesting that same category directly as the attacker returned 403.poc.sh(available at the following Gist: https://gist.github.com/Koukyosyumei/72db4f395c9e120044a8ecd2e266fa21) runs both attacks alongside the direct request that is correctly refused.Impact
Any registered user can enumerate integer IDs and disclose category metadata across households. The demonstrated data is limited category metadata rather than all household financial records.
Remediation
Resolve every supplied category through a query constrained by the current
household_id, and reject or return 404 for foreign IDs. Apply the check before assigning the relationship.Share your logs
Share your configuration