Private Bug Bounty Experience— Tata Play Bug Bounty Program
A duplicate decision may settle a reward. It does not settle whether a reported vulnerability has been fixed.
On 13 October 2026, I reported several findings through Tata Play’s bug bounty program. Three were marked duplicate. I can accept that outcome if someone reported them first. What concerns me is what happened with one of those reports: an exposed Spring Boot Actuator management interface on a Tata Play subdomain.
I am withholding the hostname and reproduction details while the behavior I observed may still be present.
What I originally reported
At 15:00:45 IST on 13 October, an unauthenticated request to the Actuator index returned HTTP 200. Its response listed management links, including shutdown and refresh. A separate health response disclosed details about the application’s infrastructure. Other sensitive Actuator endpoints returned 403, so this was a partial exposure rather than unrestricted access to every management function.
My original report described the public index and health information. Tata Play’s published program rules prohibit denial of service testing, so I left that action untested in the original submission.
An Actuator index alone does not prove that every listed operation is callable without authentication. That distinction matters. But listing a shutdown operation on a public management interface was enough to merit a close review, particularly alongside the detailed health response. Spring Boot’s documentation describes shutdown as an operation that gracefully shuts down an application and recommends securing Actuator endpoints exposed to the public.
The confusing change in access
Later on 13 October, shortly after I submitted the report, a browser-style request to the same Actuator index returned HTTP 403 at 18:12:12 IST. The response identified an AWS load balancer. On24 October at 01:05:15 IST, a minimal request again returned HTTP 200 and listed the same management links.
That sequence raised questions, but it does not prove that Tata Play fixed the issue and then reversed the fix. The 403 request differed from the 200 requests in protocol and headers, and I cannot see their edge rules or deployment history. It could have been a temporary restriction, a rule matching that particular request, or a different routing decision. I can only report what the responses showed.
Get Shivang Tiwari’s stories in your inbox
Join Medium for free to get updates from this writer.
Why the duplicate label is not the point
Tata Play’s bug bounty FAQ says later reports of the same issue are duplicates and ineligible for a bounty. I do not know whether another researcher reported this first or whether Tata Play already knew about it internally. I am not asking readers to treat the duplicate decision as proof of bad faith.
The question is narrower and more important: what happens when a report marked duplicate still points to a live, consequential exposure? A duplicate status explains who may receive credit or a reward. It does not tell a researcher whether the underlying risk has been removed.
I would like Tata Play to review the new shutdown response, verify the management interface from an external network, and clarify the status of remediation through the reporting channel. Researchers need a way to add material evidence to a closed or duplicate case without having the security concern disappear behind a workflow label.
I am sharing the timeline because it illustrates a problem that extends beyond one program: triage decisions and remediation decisions are different. When a duplicate report contains credible evidence of an active risk, the right outcome is to track the risk until it is actually addressed.
Eventual question which arises is — “How long can an unresolved vulnerability remain “duplicate” before new evidence earns a fresh review?”
Though I will not be hunting anymore on this program as I know it’s a waste of my time; even if I find a vulnerability and they don’t have anyone else having reported it earlier — they could still just say it’s a duplicate and move on without responding to my follow-up e-mails.
At this point — Is it more valuable for me to find a vulnerability and just publicly post a blog/writeup and gain credibility rather than writing a curated report in the utmost formats?
This past week I saw so many new CVEs & exploits coming in for Technological stacks & providers like PHP, NodeJS, Railway, LiteLLM, eMudhra, etc. It got me flabbergasted & also glad — finally, one way or another these organizations around the world will realise the cost of cheap/for-granted security. It’s just an EC2 instance + Claude compromising your servers!
I know this is the gray area and a few people might disagree; but I know real bounty hunters would agree with the situation described as they msut’ve faced it in the past or even currently — the process-change is NEEDED. Happy hacking to the amazing humans behind the scenes, I hope those dupes are eventually paid off!
