Tandoor Recipes EUVD-2026-103142

Requires an authenticated account that is a member of a shared Space (Space sharing must be enabled), plus knowledge or enumeration of another member's private recipe object identifier - this is the concrete prerequisite stated in the description ('authenticated member of a shared Space supplies another member's private recipe identifier'). The affected flows are the api/ai-import/, api/get_recipe_file/, api/get_external_file_link/, and api/share-link/ endpoints, which fail to invoke the private-recipe owner/sharing (CustomRecipePermission) check. Limiting factors: the attacker must already be inside the same Space (no external/unauthenticated path), the targeted recipe must exist in that shared Space, and public-link disclosure via api/share-link/ specifically depends on Space sharing being enabled; single-user or non-shared deployments are not exposed.

This is a legitimate but moderate-priority issue, not a top-tier emergency. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N, base 7.1) is internally consistent with the description: exploitation is network-reachable but requires PR:L - an authenticated member of a shared Space - which materially limits the attacker population to insiders who already belong to the same tenant. CWE-639 (authorization bypass through user-controlled key / IDOR) matches the root cause: recipe utility endpoints resolve same-Space Recipe objects by identifier without enforcing the private-recipe owner/sharing permission. No EPSS score, KEV listing, or public POC was provided in the input; per the data, there is no public exploit identified at time of analysis, so there is no evidence of active or widespread exploitation. The confidentiality impact (C:H) is the dominant signal - private recipe files and uploaded content can be disclosed to another same-Space user and, notably, exfiltrated to the configured external AI provider - while integrity is limited (I:L, via creation of external/public share links) and availability is unaffected (A:N). Net: a real data-confidentiality bug worth patching promptly in multi-tenant/shared-Space deployments, but the required authenticated same-Space foothold and the niche, self-hosted nature of the product keep real-world mass-exploitation risk low.

An authenticated user who is a member of a shared Tandoor Space enumerates or guesses another member's private recipe ID and submits it to the AI-import, get_recipe_file, external-file-link, or share-link endpoints. Because object-level authorization is missing, the server returns the private recipe's file bytes, transmits them to the configured external AI provider, or mints a disclosable/public external link - exposing another member's private content. No public exploit code is identified at time of analysis, but the attack is low-complexity and needs no user interaction once the attacker holds a valid shared-Space account.