Skip to main content

KitchenOwl CVE-2026-101033

| EUVDEUVD-2026-87946 MEDIUM
Authorization Bypass Through User-Controlled Key (CWE-639)
2026-09-27 VulnCheck GHSA-xxhh-mxcg-vmh8
5.3
CVSS 4.0 · Vendor: VulnCheck
View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

  1. Access
    Authenticate to KitchenOwl instance
  2. Exploit
    Enumerate sequential category IDs
  3. Execution
    Submit expense/item op with foreign category ID
  4. Impact
    Read leaked category name/budget/color

Vulnerability Assessment

Weakness
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V8 - Authorization Object-level authorization, IDOR prevention
Exploitation Conditions

Requires a valid authenticated account (PR:L) on a KitchenOwl instance that hosts multiple households, since the attack reads categories belonging to households other than the caller's. Exploitation targets the expense and item create/update API operations (addExpense/updateExpense, addItem/updateItem) where a caller-supplied category ID is used without verifying category.household_id matches the caller's household. No user interaction is needed. Impact is limited to reading category metadata (names, budgets, colors); it does not permit modification or cross-household writes, and single-household/single-tenant deployments have little to disclose. Affected versions are KitchenOwl through 0.7.10; upgrading past the PR #1155 fix eliminates the flaw.

Impact

This is a genuine but low-severity broken-object-level-authorization (IDOR) flaw. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) indicates network-reachable, low-complexity exploitation but requires an authenticated account (PR:L), and impact is confined to confidentiality (VC:L only; VI:N/VA:N) - an attacker can read other households' category names, budgets, and colors but cannot modify or destroy data. No EPSS score, no CISA KEV listing, and no standalone public exploit are provided; per the precision rules this is 'no public exploit identified at time of analysis.' The vendor has shipped a patch (PR #1155 / commit c15f6cb2), and the fix diff confirms the root cause precisely (missing category.household_id == household_id checks in expense and item controllers), so the technical claim is well-substantiated. Net: this is a real data-isolation bug worth patching in multi-tenant deployments, but it is a low-priority issue rather than a high-urgency one - limited disclosure impact, requires authentication, and no evidence of exploitation. The 5.3 score is consistent with a low-confidentiality-only leak.

Exploit ScenarioDerived

An authenticated KitchenOwl user on a shared/multi-household instance submits expense or item create/update requests while substituting category IDs they do not own, iterating through numeric IDs to enumerate categories belonging to other households. The server returns the foreign category's name, budget, and color, breaking household isolation. No public exploit code is referenced, though the mechanics are trivial to reproduce from the described API behavior and the published fix.

This Month Plan within 30 days. Why: MEDIUM severity (CVSS 4.0-6.9).
Patch available 0.2% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv1 – Sep 27, 2026

KitchenOwl through 0.7.10 allows authenticated users to read category metadata (names, budgets, and colors) from other households due to a broken object-level authorization flaw in the expense and item API operations. The vulnerability requires a valid account and targets the addExpense/updateExpense and addItem/updateItem endpoints, which fail to verify that a supplied category ID belongs to the caller's household. No public exploit code has been identified at time of analysis, and the impact is limited to read-only information disclosure in multi-household deployments.

RemediationAI

Apply the upstream fix from PR #1155 (commit c15f6cb21a98d5eb70746bee6b63773a6d6a6251) or upgrade to a KitchenOwl release that includes this commit; the exact patched version number is not confirmed in the provided data, but the fix validates that category IDs belong to the caller's household. Vendor advisory: https://www.vulncheck.com/advisories/kitchenowl-through-0.7.10-idor-via-unchecked-category-id and GitHub issue: https://github.com/TomBursch/kitchenowl/issues/1154. If patching is not immediately possible, compensating controls are limited: in multi-household deployments, you could temporarily restrict expense/item creation and update permissions to trusted users (side effect: breaks normal functionality for regular users), or monitor API logs for sequential category ID enumeration across households (side effect: detection only, no prevention). Because the flaw is read-only and low severity, disabling core features is likely not justified for most deployments.

Affected VersionsENISA

kitchenowl 0 ≤0.7.10

Affected Packages

euvd kitchenowl no fix

Source: OSV (Open Source Vulnerabilities)

Affects your stack

Affects 1 package in euvd

Checking this CVE against your own stacks and servers is part of the Basic plan and up.

Technical ContextAI · show details

This is a CWE-639 Authorization Bypass Through User-Controlled Key (IDOR) issue. KitchenOwl is a self-hosted household management application written in Python (Flask). The affected code paths in backend/app/controller/expense/expense_controller.py (lines 115-118) and backend/app/controller/item/item_controller.py (lines 86-88) use a caller-supplied category ID to fetch a Category object without checking that the category's household_id matches the caller's household. As a result, an authenticated user can enumerate category IDs to access categories from other households, revealing category names, budgets, and colors. The upstream patch (PR #1155) adds explicit household_id validation: in addExpense and updateExpense it raises NotFoundRequest if the category does not belong to the household, and in addItem/updateItem it raises InvalidUsage for the same condition. The CPE cpe:2.3:a:tombursch:kitchenowl:*:*:*:*:*:*:*:* indicates that all versions through 0.7.10 are affected; no fixed version is specified in the input data.

Know when Kitchenowl gets its next vulnerability

  • Watch products and get an email when something new is published
  • Check this CVE against your own stack and servers
  • Exploit and PoC references, threat intelligence from 22 sources

No credit card · 7-day full trial

Severity by source

Vendor (VulnCheck) PRIMARY 5.3 MEDIUM
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N
vuln.today AI 4.3 MEDIUM

Network API reachable with low complexity but requires an authenticated account (PR:L); impact is limited read-only disclosure of category metadata, so C:L and I:A:N.

3.1 AV:N/AC:L/PR:L/UI:N/S:N/C:L/I:N/A:N
4.0 AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N

Primary rating from Vendor (VulnCheck).

CVSS VectorVendor: VulnCheck

Attack Vector
Network
Attack Complexity
Low
Attack Requirements
None
Privileges Required
Low
User Interaction
None
Vulnerable system: Confidentiality
Low
Vulnerable system: Integrity
None
Vulnerable system: Availability
None
Subsequent system: Confidentiality
None
Subsequent system: Integrity
None
Subsequent system: Availability
None

DescriptionCVE.org

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.

Threat Intelligence Overview

EPSS Score
0.2%
Top 88% exploitable
Prevalence
Low
self-hosted hobbyist grocery/household app, no enterprise footprint
Social Media
1
Sightings
Data Quality
5 sources
Confidence: Medium

How this decision was reached

The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.

SignalValue
Severity MEDIUM
CISA KEV No
Public POC No
EPSS 0.2%
Patch available Yes
Active threat No
Deciding rule
MEDIUM severity (CVSS 4.0-6.9)
What every action level means
Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.
Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.
This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.
This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.
Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision· derived
Scheduled
Exploitation
None
System Exposure· derived
Open
Automatable
No
Human Impact· derived
Medium
Technical Impact
Partial

Priority Score

26
Low Medium High Critical
KEV: 0
EPSS: 0
CVSS: +26
PoC: 0
Weaponized: 0
Threat intel: 0
Gov advisory: 0

Attack Technique

Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy