The platform powers large-scale retail operations across online and offline channels, handling massive daily order volumes, invoice generation, delivery orchestration, and store-level fulfillment workflows.

A critical vulnerability within the platform’s AWS-backed order management infrastructure exposed customer PII, invoices, delivery metadata, warehouse operations, employee identifiers, and logistics. The issue potentially affected several hundred thousand customer and operational records.

This issue was responsibly disclosed to the platform’s security team, validated internally, and subsequently remediated within a short timeframe, accompanied by a bounty.

Step-by-Step Breakdown of the Issue info.

Initial Observation

While placing an order through the platform’s e-commerce flow, an AWS API Gateway endpoint responsible for retrieving orders was identified.

The endpoint appeared to be deeply integrated across multiple internal and external systems, including:

• Customer order flows

• Retail POS infrastructure

• Warehouse processing systems

• Invoice generation workflows

• Delivery and logistics orchestration

Further testing revealed that the API accepted direct order identifiers and returned complete order objects without validating customer ownership or enforcing authentication.

Discovery of the Exposure

The vulnerable endpoint exposed order details through predictable order identifiers.

The application relied on a reusable API key embedded within frontend and retail operational flows rather than implementing proper authorization enforcement.

By modifying order reference values, it became possible to retrieve arbitrary customer and operational records belonging to other users.

No authentication, ownership validation, or abuse protection mechanisms were enforced.

The flow effectively looked like:

The API returned complete order objects containing customer, invoice, logistics, and operational metadata.

This allowed unrestricted enumeration of order records at scale.

Data Exposed

The affected API responses exposed highly sensitive customer and operational information, including their Name, Email Address, Phone Number, House Address, signed AWS Invoice URLs, Shipping, and Logistics Info, Store names, Employee names, etc.

Technical Root Cause

The issue originated from broken object-level authorization (BOLA) combined with several insecure architectural decisions:

• Publicly accessible order lookup APIs

• Predictable order identifiers

• Static reusable API keys

• Shared public and internal API infrastructure

• Missing authorization enforcement

The platform relied heavily on API key presence rather than validating whether a user was authorized to access a specific order resource.

As a result, any external actor capable of accessing the endpoint could enumerate customer and operational records at scale.

Impact

The exposure extended far beyond traditional customer PII leakage, this could have led to issues like

• Large-scale customer data harvesting

• Operational reconnaissance

• Fraud targeting

• Social engineering campaigns

• Competitive intelligence gathering

• Supply chain visibility abuse

The issue effectively exposed an end-to-end operational map of the platform’s commerce infrastructure through a single insecure API flow.

Timeline

Vulnerability Discovered: Redacted
Validation Completed: Within 24–48 hours
Remediation Implemented: Shortly after acknowledgment
Public Disclosure: Several months post-fix

The vulnerability allowed unauthorized access to hundreds of thousands of order records, including personal identifiable information (PII) such as names, phone numbers, residential addresses, email IDs, billing details, delivery partner information, and IP addresses.

This issue was responsibly disclosed to the platform’s technology executive leadership, validated internally, and subsequently remediated in a short timeframe.

Step-by-Step Breakdown of the Issue

Users Involved

• User A: A legitimate customer placing an online food order

• User B: Any unauthenticated external user on the internet

Initial Observation

While placing an order through a restaurant’s official website, the application was observed loading a large client-side JavaScript file (main.js) responsible for checkout and order processing logic.

This JavaScript file contained multiple backend API endpoints, some of which appeared to handle order lookups and transaction details.

Given the file size (several thousand lines), used gerben_javado’s Link Finder tool to extract API paths and parameters efficiently.

Discovery of Unauthenticated Endpoints

An unauthenticated API endpoint was identified that returned order details when supplied with a valid order hash.

Although the hash initially appeared non-predictable, something Q2BNr6hxtKK , further testing revealed the presence of a secondary API endpoint that:

• Accepted simple numeric order identifiers

• Returned the corresponding order hash

• Allowed reuse of that hash in the unauthenticated order detail API

This created a complete enumeration chain:

1. Guess numeric order ID

