CVE-2026-96599 in Isotope Core
Summary
by MITRE • 09/23/2026
Isotope eCommerce through 2.9.10 derives order identifiers from uniqid() instead of a cryptographically secure source, allowing unauthenticated attackers to guess identifiers. Guest orders lack ownership verification, enabling attackers to access order details including billing address, customer information, and purchased files by supplying a guessed uid parameter.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/23/2026
The vulnerability in Isotope eCommerce versions through 2.9.10 stems from the use of non-cryptographically secure random number generation for creating unique identifiers associated with user orders. Specifically, the application relies on PHP's uniqid() function to generate these order IDs rather than employing a cryptographically strong pseudo-random number generator such as CSPRNG or random_bytes(). The uniqid() function generates identifiers based on the current time in microseconds and an optional prefix, which results in sequential or highly predictable values when requests are made in quick succession. This design flaw fundamentally undermines the assumption that order identifiers are unpredictable to external parties, thereby exposing sensitive data associated with those orders to unauthorized access by unauthenticated attackers who can systematically guess valid identifier sequences.
From a technical perspective, this issue represents a classic case of insufficient randomness leading to predictable resource IDs. The uniqid() function is not designed for security-sensitive applications where unpredictability is paramount because its output space is small and temporally correlated with system clock values. Attackers can exploit this by iterating through likely identifier ranges or leveraging the temporal proximity of their requests to previous legitimate order creations to predict subsequent identifiers. Since guest orders do not implement ownership verification mechanisms such as session binding, authentication tokens, or IP-based restrictions during retrieval operations, any validly guessed identifier grants immediate access to the associated data without requiring prior login credentials or proof of purchase.
The operational impact of this vulnerability is significant for both customers and merchants. Unauthenticated attackers can enumerate order identifiers to retrieve sensitive personally identifiable information including billing addresses, contact details, and potentially purchased digital files if they are accessible via direct links tied to these IDs. This exposure violates data privacy regulations such as GDPR or CCPA depending on the jurisdiction and erodes customer trust in the e-commerce platform's ability to protect personal information. Furthermore, the ability to access purchased files without verification may lead to intellectual property theft or unauthorized distribution of copyrighted material, resulting in direct financial losses for merchants and potential legal liabilities related to data breaches.
This vulnerability aligns with CWE-330: Use of Insufficiently Random Values, as it involves generating identifiers that are not sufficiently unpredictable for their intended security purpose. In the context of the MITRE ATT&CK framework, this flaw facilitates unauthorized access through enumeration techniques and can be categorized under T1592: Gather Victim Host Information or more broadly within initial access vectors where weak authentication controls allow data exfiltration. The lack of ownership verification also reflects CWE-862: Missing Authorization, as the application fails to enforce proper access control policies that verify whether a user is authorized to view specific resources before disclosing them.
To mitigate this vulnerability, developers must replace uniqid() with cryptographically secure random functions provided by modern programming languages or libraries, such as bin2hex(random_bytes()) in PHP for generating unique identifiers. Additionally, the application should implement strict access control checks that verify ownership of an order before returning any sensitive data to a requester. This can be achieved by requiring authentication tokens tied to user sessions for all order-related API endpoints and ensuring that guest orders are either restricted from public retrieval or protected with additional verification steps such as email confirmation links sent only to the registered address. Regular security audits focusing on ID generation practices and access control implementations should also be conducted to prevent similar issues in other parts of the application ecosystem.