When “Typically Identical to Production” Isn’t Enough

We win some. We lose some.

Every bug bounty hunter eventually discovers that finding a vulnerability and proving its impact are not always enough to achieve the outcome they expect.

Reading the Scope

Before touching any target, I make it a habit to read the scope from top to bottom.

Most researchers skim this section.

I don't.

Scope often tells you more about a target than the target itself.

In this case, one particular statement stood out:

"Avoid testing on production; testnet is typically identical to the production environment and simplifies testing."

That sentence would eventually become the title of this article.

At the time, however, it simply told me where to spend my energy.

The program was effectively saying:

Don't test production.
Use Testnet instead.
The environments are generally aligned.

So that's exactly what I did.

I registered an account, completed the onboarding process, and began exploring account lifecycle functionality.

I wasn't hunting for account takeover.

I wasn't looking for unauthorized asset movement.

I wasn't trying to find a Critical vulnerability.

I was simply exploring how identities were created, linked, and managed throughout the platform.

As it turned out, that curiosity led somewhere unexpected.

The First Oddity

Like most logic flaws, this one didn't announce itself as a vulnerability.

There were no stack traces.

No exposed admin panels.

No forgotten debug endpoints.

In fact, the behavior initially looked almost harmless.

While exploring account-management functionality on the platform's Testnet environment, I came across an endpoint responsible for creating what appeared to be independent subaccounts.

At first glance, everything looked normal. The request required authentication, accepted user-supplied account details, and returned a successful response.

What caught my attention wasn't what the endpoint did.

It was what it didn't do.

Specifically, it never appeared to verify ownership of the email address being associated with the newly created account.

That immediately raised a simple question:

What happens if I supply an email address that doesn't belong to me?

Using researcher-controlled accounts and researcher-controlled email addresses, I began testing different registration scenarios.

The results were consistent.

The platform allowed an authenticated user to create an account relationship using an email address that had never been verified.

No confirmation email.

No ownership challenge.

No proof that the person creating the account actually controlled the supplied address.

In practical terms, this meant a user could reserve, or more accurately, pre-bind an email address before its legitimate owner ever interacted with the platform.

At this point, I wasn't thinking about asset transfers or account takeover.

I was thinking about account lifecycle management.

The behavior was unusual, but unusual does not automatically mean vulnerable.

So I documented the finding and submitted a report.

The report described what I believed to be an identity-binding weakness: the platform was willing to establish account relationships before establishing ownership of the identity being linked.

After review, the report was closed as Informative.

And honestly, I could understand the reasoning.

At that stage, I had demonstrated an interesting behavior.

What I had not demonstrated was meaningful impact.

No user data had been accessed.

No assets had been moved.

No existing account had been compromised.

From a bug bounty perspective, impact is often the difference between a curiosity and a vulnerability.

For most researchers, that's where the story would have ended.

For me, it wasn't.

Because one question kept bothering me:

What happens when the legitimate owner of that email address eventually shows up?

Curiosity Got the Better of Me

That question stayed with me longer than I expected.

The original report had been closed, and from a bug bounty perspective the case was effectively over.

But the behavior still felt incomplete.

The platform had allowed me to establish an account relationship using an email address I did not control.

What I didn't know was how the system would behave once the legitimate owner of that email address eventually entered the picture.

Would the account relationship be discarded?

Would ownership be reassigned?

Would the original linkage be revoked?

There was only one way to find out.

Using researcher-owned accounts and researcher-controlled email addresses, I recreated the entire lifecycle from the beginning.

First, I created a parent account.

Next, I used the functionality I had previously reported to create an independent subaccount tied to an email address that had not yet been registered.

At this stage, everything behaved exactly as before.

The email address was accepted.

The account relationship was created.

The subaccount existed beneath the parent account hierarchy.

Then I switched perspectives.

Instead of acting as the attacker, I became the future account owner.

Using the same email address that had already been associated with the subaccount, I attempted to register as a legitimate user.

What happened next was unexpected.

The platform did not create a completely new account.

