KitchenAsty EUVD-2026-89425

Requires a valid authenticated account on the KitchenAsty application (the authenticate middleware is applied and enforced), so a completely anonymous attacker cannot exploit it - this is what limits exploitation. Given any authenticated principal, no further conditions apply: the GET /api/reservations/:id endpoint performs no ownership comparison (reservation.customerId vs the authenticated principal) and no role check, so it works against default configurations of KitchenAsty through version 0.3.0. Impact is read-only disclosure of a single reservation record per request; there is no user-interaction, non-default-configuration, or special-platform requirement beyond holding a low-privilege customer session.

This is a genuine but low-severity access-control flaw, and the signals are internally consistent rather than conflicting. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N, base 4.3) matches the description precisely: exploitation is remote and trivial (increment/guess an :id path parameter) but requires an authenticated account (PR:L), yields only read access to another customer's single reservation record (C:L), and causes no integrity or availability impact. No EPSS score, CISA KEV entry, or public exploit code is present in the supplied intelligence, so the correct exploitation status is: no public exploit identified at time of analysis. There is no conflict between severity and real risk here - this is correctly a low priority, not a high-CVSS-but-low-risk false alarm. The dominant risk-reducer is prevalence: KitchenAsty is an obscure GitHub hobby/small-project codebase (mighty840/kitchenasty), so real-world exposure is minimal. The fix is confirmed available (PR #43 and GHSA-2w4m-hjg2-2v92 advisory), and the vulnerable-code path is confirmed by source (reservation.controller.ts). Note that the fix diff in PR #43 shown here demonstrates the ownership-check pattern on the ORDER controller (order.customerId !== user.id with a staff bypass) rather than the reservation controller named in the description - the same remediation pattern applies, but the exact reservation.controller.ts hunk is not in the provided diff, so verify the reservation fix landed.

An attacker registers or already holds a legitimate low-privilege customer account, authenticates, then issues GET /api/reservations/:id iterating or guessing reservation identifiers belonging to other customers. Because the handler returns the record without comparing reservation.customerId to the authenticated principal, the attacker harvests other patrons' reservation details (e.g., names, contact, party/booking data). No public exploit code is identified; exploitation is manual and requires only a valid session.