When “Known Issue” Becomes an Excuse: My Zerodha Bug Bounty Experience

I Reported Security Flaws to Zerodha. 79 Days Later, I Was Still Fighting for Answers.

Disclaimer: This article reflects my personal experience and correspondence between July and October 2026. All vulnerability reproduction details, report identifiers, sensitive technical information, and private communications have been intentionally excluded. The article does not allege confirmed exploitation, customer financial losses, or deliberate wrongdoing by Zerodha.

An account of how a bug bounty dispute turned into months of frustration, unanswered questions, and concerns about the safety of everyday traders.

I never thought I would end up writing something like this about Zerodha.

As a security researcher, my job is to find vulnerabilities before someone with bad intentions does. I spend hours understanding how applications work, testing their security, and documenting problems so companies can fix them.

I believe responsible disclosure should benefit everyone. The company learns about a security weakness, customers become safer, and the researcher gets recognized for the work.

At least, that's how it's supposed to work.

In July 2026, I discovered a serious security vulnerability affecting Zerodha's trading platform. I reported it through their official bug bounty program, managed by Com Olho.

The initial report was accepted, and I was rewarded.

I appreciated that. It made me feel that my research was being taken seriously.

But what happened over the following months completely changed how I viewed the program.

August 2026: When things started going wrong

After reporting the first vulnerability, I continued researching the application and discovered another way around its security protections.

I didn't want to waste anyone's time submitting something that would simply be considered a duplicate.

So, on August 6, 2026, I did what I thought was the responsible thing: I asked Zerodha whether I should submit the new finding separately.

They told me I could submit it and that their stakeholders would decide whether it qualified as a different report.

Fair enough.

I went ahead, completed my testing, prepared the evidence, and submitted the vulnerability on August 9.

Two days later, on August 11, it was rejected.

The reason was that Zerodha's team had supposedly already identified the issue internally.

Now, I understand that companies can discover vulnerabilities independently. I also understand that bug bounty programs don't have to reward every submission.

But my concern wasn't simply the rejection.

I had specifically explained why I believed this was a different technical problem from my earlier accepted report. What I wanted was a clear explanation of how their internal finding covered the same underlying issue.

Instead, I was left questioning whether the technical differences I had documented had received a meaningful review.

And that was only the beginning.

Two months later, the problem was still reproducible

This is where the story becomes more concerning, especially for people who actually use Zerodha.

On October 11, 2026, I returned to the application to check the security issue again.

To my surprise, I could still reproduce the same underlying weakness in the live production environment.

It had been approximately 63 days since my August submission.

Think about that for a moment.

I had reported the issue, received a rejection, and then returned more than two months later to find that the underlying behavior could still be reproduced.

I submitted additional evidence showing the impact I could demonstrate in the newer version of the application. I also reported another issue that I believed had an independent technical cause.

At this point, my concern wasn't only about the bounty anymore.

It was about the users.

Imagine being an ordinary Zerodha customer

Most people using Zerodha aren't cybersecurity experts.

They're students, working professionals, long-term investors, and everyday traders.

Some have years of savings invested through their accounts.

They open the app, check their holdings, place orders, and trust that the platform is protecting their information and access to their accounts.

They shouldn't have to think about what happens behind the scenes when a security researcher reports a vulnerability.

But that's exactly why the way these reports are handled matters.

The security weaknesses I reported raised concerns about unauthorized behavior within an authenticated user's session.

Depending on the circumstances and other security controls, that kind of weakness can create risks involving account information or actions performed in a user's session.

But my testing demonstrated a security concern that I believed deserved timely remediation.

And as someone who also looks at this from a customer's perspective, that worried me.

October 23: Rejected again, despite the remediation questions

On October 23, 2026, the later reports were rejected as internal duplicates.

What made this particularly frustrating was that, in its response concerning one of the issues, Zerodha indicated that a fix had been tested internally but had not yet been pushed to production.

That left me with an uncomfortable question.

If the issue was already known internally, why was I still able to reproduce the underlying weakness in production more than two months after reporting it?