Instead, after completing the recovery and registration process, I was successfully authenticated into what appeared to be the same underlying account object.

On the surface, everything looked normal.

The email address belonged to me.

I could log in successfully.

The account appeared legitimate.

If I had stopped testing there, I probably would have assumed the ownership issue had resolved itself.

It hadn't.

Because when I returned to the original parent account, something important was still there.

The relationship I expected to disappear had survived.

The account that was now being used by the legitimate email owner still appeared to exist beneath the hierarchy of the original creator.

At first, I thought I had made a mistake.

So I repeated the process.

Then I repeated it again.

The result remained consistent.

The same account appeared to be accessible from two completely different trust relationships.

One through legitimate authentication.

The other through a previously established account hierarchy.

And that's when I stopped thinking about registration.

I started thinking about authorization.

One Account, Two Controllers?

At this point, I wasn't looking at a registration problem anymore.

I was looking at an ownership problem.

The legitimate user could authenticate normally.

The email address belonged to them.

The password belonged to them.

Any email verification challenges would be sent to them.

From the user's perspective, they owned the account.

But from the platform's perspective, something else appeared to remain true.

The account still seemed to retain the hierarchical relationship established before the legitimate owner ever registered.

In other words, two independent trust relationships appeared to coexist.

One was based on identity ownership.

The other was based on historical account hierarchy.

That distinction matters.

A lot.

Because authentication answers the question:

Who are you?

Authorization answers a completely different question:

What are you allowed to do?

The more I examined the behavior, the less interested I became in the login process itself.

The legitimate owner could clearly log in.

That wasn't the issue.

The question was whether the original creator still possessed authority over an account that was now being actively used by someone else.

To answer that, I began testing the permissions that naturally existed between parent accounts and their associated subaccounts.

I wanted to understand whether the relationship was merely cosmetic or whether it carried real operational privileges.

If the hierarchy was only a visual artifact, the issue would likely remain informational.

If the hierarchy still granted authority, however, the implications would be very different.

So I started examining what actions could be performed through that relationship.

What information could be viewed?

What settings could be managed?

What account operations remained available?

And eventually, one particular capability stood out from the rest.

Asset transfers.

That's when the finding stopped looking like an account-lifecycle inconsistency and started looking like a security boundary failure.

The question was no longer whether the relationship existed.

The question was whether that relationship could be abused.

There was only one way to find out.

Following the Money

Security researchers often talk about "impact."

But impact isn't something you assume.

It's something you demonstrate.

At this point, I believed I had discovered an unusual account state.

The legitimate owner could authenticate normally.

The original creator appeared to retain hierarchical authority.

What I still didn't know was whether that relationship actually mattered.

So I started looking for actions that depended on trust between parent accounts and their associated subaccounts.

One operation immediately stood out.

Internal asset transfers.

Like many platforms that support account hierarchies, transfers between related accounts were treated as trusted actions.

The assumption made sense.

If both accounts belong to the same owner, additional friction would only create inconvenience.

The problem, of course, is that my testing suggested ownership might not be as straightforward as the platform assumed.

To evaluate the impact safely, I continued using researcher-controlled accounts within the designated testing environment.

Using the platform's faucet functionality, fund the account associated with the email address that had previously been pre-bound using the testnet fund.

The account now held a balance.

The next step was simple.

I returned to the original parent account and attempted an internal transfer.

I expected one of two outcomes.

Either the transfer would fail because ownership had been reassigned during registration.

Or the platform would require additional verification before allowing assets to move.

Neither happened.

The transfer succeeded.

Immediately.

No secondary confirmation.

No email challenge.

No ownership revalidation.

No indication that the account relationship had changed after the legitimate user completed registration.

The platform continued to treat the account as a trusted subordinate entity.

From a technical perspective, this was the moment the finding changed categories in my mind.

I was no longer looking at email squatting.

I was no longer looking at registration behavior.

I was looking at a scenario where an account authenticated and operated by one user could still be acted upon through a relationship established earlier by another.

