CVE-2026-67359

The CVSS 8.7 score for this order confirmation disclosure mischaracterizes the actual risk. The vulnerability is not merely that an attacker can view a single order byits order_id — it is that predictable or sequential order IDs enable systematic enumeration, turning what the scoring framework treats as an information disclosure into a behavioral intelligence harvesting operation. Purchase histories, price sensitivity curves, product affinity patterns, inventory movement signals, and customer lifetime value stratification become actionable intelligence when enumerated at scale. That is a fundamentally different threat class than a one-off privacy leak. If order IDs in the affected versions (prior to 3.3.21, 4.0.21, and 4.1.6) followed a sequential or timestamp-derived pattern, the exposure window extends to every order ever placed during that period — not just the time between disclosure and patch. Intelligence harvested during that window does not expire when you apply the fix. A competitor or threat actor who enumerated this data in 2024-2025 holds actionable behavioral baselines indefinitely. The critical verification step for defenders is this: examine whether the fix implements session-bound validation (confirmation page only renders for the active purchasing session that created the order) or whether it relies on ID obfuscation or rate limiting alone. If the confirmation page remains accessible via direct URL with an order_id parameter without session binding, the architectural flaw persists — it is merely obfuscated. Historyrhyme's observation is particularly salient: J2Store likely already had HMAC-signed expiring tokens implemented for email confirmation links within the same codebase, meaning the failure was inconsistent application of a known pattern rather than ignorance of the solution. The delta between the two authentication models is exactly where the vulnerability persisted. Given the exposure window spanning three version branches (3.3.x, 4.0.x, 4.1.x) over what appears to be years, and the reality that Joomla extension deployments frequently lag behind on patching, the vulnerable code path almost certainly still executes in production today on systems whose operators may never see this CVE. Assume historical enumeration has occurred and treat the exposed customer data as potentially compromised.

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