There may have been valid technical or operational reasons for the delay. Production changes require testing, and I understand that security fixes can take time.

But that makes communication even more important.

Later that same day, I tested again and observed that the previously vulnerable behavior appeared to have changed.

It looked as though remediation might have reached the live application.

I immediately informed Com Olho.

However, I still didn't have a confirmed deployment timeline or a satisfactory explanation of how the separate findings had been evaluated.

I couldn't independently establish exactly when the fix was deployed or whether every related issue had been completely resolved.

What I could establish was that I had been reporting, retesting, and questioning these issues for weeks.

And the process had become exhausting.

The part of bug bounty hunting nobody talks about

People outside this field often imagine bug bounty hunting as finding a bug, submitting a report, and getting paid.

They don't see the other side.

The hours spent reproducing an issue consistently.

The evidence you have to collect.

The explanations you write so someone else can understand exactly what you discovered.

And then, sometimes, the additional hours spent trying to explain why your report shouldn't have been dismissed.

That's what happened to me.

Instead of moving on to new research, I found myself revisiting old submissions, comparing technical findings, checking the application again, and preparing a detailed appeal.

On October 23, I formally requested an independent review from Com Olho.

I wasn't demanding multiple rewards for variations of the same issue. I explicitly acknowledged where my later findings shared the same underlying cause.

All I wanted was a fair comparison of the issues I believed were different, proper credit for the earliest relevant submission, and a clear explanation of the final decisions.

On October 24, I followed up again.

By then, it had been 79 days since I first asked Zerodha whether I should submit the additional finding.

Seventy-nine days.

And I was still trying to get the core questions resolved.

It's difficult to explain how discouraging that can be.

You start out trying to help secure a platform. Eventually, you find yourself spending more time defending the validity of your work than doing the research you enjoy.

For an independent researcher, time is a limited resource. Every day spent chasing an unresolved decision is a day that could have gone into discovering something new.

And over time, that affects your willingness to trust the process.

What bothered me more than the money

I know how this might look from the outside.

Someone might say, "You already got paid for the first bug. Why are you complaining?"

Because this isn't simply about getting another reward.

My original finding was accepted and rewarded. I have never denied that.

The problem was how the subsequent reports were handled.

A company has every right to reject a duplicate vulnerability. If an issue was genuinely identified internally before my submission, that's a legitimate reason to consider when determining eligibility.

But I believe a researcher should be able to challenge that decision and receive a technical explanation that addresses the actual evidence.

Being told something is already known doesn't explain whether the earlier finding covered the exact same problem.

And when the reported issue remains reproducible in production weeks later, the conversation should also address what is being done to protect customers.

A report being closed does not necessarily mean the underlying security risk has been resolved.

Those are two different things.

For researchers, the concern is fair treatment.

For customers, the concern is whether the platform is secure.

Both deserve serious attention.

Why I'm making this public

I'm not writing this to accuse Zerodha of deliberately putting customers in danger or intentionally avoiding payments. I don't have evidence to establish either claim.

I'm writing this because I believe my experience raises important questions about transparency, accountability, and how security researchers are treated when they disagree with a company's decisions.

I followed the official disclosure process.

I asked for guidance before submitting a follow-up.

I provided supporting evidence.

I continued testing.

I requested an independent review rather than simply making accusations.

And after nearly eleven weeks of back-and-forth, I was still asking for a clear explanation.

I also wanted to know when the reported risk had actually been fixed in production.

As a researcher, I lost time and confidence in the process.

As someone concerned about the people using this financial platform, I found the unresolved security questions even more troubling.

Security researchers shouldn't have to fight for transparency, and customers shouldn't have to wonder whether reported vulnerabilities are being addressed.

I hope Zerodha and Com Olho take these concerns seriously.

Not just for me, but for every independent researcher who puts in the time to help protect their users.

Because once researchers stop trusting the process, everyone stands to lose.

And the people who have the most to lose may be the customers who never knew about the vulnerability in the first place.