CVE-2026-105444 in eShop
Summary
by MITRE • 10/06/2026
A security flaw has been discovered in dotnet eShop .NET 8. The impacted element is the function GetOrderAsync of the file src/Ordering.API/Apis/OrdersApi.cs of the component Ordering API. Performing a manipulation of the argument OrderNumber results in improper control of resource identifiers. The attack is possible to be carried out remotely. The project was informed of the problem early through an issue report but has not responded yet.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/06/2026
The vulnerability identified within dotnet eShop version 8 represents a critical security flaw located specifically in the GetOrderAsync function found in the src/Ordering.API/Apis/OrdersApi.cs file of the Ordering API component. This defect is classified as an Insecure Direct Object Reference, commonly known by its CWE identifier CWE-639. The core technical issue stems from improper control over resource identifiers, where the application fails to adequately validate or authorize access based on the OrderNumber argument provided in a request. Instead of verifying that the authenticated user requesting the order data actually owns or has permission to view that specific order, the system directly uses the supplied identifier to retrieve and return the corresponding database record. This lack of authorization checks allows an attacker who can manipulate the OrderNumber parameter to access sensitive information belonging to other users.
From a technical perspective, this vulnerability exploits the assumption that object identifiers are unguessable or inherently secure when used as primary keys in API endpoints. In many modern web applications and microservices architectures like eShop, APIs often expose resources via RESTful interfaces where the resource ID is passed directly in the URL path or request body. When the backend logic does not implement an access control layer that maps the authenticated session identity to the requested resource identifier, it creates a direct pathway for unauthorized data retrieval. An attacker can systematically iterate through sequential OrderNumbers or use known valid formats to probe the system, effectively bypassing any intended privacy boundaries between different customer accounts.
The operational impact of this vulnerability is significant, primarily centering on the compromise of confidentiality and potential violation of data protection regulations such as GDPR or CCPA due to the exposure of personally identifiable information and order history. Since the attack vector is remote, an adversary does not need physical access or local system privileges; they can exploit this flaw over a network connection by crafting specific HTTP requests with manipulated OrderNumber values. This capability enables unauthorized users to view private details such as shipping addresses, payment methods (if exposed in the response), purchase history, and other sensitive customer data associated with different accounts within the eShop platform.
This type of vulnerability aligns closely with several categories in the MITRE ATT&CK framework, particularly those related to Collection and Exfiltration under techniques like Data from Information Repositories or Unsecured Credentials if combined with further exploitation. It also reflects common patterns found in web application attacks where authentication is present but authorization checks are missing for specific endpoints. The fact that the project was informed of this issue through an early report yet has not responded highlights a potential gap in their security response lifecycle, leaving users exposed until a patch or mitigation strategy is officially released and deployed.
To mitigate this risk, developers must implement robust object-level access control mechanisms within the GetOrderAsync function. This involves ensuring that every request to retrieve order data includes a verification step where the system checks if the currently authenticated user's identity matches the owner of the requested OrderNumber before returning any data. Additionally, implementing rate limiting and input validation can help reduce the effectiveness of automated enumeration attacks targeting sequential identifiers. Organizations using this component should monitor their API logs for unusual patterns in OrderNumber requests, such as rapid successive calls with incrementing IDs, which may indicate an active exploitation attempt. Until a formal patch is available from the project maintainers, applying these defensive coding practices and network-level monitoring controls are essential steps to secure the ordering service against unauthorized data access.