Payment bypass: booking trusts client-supplied offering_id (no slot match) #31

New Issue

2026-06-09T19:08:16Z

thatguygriff commented

2026-06-09 19:08:16 +00:00

Severity: High — remotely exploitable by any logged-in student, direct financial impact.

Problem

BookingEndpoint::book() (src/Booking/BookingEndpoint.php:99-161) takes offering_id straight from the request and never verifies it matches the slot's own offering (or even the slot's instructor):

$offeringId = absint( $request->get_param( 'offering_id' ) );
if ( 0 === $offeringId ) { $offeringId = (int) ( $slot->offeringId ?? 0 ); }
...
if ( null !== $offering && $offering->price > 0.0 ) {
    $this->payments->createForRegistration( ..., $offering->price, ... );
}

Impact

A student can book a paid slot while passing the offering_id of any free offering (or one with price = 0). No Payment row is created, yet the lesson/series is reserved and markBooked() runs → free lessons.
A student can point at a different instructor's offering, so price and etransfer_email are sourced from an unrelated offering while instructor_id comes from the slot → payment misrouting.

Fix

Require the chosen offering to belong to $slot->instructorId and/or to be the slot's own offeringId; reject mismatches with a 400/403.

**Severity: High** — remotely exploitable by any logged-in student, direct financial impact. ## Problem `BookingEndpoint::book()` ([src/Booking/BookingEndpoint.php:99-161](src/Booking/BookingEndpoint.php#L99-L161)) takes `offering_id` straight from the request and never verifies it matches the slot's own offering (or even the slot's instructor): ```php $offeringId = absint( $request->get_param( 'offering_id' ) ); if ( 0 === $offeringId ) { $offeringId = (int) ( $slot->offeringId ?? 0 ); } ... if ( null !== $offering && $offering->price > 0.0 ) { $this->payments->createForRegistration( ..., $offering->price, ... ); } ``` ## Impact - A student can book a **paid** slot while passing the `offering_id` of any **free** offering (or one with `price = 0`). No `Payment` row is created, yet the lesson/series is reserved and `markBooked()` runs → **free lessons**. - A student can point at a **different instructor's** offering, so price and `etransfer_email` are sourced from an unrelated offering while `instructor_id` comes from the slot → **payment misrouting**. ## Fix Require the chosen offering to belong to `$slot->instructorId` and/or to be the slot's own `offeringId`; reject mismatches with a 400/403.

thatguygriff added the payments security bug labels 2026-06-09 19:08:16 +00:00

thatguygriff referenced this issue

2026-06-09 19:08:30 +00:00

Instructor can attach a slot to an offering they don't own #34

thatguygriff referenced this issue from a commit

2026-06-09 20:01:02 +00:00

Harden booking, offering exposure, payments, and invites

thatguygriff referenced a pull request that will close this issue

2026-06-09 20:02:04 +00:00

Security hardening: booking auth, offering exposure, payments, invites (#31–#37) #38

thatguygriff referenced this issue from a commit

2026-06-09 20:08:59 +00:00