- Status Closed
-
Assigned To
cbay - Private
Opened by monty099 - 27.01.2026
Last edited by cbay - 28.01.2026
FS#290 - Title: Critical Logic Flaws Leading to Billing Bypass and Mailbox Local-Part Takeover
Severity: Critical (P1)
—
Summary
The Alwaysdata system suffers from a logic flaw in verifying domain ownership and handling the domain identifier (domain_id) during mailbox modification. This flaw allows an attacker to use an internal system domain identifier (alwaysdata.net) to create unauthorized local-parts on the Alwaysdata domain itself. As a result, this behavior can be abused to create paid subscriptions without billing (Billing Bypass) and to pre-register local-parts and link them to future subscriptions, leading to control over the primary email address of the subscription.
This root flaw leads to privilege escalation and bypass of financial and email security mechanisms, posing a critical risk to the platform infrastructure as a whole.
—
Vulnerability #1 – Unauthorized Paid Subscription Creation (Billing Bypass)
Description:
An attacker can modify the mailbox update request and change the domain_id value to the one belonging to the system domain alwaysdata.net. After that, they can create a subscription account using the created local-part and choose any paid plan, and the subscription will be created successfully without requesting any payment method or billing verification. This results in a complete bypass of the subscription system and obtaining paid features for free.
Steps:
1. Create a regular domain inside the account.
2. Create a mailbox on this domain.
3. Intercept the mailbox modification request using Burp Suite.
4. Change domain_id to 1 and set any local-part.
5. Send the request → a mailbox named name@alwaysdata.net appears.
6. Go to the subscription creation page.
7. Enter the same name and choose any paid plan.
8. Observe that the subscription is created without requesting payment details.
Impact:
Billing bypass, privilege escalation, and unlimited resource consumption.
—
Vulnerability #2 – Mailbox Local-Part Takeover on alwaysdata.net
Description:
The same flaw allows an attacker to reserve an unlimited number of local-parts on the alwaysdata.net domain. When any legitimate user later creates a subscription using one of these local-parts as the name, the subscription is linked to the pre-registered mailbox, making the primary email address of the subscription under the attacker’s control.
Steps:
1. Perform steps 1–5 from the first vulnerability to create a mailbox on alwaysdata.net.
2. Wait for another user to create a subscription using the same name.
3. Observe that the primary email address of the subscription is linked to the mailbox owned by the attacker.
Impact:
Control over the primary subscription email, interception of sensitive messages, and unauthorized access.
Loading...
Available keyboard shortcuts
- Alt + ⇧ Shift + l Login Dialog / Logout
- Alt + ⇧ Shift + a Add new task
- Alt + ⇧ Shift + m My searches
- Alt + ⇧ Shift + t focus taskid search
Tasklist
- o open selected task
- j move cursor down
- k move cursor up
Task Details
- n Next task
- p Previous task
- Alt + ⇧ Shift + e ↵ Enter Edit this task
- Alt + ⇧ Shift + w watch task
- Alt + ⇧ Shift + y Close Task
Task Editing
- Alt + ⇧ Shift + s save task
Hello,
It was indeed possible to create additional alwaysdata.net mailboxes, which should not be possible. It has been fixed.
However, it causes no security issue or billing issue.
That's not true: creating an additional mailbox is unrelated to subscriptions or billing.
Kind regards,
Cyril
Hello,
I confirm that this issue is not limited to the ability to create an additional mailbox.
I can create an email address under your internal domain such as:
victim@alwaysdata.net and this address is registered within the system as a valid existing email.
When any user later creates a subscription with the name victim, the system automatically links this subscription to the already existing email victim@alwaysdata.net.
Since I am the one who created this email in advance, all subscription-related emails are delivered directly to me.
This gives me full control over the subscription’s primary email address.
Best regards,
The only domain you could attach additional mailboxes is alwaysdata.net, which is not a security issue as anyone can have its own alwaysdata.net mailbox anyway.
Subscription-related emails are sent to the email address the user specified during signup, NOT its @alwaysdata.net address.
Hi,
Owning a mailbox on alwaysdata.net is not the point.
The real issue is that I have control over the primary email associated with a subscription, which the subscription actually uses to manage its communications.
—
Regardless of the internal delivery method, in practice I control the mailbox tied to the subscription’s identity.
This gives me unauthorized access to a subscription’s communications and constitutes a real Mailbox Takeover at the subscription level.
Best regards,
Hello,
To clarify the impact once again:
An attacker can gain control over the primary email address of a subscription, which the user relies on to manage their subscription and its communications.
This means an attacker can access subscription communications belonging to other users.
This represents a real Mailbox Takeover at the subscription level, allowing an attacker to:
Have full access to incoming emails for that subscription
Control the mailbox associated with the subscription without authorization
This constitutes unauthorized access to a resource the attacker does not own.
Best regards,
Hello,
That's not true.
That's not true either.
Kind regards,
Cyril
Hello,
I have attached a PoC video demonstrating the behavior in practice:
From the first account, I created a mailbox with a specific name.
From another account, I created a subscription using the same name.
When accessing webmail.alwaysdata.net from the first account, I was able to access the mailbox associated with that subscription.
This proves that I control the mailbox of a subscription created by another user.
Please review the attached video.
POC: https://admin.alwaysdata.com/support/91794/
Best regards,
Your PoC doesn't show that the testw@alwaysdata.net belongs to the testw account, as it doesn't.
Hello,
Regarding your previous reply:
In practice, I fully control the mailbox that uses the same identifier as the subscription, and the legitimate subscription owner has no way to access or manage it.
This gives me exclusive ability to send and receive emails under this subscription identity.
This constitutes a Mailbox Takeover.
You can see the submitted proof of concept.
PoC: https://admin.alwaysdata.com/support/91794/
Best regards,
The "victim" account has NEVER owned that mailbox that you've created, so that's obviously not a takeover.
Hello,
A takeover does not require that the victim previously owned the mailbox.
The security issue is that a mailbox under the subscription identity is controllable by an external user.
A subscription is created with an identifier that is assumed by the system to represent that subscription’s email identity.
I am able to register and fully control a mailbox using that same identifier, while the legitimate subscription owner has no technical way to access or manage it.
This creates a situation where:
I control the only mailbox corresponding to a subscription created by another user
I can send and receive emails as that subscription
The legitimate owner cannot access or reclaim this mailbox
This is an identity/mailbox takeover scenario, regardless of who created the mailbox first.
POC: https://admin.alwaysdata.com/support/91794/
Best regards,
Hello,
I recorded a PoC video demonstrating a real bypass of the plan and billing enforcement.
To explain this in a structured manner, I compared two different accounts:
1. A Free plan account:
The plan information page shows a 1GB storage limit.
When attempting to create an additional site from the control panel, the system correctly blocks the action and displays a message stating that this feature is not available on the free plan and that an upgrade is required.
2. An account affected by the issue:
When accessing the plan information page, no storage limit or any indication of restrictions is displayed.
I was able to successfully create an additional site from the control panel without the system requesting a plan upgrade or adding a payment method.
I then checked the billing status of the affected account:
No payment method is added to the account.
No current or past invoices appear on the billing page.
The account was created more than two days ago.
Based on the platform’s normal behavior, when a paid account is created or paid features are activated, an invoice is generated within a short period (usually within one or two days).
Even after more than two days, no invoice has been generated and no payment request has appeared.
This confirms that the system is granting paid-plan capabilities without actually enforcing payment.
Please review the attached PoC video, which sequentially shows:
The free account being blocked from creating an additional site.
The affected account successfully creating a site without upgrade.
The plan information page showing no limits.
The billing page showing no invoices or payment requests.
This represents a serious flaw in the billing system and leads to direct financial loss for the platform.
If you need any additional clarification or further detailed steps, I will be happy to provide them.
POC: https://admin.alwaysdata.com/support/91794/
Best regards,
Which is NOT a security issue.
Hello,
Bypassing plan and billing enforcement is a security issue.
It allows an attacker to obtain paid features without authorization and without payment, which is an authorization and business logic flaw.
Such issues are commonly classified under security vulnerabilities in bug bounty programs as "Improper Authorization" or "Business Logic Abuse".
This behavior is exploitable, reproducible, and results in unauthorized access to restricted functionality.
Regards,
I'm afraid we disagree on the definition of security, and it's clearly out of scope of our own bug bounty program
Hello,
I understand your position. However, your bug bounty program scope includes authorization and access control issues.
This issue allows access to functionality restricted to paid plans, without authorization and without payment, which represents a clear authorization and business logic bypass.
Regardless of the financial impact, the core problem is unauthorized access to restricted features, which inherently falls under security vulnerabilities.
Best regards,
Hello,
I reviewed your bug bounty scope and did not find any exclusion for authorization or access control issues.
This report demonstrates unauthorized access to functionality restricted to paid plans, which falls under access control / authorization bypass.
Regards,
Our bug bounty program has a Qualifying vulnerabilities section, which explicitly lists what IS accepted, and financial impact is NOT listed, so NOT accepted.
Hello,
This report is not based on financial impact, but on an authorization and access control issue.
A non-authorized account can access features intended only for paid users due to improper enforcement of plan restrictions.
This falls clearly under the qualifying categories for authorization and access control in your bug bounty program.
Best regards,
Hello,
According to OWASP Top 10 – Broken Access Control, access control failures occur when users can perform actions outside of their intended permissions, including accessing functionality they should not have.
https://owasp.org/Top10/2025/A01_2025-Broken_Access_Control/
In this case, a non‑paid account is able to access features reserved for paid plans due to improper enforcement of plan restrictions, which directly matches this definition.
Therefore, this issue falls under Broken Access Control / Authorization.
Best regards,