The Victim Paid. The Attacker Used Their Subscription.

I hunt for the small mistakes that turn into big security problems.

Here's one of them. 👇

While testing example.com, I found an API responsible for creating websites that accepted a client-controlled subscription_id.

The first thing I noticed was that my subscription was limited to one website.

So I started testing whether that restriction could be bypassed.

The First Impact — P3

The request looked like:

POST /api/hosting/instances
Host: my.example.com

{"subscription_id":"ATTACKER_SUB"}

POST /api/hosting/instances
Host: my.example.com

{"subscription_id":"ATTACKER_SUB"}

The subscription IDs also followed a predictable format:

A-S02991817
A-S02991818
A-S02991819

A-S02991817
A-S02991818
A-S02991819

I changed the subscription_id and found that I could use another subscription ID to create additional websites, bypassing the one-website limitation of my own subscription.

That was already an authorization issue, and the report was initially classified as P3.

But I wasn't satisfied with that impact.

I asked myself:

If I can use another subscription ID, what happens if that subscription belongs to another user?

That's where things got interesting.

The Bigger Impact

I tested with two accounts:

• Attacker — my account
• Victim — an account with a paid subscription

I replaced my subscription ID with the victim's:

{"subscription_id":"VICTIM_SUB"}

{"subscription_id":"VICTIM_SUB"}

The request was accepted.

No ownership validation.

No authorization error.

The backend simply trusted the supplied subscription ID.

At this point, the impact was no longer just:

"I can create more websites than my subscription allows."

It became:

"I can use a subscription that another customer paid for."

The victim paid for the subscription.

The attacker used it.

And because the resource was now being consumed by the attacker, the victim could no longer use their own paid resource as intended.

💀

P3 → P2

This was the most important part of the investigation.

The initial finding was about bypassing the one-website limitation, which resulted in P3.

But by going back to the same authorization flaw and testing a victim's subscription ID, I discovered a much more serious impact:

Unauthorized use of another customer's paid subscription.

The issue wasn't simply that I could create additional websites.

The real problem was:

The victim paid. The attacker benefited.

After clarifying this business impact, the severity was raised from P3 to P2.

The Lesson

This was a good reminder that finding the vulnerability is only half the job.

When you discover an IDOR, don't stop at the first impact you find.

Ask:

"What else can this identifier give me access to?"

In this case, the first answer was:

More websites.

The second — and much more important — answer was:

Someone else's paid subscription.

The victim paid. The attacker used it.

— el7xoot