2. Fetch associated order hash

3. Use the order hash to retrieve full PII and transaction details

4. Repeat the process at scale

No authentication, session validation, or rate limiting was enforced at any stage of this flow.

So that flow looked like

• api[.]example[.]com/api/order/4985909 → Returns order metadata, including the hash value

• api[.]example[.]com/api/redacted/order/hash/redacted/A2BNr6hxtKK → Returns full order details and associated PII

  

Data Exposed

The affected API responses contained the following sensitive information:

• Customer's full name

• Mobile phone number

• Email address

• Residential delivery address

• Full billing and order data

• Delivery partner name & phone number

• Restaurant identifiers

• Order timestamps

• IP address

Both customer and restaurant operational data were exposed through this vulnerability of several hundred thousand customers and thousands of restaurants.

Technical Root Cause

The root cause originated from broken object-level authorization (BOLA) combined with:

• Unauthenticated access to order lookup APIs

• Predictable numeric order identifiers

• Public order-hash retrieval endpoints

• Lack of rate limiting and abuse detection

The system relied on the secrecy of order hashes instead of enforcing mandatory authentication and authorization controls, allowing any external actor to retrieve sensitive order records at scale.

Timeline

• Vulnerability Discovered: [Redacted]

• Reported to Organization: [Redacted]

• Acknowledged & Validation Completed: Within 24–48 hours

• Patch & Remediation Implemented: Shortly after acknowledgment

• Public Disclosure: Several months post-fix

This issue was responsibly disclosed to Apple, validated by the Apple Product Security Team, and subsequently remediated.

Step-by-Step Breakdown of the Issue

Users Involved:

• User A: Owner of an iCloud Note

• User B: External user accessing publicly shared Notes

1. A user generated a shareable iCloud Notes link in the format:
   https://www.icloud.com/notes/0MJM1URPtcLj6k0s1bDIIB3Bg

2. Some of these shared Notes were publicly indexed by search engines due to user sharing configurations.

3. Publicly shared Notes links were discovered via google dorking such as:
   site:icloud.com/notes/*

1. When accessing certain shared Notes, the system returned a verification prompt rather than a direct 404 or access denial.

2. Upon clicking the Verify button, the page displayed the email address associated with the Note’s owner along with the file name.

   

   

In some instances, the interface also returned the owner's phone number, depending on the sharing configuration.

4. Opening the same shared link in a private browsing session exposed the full name of the owner.

   

5. Attempts to exploit the verification flow further (e.g., modifying API requests to extract additional data) were mitigated by Apple’s backend and did not result in unauthorized access to note content.

The vulnerability was limited to the exposure of user metadata, not the notes themselves.

Technical Root Cause

The misconfiguration originated from how the iCloud Notes sharing mechanism handled identity verification for shared links. When verification was triggered for a public Note URL, the platform disclosed:

• The email address associated with the Apple ID

• The phone number associated with the Apple ID (in some cases)

• The Apple ID display name

These details were revealed without requiring authentication and were accessible to any external user visiting the shared link.

Additionally, the public indexability of certain Notes URLs allowed search engines like Google to crawl and surface shareable iCloud Notes links, increasing the exposure surface.

Impact

The vulnerability allowed unauthorized users to:

• Identify the Apple ID email address associated with a shared iCloud Note

• Access the Apple ID owner’s phone number in specific cases

• Retrieve the full display name of the Apple ID owner

Although the Note contents were not exposed, this metadata could be used for:

• Targeted phishing

• Social engineering

• Identity profiling

Fix & Apple’s Response

Apple acknowledged the report and addressed the root cause by preventing public crawling of iCloud Notes share URLs and tightening the verification flow to ensure user metadata is no longer exposed.

The issue was fixed completely after acknowledgment.

Apple’s security team handled the disclosure professionally, validated the vulnerability, and credited my name, “Renganathan” in the Apple Security Hall of Fame.

Timeline

• Reported: June 2, 2021

• Accepted & Fix Implemented: June 16, 2021

• Fully Resolved: June 2021

• Hall of Fame Recognition: February 2022