An instructor can tag their availability slot with another instructor's offering. Combined with the booking offering-substitution flaw (#31), this widens price/payment-routing manipulation.
Fix
Validate that the supplied offering_id resolves to an offering owned by get_current_user_id() (or a studio admin), else reject.
**Severity: Low** — authorization gap; widens the surface of #31.
## Problem
`AvailabilityEndpoint::create()` ([src/Availability/AvailabilityEndpoint.php:105-115](src/Availability/AvailabilityEndpoint.php#L105-L115)) accepts any `offering_id` with no check that the offering belongs to the calling instructor.
## Impact
An instructor can tag their availability slot with another instructor's offering. Combined with the booking offering-substitution flaw (#31), this widens price/payment-routing manipulation.
## Fix
Validate that the supplied `offering_id` resolves to an offering owned by `get_current_user_id()` (or a studio admin), else reject.
Verified resolved on main (061d09e, PR #38): AvailabilityEndpoint::create() now rejects any offering_id that does not resolve to an offering owned by the calling instructor (400 invalid_offering). BookingEndpoint::book() independently enforces that the offering used at booking belongs to the slot's instructor, closing the #31 combination. Re-confirmed during the 2026-06-10 security review pass.
Verified resolved on main (061d09e, PR #38): AvailabilityEndpoint::create() now rejects any offering_id that does not resolve to an offering owned by the calling instructor (400 invalid_offering). BookingEndpoint::book() independently enforces that the offering used at booking belongs to the slot's instructor, closing the #31 combination. Re-confirmed during the 2026-06-10 security review pass.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Severity: Low — authorization gap; widens the surface of #31.
Problem
AvailabilityEndpoint::create()(src/Availability/AvailabilityEndpoint.php:105-115) accepts anyoffering_idwith no check that the offering belongs to the calling instructor.Impact
An instructor can tag their availability slot with another instructor's offering. Combined with the booking offering-substitution flaw (#31), this widens price/payment-routing manipulation.
Fix
Validate that the supplied
offering_idresolves to an offering owned byget_current_user_id()(or a studio admin), else reject.Verified resolved on main (
061d09e, PR #38): AvailabilityEndpoint::create() now rejects any offering_id that does not resolve to an offering owned by the calling instructor (400 invalid_offering). BookingEndpoint::book() independently enforces that the offering used at booking belongs to the slot's instructor, closing the #31 combination. Re-confirmed during the 2026-06-10 security review pass.