- 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,