When we buy products online, we hand companies our most sensitive information and trust them to keep it locked away. That expectation becomes even more critical when the product in question is an intimate wellness item. You assume the company has done the bare minimum — protected your name, your address, your phone number, and what exactly you ordered.

Durex India had not.

This is the story of how a curious glance at a Twitter reply led me to a vulnerability that exposed the personally identifiable information of thousands — potentially millions — of Indian customers. Full names, email addresses, phone numbers, home addresses, and intimate purchase histories. All of it. Freely accessible to anyone on the internet, no login required.

Responsible Disclosure Notice

This writeup documents a security vulnerability that has been fully remediated by the vendor. All research was conducted ethically and in good faith — no customer data was accessed beyond what was necessary to confirm the vulnerability, and no data was stored, shared, or exploited at any point.This article is intended purely for educational purposes: to help developers understand how misconfigured APIs lead to real-world privacy risks, and to encourage companies to take responsible disclosure seriously. All screenshots have been sanitized to remove personally identifiable information prior to publication.

If you are from the Durex India or Reckitt security team and have concerns about this disclosure, you are welcome to reach out directly.

The Spark: A Hacker's Curiosity

It was a regular evening. I was scrolling through Twitter when a Durex India support reply stopped me cold — not because of what they said, but because of what they showed. A customer had posted a screenshot of their order as part of a complaint, and right there in the image, their Order ID was fully visible. Public. Visible to anyone who scrolled past.

OrderID: DX976441.

Most people scroll past that without blinking. But there's a particular kind of brain damage that comes from spending too much time poking at systems — you start seeing attack surfaces in things other people call mundane. My brain filed that order ID under interesting before I even consciously registered it.

Sequential. Numeric. Guessable. I wonder how their tracking works.

New tab. Let's find out.

Finding the Door

The global site, durex.com, redirected me straight to WhatsApp. I tried the order ID there. Nothing. Dead end.

I went to durexindia.com instead — and found a third-party AI chatbot on the page, powered by getmanifest.ai, designed to help customers track their orders. Simple premise: type in your order ID, get your status back.

I hit F12, opened DevTools, and watched the Network tab as I entered an order ID.

The chatbot wasn't talking to Durex's own servers. It was firing a POST request to bikapi.bikayi.app — a third-party commerce backend. The request body had exactly two fields:

{
  "store_id": "B3hW012LKSX5Z5rcaNPFBOZOYOt2",
  "order_id": "#DX976441"
}

No auth header. No session token. No OTP. No verification of any kind. Just a static store_id — hardcoded, identical in every request from every user — and an order_id.

I stared at the screen. That's it?

I pulled Burp Suite up and started doing this properly.

The Enumeration Game

Here is where the actual detective work begins.

I already had a baseline order ID from that Twitter screenshot — something like #DX976441. The tracking response told me this order had already been delivered. Delivered orders, as I'd find out, weren't interesting. But I wanted to find the live orders — the ones currently in transit, still sitting in someone's dispatch queue.

So I started changing the numbers.

DX100350 to DX200350. The API came back immediately: "Order with ID #DX200350 not found." Too high.

DX100350 to DX101000. Valid order. Delivered. Still not what I was looking for.

I kept nudging — bumping the thousands, then the hundreds — like tuning an old radio dial, hunting for the signal buried in the static. The API was cooperative, almost friendly about it. When an ID didn't exist, it said so plainly:

{
  "success": false,
  "errors": [{ "code": 400, "message": "Order with ID #DX1015500 not found" }]
}

When an ID did exist, it fired back a full, detailed response instantly. After a few minutes of probing, I had mapped the active range — the band of IDs corresponding to orders placed in the last few days that had not yet been delivered.

Live orders. Real people. Right now.

Two Responses. One Catastrophic Difference.

Once I understood the range, I noticed something critical about how the API handled active versus delivered orders.

For a delivered order, the response included a tracking URL pointing to GoKwik's standard shipment tracker:

"tracking_url": "https://api.gokwik.co/kwikship/track/21"

I opened it. Generic delivery status. No personal information visible. Fine.

For an active, undelivered order, the response returned something else entirely:

"tracking_url": "https://www.durexindia.com/72368/orders/f968cdaf9/authenticate?key=47f9d765b9"

This was a Shopify order authentication link. A pre-authenticated deep link that skipped the login page entirely and dropped you straight into the customer's private order confirmation.

I clicked one.

No login screen. No verification step. Just — a stranger's complete personal profile, laid out in front of me:

• Full name
• Email address
• Mobile phone number
• Complete billing address, street to PIN code
• Complete shipping address
• Every product they ordered — including the specific Durex items

I had gotten there by guessing a six-digit number.

The Scale Problem

Here is where "interesting bug" becomes "critical vulnerability."

Durex India was processing over 10,000 orders per day. Delivery windows stretched up to 10 days. Do the math: at any given moment, roughly 100,000 active orders were sitting in the system, each one fully queryable by anyone who could send a basic HTTP POST request.

