CVE-2026-67358

This vulnerability exposes a fundamental authorization failure in token-scoped download systems: the endpoint validated that an order token was genuine, but never verified that the token's order actually owned the download record being accessed. The pattern likely looked like `if (validOrderToken($token)) { incrementDownload($download_id); }` — a check that proves the token is real but says nothing about whether that token authorizes access to the specific record. The core issue is conflating token validity with resource authorization. An order token proves a purchase occurred; it does not prove the bearer can manipulate any download record tied to any order. The fix must add ownership validation: verify that `token.order_id === download_record.order_id` (or equivalent) before permitting any state-changing operation on the download record. Without this check, any authenticated user who knows a download record ID can manipulate another customer's download quota. The CSRF token absence mentioned in the advisory is a separate issue. CSRF protects against attacker-controlled browsers tricking victims into actions. In this case, the attacker needs a valid order token — which they could obtain from their own purchase, extraction from API responses, or enumeration. CSRF would not have prevented token-based enumeration attacks, so treat these as independent vulnerabilities requiring independent fixes. Prioritize these actions: First, audit all endpoints accepting download_record_id, invoice_id, or similar resource identifiers to confirm they validate ownership against the token's scope. Second, determine whether your deployment exposes sequential IDs in URLs, APIs, invoices, or emails — sequential IDs collapse the 'authenticated user' constraint into near-universal access. Third, review any parallel version branches (the affected component shipped vulnerable across 1.x, 4.0.x, and 4.1.x independently), as partial patches in one branch may not propagate to others. Fourth, treat any scoped bearer token — order tokens, transaction tokens, session-adjacent credentials — as requiring explicit resource-ownership validation, regardless of how narrowly the token was designed.

Reviewed through automated stages and approved by a human before publication.