To be clear, this demonstration involved researcher-controlled accounts and testnet assets only.

No third-party accounts were accessed.

No production systems were tested.

But the security question was difficult to ignore:

If ownership can change while authority remains behind, who actually owns the account?

And if trusted account relationships survive that ownership transition, what prevents those relationships from being abused?

At that point, I stopped treating the finding as an extension of the original report.

It had become something else entirely.

So I opened a new report.

The Second Report

At this point, I wasn't looking at the same finding I had reported previously.

The original report focused on identity binding.

This one focused on what that identity-binding issue appeared to enable.

That distinction mattered.

A lot.

The first report demonstrated that an email address could be associated with an account before ownership was verified.

The second report demonstrated what happened when that ownership conflict persisted into account operations.

From my perspective, the difference was the presence of impact.

I now had a reproducible scenario involving:

Pre-binding an email address before registration.
A legitimate user subsequently authenticating into that account.
Persistence of the original account hierarchy.
Successful asset transfers through that hierarchy.

In other words, I wasn't arguing that the first report should be reconsidered.

I was arguing that I had discovered something new.

Something that appeared to move beyond account lifecycle behavior and into authorization territory.

So I documented everything.

The registration flow.

The account relationships.

The ownership transition.

The transfer behavior.

The screenshots.

The timelines.

And I submitted a new report.

To the program's credit, the report quickly passed initial triage and moved forward for validation.

That was encouraging.

For a brief moment, I thought I had finally connected the missing piece.

The original report had lacked impact.

This one demonstrated it.

Or at least I believed it did.

A few days later, however, a question arrived from the reviewing analyst.

The team wanted clarification on one thing:

How does an attacker actually benefit from this behavior?

It's a fair question.

In bug bounty programs, unusual behavior alone rarely matters.

The value of a finding is determined by what an attacker can realistically do with it.

So I responded with the most detailed explanation I could provide.

I explained the persistence of the ownership relationship.

I explained how a legitimate user could inherit an account while a previous authority remained behind.

I explained the transfer capability.

And I explained why I believed the issue represented more than simple account confusion.

Then I waited.

And eventually, the response arrived.

The Closure

The final response was brief.

After reviewing the report and the additional impact explanation, the program concluded that the behavior did not appear to result in significant security impact.

The report was closed as Informative.

That was it.

No severity downgrade.

No indication that the ownership condition was intended.

No explanation that the transfer behavior was expected.

No statement that the account relationship was functioning as designed.

Simply:

No significant security impact.

To be clear, programs have every right to make that determination.

Not every unusual behavior is a vulnerability.

Not every vulnerability qualifies for a bounty.

And not every researcher will agree with every assessment.

That's part of bug bounty hunting.

What made this particular closure memorable wasn't the outcome.

It was the absence of a technical explanation.

Because from my perspective, several questions remained unanswered.

If the observed behavior was expected, what was the intended ownership model?

If the account hierarchy was functioning correctly, why did authority appear to survive an ownership transition?

If the transfer capability was not security-relevant, what aspect of the demonstrated chain made it insufficient as an impact scenario?

Those were the questions I hoped to understand.

Not because I wanted the report reopened.

Not because I wanted to argue.

But because every closure is an opportunity to learn.

A good explanation helps researchers refine their threat models.

It helps them understand where their reasoning diverged from the program's reasoning.

And ultimately, it makes future reports better.

So I followed up.

Politely.

I asked whether the determining factor was:

The Testnet environment.
The absence of a confirmed production path.
Or an assessment that the behavior was acceptable by design.

I also requested guidance regarding responsible disclosure.

The response never came.

At least not the one I was hoping for.

And that's when the report stopped being about a vulnerability.

It became about understanding the gap between two different interpretations of risk.

The Question Nobody Answered

At this point, the report was closed.

For many researchers, that's where the story ends.

Accept the outcome.

Archive the report.

Move on to the next target.

Normally, that's exactly what I would have done.

But this time, something continued to bother me.

Not the closure.

The explanation.

Or more accurately, the lack of one.

