KitchenOwl EUVD-2026-104319

Requires an authenticated KitchenOwl household member (PR:L) to invoke the recipe-import/scrape feature with an attacker-supplied URL. The attacker must host a page whose HTML title is "KitchenOwl" at a URL path matching /recipe/<id>, which causes the local-instance detection to trigger a second requests.get() to api_url + "/recipe/" + recipe_id that - unlike the first fetch - bypasses the IP filter; that follow-up request must then be redirectable or DNS-rebindable to loopback, private-network, or cloud-metadata addresses. Limiting factors: a valid household account is mandatory (no anonymous exploitation), the attacker must control an externally reachable page, impact is confined to reading responses from reachable internal services (no write/RCE), and only KitchenOwl versions through 0.7.10 are affected - patched builds route the call through the hardened request_manager.

This is a genuine but modest-priority issue, not a top-tier emergency. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) confirms network-reachable exploitation requiring authentication (PR:L - an existing household member), with no user interaction. Impact is limited: VC:L and VI:N/VA:N mean only partial confidentiality exposure (reading internal service responses), with no integrity or availability impact and no subsequent-system scope change (SC:N/SI:N/SA:N), consistent with a read-oriented SSRF. No EPSS score was provided, so exploitation probability cannot be quantified. The vulnerability is NOT in CISA KEV and no public exploit code is referenced, so there is no evidence of active exploitation - the finding originates from VulnCheck research with a vendor patch already available. The authentication requirement (PR:L) meaningfully constrains the attacker population to trusted household members, which lowers real-world risk below what the CWE-918 SSRF class might suggest in isolation. Net: a valid, patch-worthy defense-in-depth flaw, but low-to-moderate urgency absent any exploitation signal.

An authenticated KitchenOwl household member submits a recipe-import URL pointing to an attacker-controlled page whose HTML title is "KitchenOwl" and whose path matches /recipe/<id>. This tricks the backend into treating it as a KitchenOwl instance and issuing a second, unfiltered requests.get() call that the attacker redirects or DNS-rebinds to loopback, private-network, or cloud-metadata (e.g., 169.254.169.254) addresses, returning the internal response to the attacker. No public exploit identified at time of analysis.