To prove the point, I ran a simple script & Burp Suite's Intruder confirmed what I already suspected — sequential IDs, wall-to-wall 200 responses, row after row of active orders returning valid data. The script started logging order IDs and their corresponding Shopify authentication URLs, one after another:

61055481  DX109  https://www.durexindia.com/7236812858/orders/7c1a2e965d.../authenticate?key=...
61055499  DX109  https://www.durexindia.com/7236812858/orders/f1833a0f01.../authenticate?key=...
61055502  DX1094 https://www.durexindia.com/7236812858/orders/e0b6f9fc56.../authenticate?key=...

Each line was a real person, a real home address, a real purchase.

Now ask the harder question: how long had this been running?

If this flaw existed for even six months at that order volume, we are talking about potentially millions of customer records that a patient attacker could have silently scraped. And this is not a stationery shop. These are intimate wellness and sexual health products. The privacy expectations here are not incidental — they are the entire point. People who buy these products deserve to know their information is not sitting behind a guessable number and a missing auth check.

What Actually Went Wrong

There was no complex exploit here. No zero-day. No clever chain of vulnerabilities. This was textbook IDOR — Insecure Direct Object Reference, sitting squarely under OWASP A01:2021: Broken Access Control.

The API had no server-side authorization at all. It accepted any store_id and order_id combination from any origin, with no check that the person making the request actually owned the order they were asking about.

The root cause traces to a single configuration choice in the getmanifest.ai chatbot platform. The platform gives merchants three options for order tracking:

Option Method Security 1 Email + Verification Code Secure 2 Single Detail — Email or Phone or Order ID Insecure (Default) 3 Email or Phone + Order ID Reasonably secure

Durex India was running on Option 2. The default. The weakest one. It lets any person, anywhere, with any guessed order ID pull up a stranger's complete order details without proving they are who they claim to be. One dropdown. One configuration change. That is the full distance between this vulnerability and not having it.

Responsible Disclosure, and the Sound of Nothing

I compiled a detailed report — endpoint, request structure, full impact assessment, specific remediation steps — and sent it to the Durex India and Reckitt Privacy Office security contacts.

Then I waited.

One week. Two weeks. A month.

Not a single word back. No acknowledgement, no automated reply, not even an out-of-office. The vulnerability remained live. Every day of inaction was another 10,000 customers added to the exposure window.

One Email to CERT-In. Fixed in 24 Hours.

After months of corporate silence, I escalated.

I sent a formal report — subject line: "CRITICAL — Unauthenticated PII Leakage Vulnerability in Durex India Website Affecting Indian Customers" — to CERT-In (Indian Computer Emergency Response Team) and NCIIPC (National Critical Information Infrastructure Protection Centre), with Durex India and the Reckitt Privacy Office in CC.

The vulnerability was fixed within 24 hours.

No public statement. No email to me. No acknowledgement that a report had ever been filed. The same silence that had ignored me for months quietly cleaned up the mess, now that a government body was watching.

The Bigger Picture

This is not a story about one brand making one mistake. It is a pattern.

India's corporate security culture runs on what I would call Security Theater. Companies commission VAPT audits from CERT-IN empanelled firms and collect clean certificates. Compliance boxes get ticked. Boardrooms look at green dashboards. And then their production systems run third-party chatbots with default configurations that expose customer data to unauthenticated enumeration, and nobody finds out until a researcher stumbles across it in a Twitter rabbit hole.

An IDOR like this — unauthenticated, fully automated, operating at scale against a platform processing millions of orders — is the kind of issue a junior penetration tester catches in hour one. That it sat live long enough for me to find it this way suggests the audit never looked here.

CERT-In's escalation path works, as this case shows. But the fact that looping in a government regulator was the only thing that moved a billion-dollar company to patch a critical consumer data leak says everything about where the real problem lies.

For companies: Sequential, guessable IDs on unauthenticated API endpoints are a liability waiting to be discovered. Server-side authorization is not optional. Validate that the requesting session owns the resource it is asking for.

For vendors: Stop shipping the least secure option as the default configuration. Your customers' misconfiguration is your liability too.

For researchers: Do not let corporations wait you out when real user data is actively at risk. National escalation paths exist for exactly this reason. Use them.

For everyone else: The next time you order something from a major e-commerce brand, your name, address, phone number, and purchase history may be sitting behind nothing more than a guessable number and a missing auth check. Start asking questions.

Thanks for Reading

This one was a simple vulnerability. A misconfigured dropdown, a sequential order ID, and a missing auth check — that is the entire technical story. But the impact was anything but simple. Hundreds of thousands of records, fully exposed, on a platform selling products people buy with the expectation of complete discretion.

If you found this writeup useful or educational, the best thing you can do is share it. Post it on LinkedIn, discuss it on X, send it to your dev or security team internally. The more the industry talks about these real-world misconfigurations — not theoretical attack chains, but actual bugs in production systems — the harder it becomes to dismiss them as edge cases.

I am always happy to connect with researchers, developers, and security professionals. If you have questions about this research or just want to talk shop, find me here:

• Connect on LinkedIn: Mayur Pandya
• Follow me on X (Twitter): @pandyaMayur11