Before starting with the blog, i would like to introduce myself a bit. My name is Gopi and i hold a Bachelors degree in Mechanical engineering and a Masters degree in Automotive systems engineering. I also have a couple years of working experience as a supply quality engineer. Its a long story why i shifted my career path to cyber security and i will keep this to a different blog in the future. By the way this is my first bounty for a bug in hacker one.

Now moving on to the bug.

Most bug hunters spend their time poking at production environments, trying to bypass hardened login screens or find complex injection points. But sometimes, the most impactful vulnerabilities aren’t hidden behind a zero-day exploit — they are sitting in plain sight on a sub-domain that everyone forgot to lock down.

In this post, I’ll walk through how I accessed restricted financial documents on a major stock exchange platform by simply looking where the public wasn’t supposed to be watching.

The Discovery: Production vs. QA

While exploring a financial data platform (let’s call it TargetCorp), I noticed a clear distinction between free and licensed tiers.

Production (data.targetcorp.com): High-value documents, such as "Equity Index Selection Lists," were strictly restricted. Clicking them prompted a "licensed users only" warning.

The QA Environment: I pivoted to a non-production sub-domain I discovered during recon: data-qa.np.targetcorp.com.

Initially the QA page looked almost similar to the production environment, It had the same layout, same subdomains, etc. But then after looking closely, i noticed that some documents(5 documents in total) that were locked on the main site were fully downloadable on the QA site without any authentication. As you can see from the attached images, QA environment allowed to download a document in the first page. After navigating through the remaining pages in the QA environment, i discovered 4 more such documents.

Proof of Concept (PoC)

The vulnerability was a classic case of lack of access control on a mirrored environment. By navigating to the index adjustment sections on the QA site, I could download:

• Equity index selection lists.
• ESG factor annual files.
• Current index composition and divisor data.

The “Aha!” Moment:

Initially, one might assume a QA site only contains old or “dummy” data. However, I monitored the files for five days and noticed something critical: The data was updating in real-time.

I was able to read internal update messages and see corporate action descriptions within the .csv files that were current for that specific trading day. This transformed the bug from a simple "misconfiguration" into a live data leak of proprietary information.

The Scope Debate: Is QA “In Scope”?

After reporting the issue via the bug bounty platform, there was a brief discussion regarding scope. The triage team initially noted that the QA environment wasn’t “officially” listed in the main scope, which focused on production systems. This was really frustrating for me as this was my first report that was accepted by the internal team and it was already two months into reporting.

But, I countered with two main points:

1. The CIDR Range: The QA domain lived within the IP range explicitly listed as “In Scope.”
2. Data Impact: The QA site was leaking the exact same proprietary data that the company charges customers to access.

The Result: The team agreed. They acknowledged the risk to their revenue and proprietary data, triaged the report, and promptly fixed the access control.

Key Takeaways for Hunters and Devs

• For Hunters: Always check sub-domains like qa.*, dev.*, or staging.*. If they pull from the same database or file storage as production, they might be missing the production-grade security layers.
• For Companies: If an environment contains production data, it is production. Secure your QA environments with the same rigor as your main site, or use strictly “dummy” data.