CVE-2026-79348: Medium severity KitchenAsty vulnerability
KitchenAsty through 0.3.0 contains a broken object level authorization (IDOR) vulnerability in the reservations API. The endpoint GET /api/reservations/:id in packages/server applies the authenticate middleware but performs no ownership or role check, and the getReservation handler in packages/server/src/controllers/reservation.controller.ts returns the record retrieved by the client-supplied identifier without comparing reservation.customerId to the authenticated principal
Affected Software
Event History
Frequently Asked Questions
Who can exploit this issue?
Any authenticated user with a valid account can exploit it. The endpoint requires authentication, but it does not verify that the requester owns the reservation or has an authorized role.
What does an attacker need to access another reservation?
The attacker needs to send a request to GET /api/reservations/:id using a reservation identifier for a record they do not own. Network access to the API and low-privileged authenticated access are required.
What information can be exposed?
The affected handler returns the reservation record selected by the client-supplied identifier. The provided data does not specify the exact fields contained in reservation records.
Are deployments affected by default?
Deployments running KitchenAsty through version 0.3.0 are affected where the described reservations endpoint is available. Authentication alone does not prevent the issue because the route lacks ownership and role authorization checks.
What can be done if an update is not immediately available?
Restrict access to the reservations API to trusted users and apply an authorization check that compares the authenticated principal with reservation.customerId, while allowing any intended privileged roles explicitly. Monitor requests to the endpoint for users retrieving reservation IDs that do not belong to them.