The final assessment stated that the demonstrated behavior did not result in significant security impact.

That's a perfectly valid conclusion for a program to reach.

What I struggled with was understanding how it had been reached.

I wasn't looking for a bounty negotiation.

I wasn't asking for a severity increase.

I wasn't demanding the report be reopened.

I simply wanted to understand the reasoning.

So I asked.

Was the determining factor the Testnet environment?

Was the issue considered acceptable by design?

Was there an assumption that the behavior could not exist in production?

Or was there another aspect of the ownership chain that I had misunderstood entirely?

Those questions never received a direct answer.

Instead, the report remained closed.

Weeks passed.

Then months.

I submitted a disclosure request.

I followed up.

I requested clarification.

Eventually, I requested mediation.

Not because I expected the outcome to change.

But because independent review sometimes helps identify blind spots.

Maybe I had missed something.

Maybe the program had.

Maybe there was simply a difference in how risk was being evaluated.

The mediation request outlined the same question that had been bothering me since the closure:

If a legitimate user can authenticate into an account while a previously established authority relationship continues to exist, what security property is being preserved?

Account ownership?

Authorization?

Neither?

I wasn't looking for someone to declare me right.

I was looking for someone to explain where my reasoning broke down.

That explanation never arrived.

And strangely enough, that's what made the report memorable.

Not the finding.

Not the closure.

The uncertainty.

Because as researchers, we learn just as much from the reports we lose as the reports we win.

Sometimes more.

What I Learned

Looking back, I still don't know whether the program's assessment was ultimately right or wrong.

And that's okay.

Bug bounty programs and researchers don't always view risk through the same lens.

Researchers tend to ask:

"What can this behavior become?"

Programs tend to ask:

"What can be demonstrated today?"

Somewhere between those two perspectives lives the reality.

What this experience taught me is that technical findings and accepted impact are not always the same thing.

A vulnerability can be real.

A proof of concept can work.

A security boundary can appear broken.

And a program can still conclude that the resulting risk is insufficient for a reward.

That's part of the process.

It also reinforced something else.

Scope matters.

Program expectations matter.

Threat models matter.

And perhaps most importantly, communication matters.

A detailed explanation of why a report is accepted can help a researcher improve.

A detailed explanation of why a report is rejected can be just as valuable.

Because every report represents a learning opportunity for both sides.

The reports that get rewarded teach us how systems fail.

The reports that get closed teach us how programs think.

This one happened to teach me both.

Would I report it again?

Absolutely.

Not because I know how the outcome would unfold.

But because I still believe that account ownership should be exclusive, authorization boundaries should remain consistent, and security questions are worth asking even when the answers aren't obvious.

As for the report itself, it now sits alongside countless others in bug bounty history.

Closed.

Archived.

Resolved, at least administratively.

But every so often, I still find myself thinking about that original statement in the scope:

"Testnet is typically identical to production."

And I wonder whether the most interesting part of this story was ever the vulnerability at all.

Or whether it was the lesson hidden inside the disagreement.

After all, that's bug bounty hunting.

We win some.

We lose some.

And sometimes, the reports we lose are the ones we remember the longest.

About the Author

Paul Haykeens Ethical Hacker | Security Researcher

I spend most of my time breaking things that are supposed to work, documenting why they don't, and occasionally discovering that finding a bug and proving its impact are two very different challenges.

The reports that get rewarded teach you how systems fail.

The reports that get closed teach you how people think.

Sometimes those lessons are worth more than the bounty.

Thank you for reading all the way to the end.

This report was submitted in December 2025.

The disclosure request followed.

The mediation request followed.

Months passed.

The status never changed.

But that's not why I wrote this article.

I wrote it because security research isn't just about vulnerabilities — it is about questions.

Sometimes you find the bug.

Sometimes you find the impact.

And sometimes you spend months trying to understand why nobody else sees the same thing you do.

Whether you agree with my assessment, the program's assessment, or somewhere in between, I hope this story offered something valuable about the often-overlooked gap between discovery, impact, and interpretation.