How I Was Able to Create an Account on Any Third Party Application Using an Acronis-owned Email…

In this write-up, I am going to share an interesting Ticket Trick vulnerability that I found on an Acronis asset. The bug allowed me to create accounts on third-party platforms such as GitHub using Acronis-owned email addresses without actually having access to those email inboxes.

When I first saw it working, I had to double-check everything because it looked too good to be true (:

What is Ticket Trick?

For those who are not familiar with Ticket Trick attacks, many organizations use helpdesk or support systems where emails sent to specific addresses automatically create support tickets.

For example:

support@company.com

help@company.com

feedback@company.com

Whenever someone sends an email to these addresses, a ticket gets created and the content of the email becomes visible inside the ticketing system.

Now imagine if an attacker could register an account on that ticketing system using someone else's email address and then read all the tickets generated for those support mailboxes.

Sounds interesting right ?

While testing an Acronis asset, I discovered exactly that.

Discovery

One day I was hunting on Acronis' HackerOne public program so while doing a subdomain enumeration I came across the following asset:

exceed(.)acronis(.)dev

The application was using a helpdesk/ticketing platform where users could register their own accounts.

While exploring the registration functionality, I noticed something interesting.

The application was allowing me to register accounts using any email address without verifying ownership of that email.

At that moment, a thought came to my mind:

"What if I register using an email address that I don't actually own?"

And that's where things became interesting. (:

The Test

To verify my assumption, I created an account on the ticketing system using:

noreply@github.com

Yes, GitHub's email address.

The registration was successful.

No verification email.

No ownership validation.

Nothing.

The system simply accepted the email address and created the account.

At this point I knew there was a possibility of a Ticket Trick vulnerability, but I still needed a way to prove it.

The Attack

I noticed two email addresses that were being used by the platform:

• feedback@exceed.acronis.dev
• request@exceed.acronis.dev

The ticketing system automatically generated tickets whenever emails were sent to these addresses.

So I decided to use GitHub as my proof of concept.

I started creating a new GitHub account using:

feedback@exceed.acronis.dev

GitHub sent a verification code to that email address.

Normally, I shouldn't have access to that code because I don't own the email address.

However, because the ticketing system automatically converted incoming emails into tickets, the GitHub verification email appeared inside the helpdesk portal.

And because I had already registered an account using noreply@github.com, I was able to view the email content from inside the ticket.

At that moment I had access to the GitHub verification code.

The attack worked perfectly.

Proof of Concept

Step 1

Register on the Acronis helpdesk portal using:

noreply@github.com

The application allows registration without email verification.

Step 2

Create a GitHub account using:

feedback@exceed.acronis.dev

Step 3

GitHub sends a verification code to the Acronis email address.

Step 4

The email automatically generates a ticket inside the helpdesk system.

Step 5

Log in to the previously created helpdesk account and open the generated ticket.

Step 6

Read the GitHub verification code from the ticket content.

Step 7

Use the verification code to complete GitHub account registration.

The result?

A fully functional GitHub account created using an Acronis-owned email address which may allow you to get access to the company's internal github.

Evidence

When the verification email arrived, the helpdesk portal displayed GitHub's verification message directly inside the generated ticket.

The screenshot below shows the GitHub launch code being exposed through the ticketing system.

After completing the registration process, I successfully gained control over a GitHub account whose primary email address was:

feedback@exceed.acronis.dev

Impact

An attacker could abuse this issue to create accounts on various third-party platforms using organizational email addresses.

Potential targets could include:

• GitHub
• Slack
• Atlassian
• Trello
• Notion
• Other SaaS platforms relying on email verification

Depending on the organization's setup, this could lead to:

• Creation of unauthorized accounts
• Impersonation of company-owned email addresses
• Abuse of trust relationships
• Access to services registered under company domains

Root Cause

The issue existed because of two security weaknesses:

Missing Email Verification

The ticketing platform allowed registration using arbitrary email addresses without validating ownership.

Automatic Ticket Creation

Incoming emails were automatically converted into tickets and exposed to users who should not have been able to view them.

Combining these two issues resulted in a classic Ticket Trick vulnerability.

Recommendation

To prevent this type of attack:

• Enforce email verification during account registration.
• Restrict visibility of generated tickets.
• Prevent untrusted users from registering using arbitrary email addresses.
• Carefully review workflows that automatically process incoming emails.

Final Thoughts

What made it interesting was that there was no complex exploitation involved.

No SQL Injection.

No XSS.

No SSRF.

Just a simple chain of small security weaknesses that eventually allowed me to create an account on thirdt party platforms using an Acronis-owned email address.

This is a good reminder that sometimes the most impactful bugs are hidden in business logic rather than technical vulnerabilities.

Hope you enjoyed this write-up.

Happy hunting! 🚀