If you have already read my previous post, you know how a forgotten QA environment led to an $800 bounty. But the story didn’t end there. In the world of cyber-security, a “fix” isn’t always a “solution.”

This bug report in Hackerone is still in “Triaged” state, but since i know that they have now denied access to QA page for the public, I am writing about this report.

Three months after my first report was resolved, I went back to the same QA environment. What I found taught me a valuable lesson: Always retest, even when the bug is marked “Resolved.”

The “Incomplete” Fix

When the initial vulnerability was closed, the organization had secured the specific endpoints I reported. However, the root cause — the lack of universal access control on the QA server — remained.

While the original documents were now protected, I discovered that a whole new set of sensitive files were sitting wide open.

Part 2: New Data, Same Door

While pivoting through the QA sub-domain (data-qa.np.targetcorp.com), I noticed that the "ESG ****" and "Multi ****" sections were still serving live, restricted files.

By simply visiting the QA versions of these pages, I could download:

• xxx.csv: Daily index composition data.
• abc.csv: High-value premium index data.
• Forecast Files: Proprietary biomedical and global tech indices.

Refer below images for your reference

These weren’t just test files; they contained sensitive financial columns like Shares, Weights, Free Float, and Cash Dividend Amounts — data that is strictly reserved for high-paying licensed customers.

The Impact: Live Financial Benchmarks

Because this data serves as a primary benchmark for the stock market, unauthorized access is a serious revenue risk. Investors and professionals pay for this accuracy; if it’s available for free on a QA site, the business model is compromised.

The Negotiated Bounty: Duplicate or Valid?

This is where the story gets interesting. After reporting this second wave of documents, the triage team initially viewed it as a duplicate of my first report because the root cause (QA misconfiguration) was the same.

I argued that since the original remediation was clearly incomplete and entirely new, distinct datasets were exposed, it should be treated as a new finding.

The team agreed. Because not all remediation steps were applied the first time, they accepted the report as valid. While not the full original bounty, they awarded a $500 reward for the catch.

Why You Should Always Double-Back

1. Remediation is Hard: Developers often patch the specific “symptom” (the link you found) rather than the “disease” (the server-wide configuration).
2. Scope Expansion: As companies update their QA environments with new projects, new vulnerabilities can appear in old places.
3. Persistence Pays: My total bounty for this one QA environment grew to $1,300 simply because I didn’t stop after the first “Resolved” status.