All Projects

Description

There is a flaw in permission management within Alwaysdata’s Mailing system that allows the Owner role to remain associated with an old user identity even after the email address is modified, the user is deleted, and the domain is transferred to another account. This results in an attacker being able to retain full control over a Mailing instance linked to a domain that is now owned by the victim.

—

Steps to Reproduce

1. The attacker creates an Alwaysdata account (Account A).

2. Creates a Domain within the account and then creates a Mailing associated with this domain.

3. Creates an email user such as: a@example.com.

4. From the Mailing settings, grants the user a@example.com the Owner role.

5. From user management, modifies the email from a@example.com to b@example.com by intercepting the request (Burp) and sending the modified request.

6. After the modification succeeds, deletes the user b@example.com.

7. Transfers the domain to the victim’s account (Account B).

8. The victim receives the domain with an existing Mailing.

9. The attacker is able to access the Mailing management interface using the old identity a@example.com and still has the Owner role.

POC: https://admin.alwaysdata.com/support/91899/

Impact

Full control of a Mailing that belongs to a domain the attacker does not own.

Full unauthorized access.

Compromise of the victim’s data confidentiality and integrity.

—

Suggested Fix

Add additional validation to prevent any Owners from existing outside the current domain owner’s account.

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.

POC: https://admin.alwaysdata.com/support/91794/

Description

There is a logical flaw in the domain transfer system within the AlwaysData platform. Creating a Mailing List and then creating a User with Administrator privileges within the domain before sending a transfer invitation causes the transfer invitation to remain pending even after it has been accepted and the domain has actually been transferred.

This flaw allows the attacker account (B) to retain an active transfer invitation that can be used later to take over the domain from any other account that received the domain (victim C).
Consequently, the attacker can regain full control of the domain even though they are no longer the owner, resulting in complete control over:

Email accounts

Mailing Lists

DNS settings

Users and permissions

Any data created by the victim

This represents a critical flaw in ownership control.

—

Steps to Reproduce

1. Setup (Account A)

1. Create a new Domain in your account A.

2. Within the domain:

Create a Mailing List.

Create a User and grant Administrator privileges.
(This step is the primary cause of the flaw.)

3. After that, send a domain transfer invitation to your second account B.

—

2. First Transfer (A → B)

4. From account B:

Accept the transfer invitation.

5. The domain is transferred to B normally,
but the original invitation remains pending in account B despite the transfer being accepted.

—

3. Second Transfer (B → C “Victim”)

6. From account B (which still holds the pending invitation):

Send a transfer invitation to the victim account C.

7. From the victim account C:

Accept the invitation.

8. The victim starts using the domain normally (emails, mailing lists, DNS settings…).

—

4. Final Takeover (from Account B)

9. Return to account B.

You will find that the old transfer invitation is still pending acceptance.

10. Accept the pending invitation.

11. The domain fully returns to account B with all victim data and content, without any notification or additional permission.

POC: https://admin.alwaysdata.com/support/90473/

—

Impact

Full domain takeover.

Access to all existing email accounts.

Control over victim’s email-related accounts and mailing lists.

Full unauthorized access.

Highly critical (Critical).

Proposed Classification:

Severity: Critical – P1

Vulnerability Type: Logic Flaw + Broken Access Control

—

Suggested Fixes

1. Automatically cancel any pending transfer invitations once the domain transfer is accepted.

2. Enforce a single active transfer state, preventing more than one pending invitation for the same domain at a time.

Description: After unlinking Google from a user's account, previously created sessions via Google remain active and are not terminated.

Steps to reproduce:

1. Browser A: Sign in to the account via Google OAuth. Keep the session.

2. Browser B: Sign in to the same account using email/password.

3. From Browser B, go to account settings and unlink Google.

4. Return to Browser A and notice that the session was not terminated.

POC: https://admin.alwaysdata.com/support/90046/

Impact:
An attacker who possesses a previous session via Google remains able to access the account even after the owner believes they have unlinked it — leading to persistent unauthorized access.

Suggestion for fix:

Force immediate logout from all sessions associated with the OAuth provider.

Description:
While testing the ticket feature in the support system, I noticed that the sender’s IP address is visible to all users participating in the same ticket. This behavior leads to an unjustified exposure of sensitive information and constitutes a violation of user privacy, as the IP address can reveal the user’s approximate location and service provider.

Steps to Reproduce:

1. Create a new support ticket.

2. Add another user to the same ticket.

3. Send a message from user account (A).

4. Observe that the IP address of user A appears next to the message and can be seen by the other user.

POC:
https://admin.alwaysdata.com/support/89988/

Impact:
Any participant in the ticket can view the IP address of other users.
This is a clear violation of user privacy and conflicts with data protection policies and laws.

Recommendation:
Hide the IP address from regular users and make it visible only to support staff or administrators.

Description

There is a design flaw in the domain and mailbox management logic within a user account on AlwaysData.
A user who owns multiple subscriptions within the same account can create a mailbox in one subscription using a domain that belongs to another subscription within the same account, without strict verification of domain ownership.

As a result, mailboxes become associated with the domain object itself rather than with the subscription that created them.
When subscriptions or domains are later transferred to other users, mailboxes and their stored emails are automatically re-associated based on domain ownership, enabling serious exploitation scenarios.

—

Scenario 1 — Create a mailbox then transfer the subscription that owns the domain

1. The attacker’s AlwaysData account contains two subscriptions:

Subscription A: with a different domain.

Subscription B: contains the domain victim-domain.com.

2. From within Subscription A, the attacker creates a new mailbox using the domain from Subscription B (for example admin@victim-domain.com).

3. The attacker then transfers Subscription B (which contains the domain) to another user.

4. The mailbox the attacker created remains active and operates under the domain now owned by the new user.

Result:
The attacker retains an active mailbox under a domain that now belongs to another user, allowing them to receive/send emails as that domain — enabling impersonation or disclosure of sensitive communications.

—

Scenario 2 — Create a mailbox, transfer the subscription that contains the mailbox, then later transfer the domain

1. The attacker creates a mailbox in Subscription A using the domain in Subscription B.

2. The attacker transfers Subscription A (which contains the mailbox) to another user. The new user sees the mailbox ready and uses it.

3. Later, the attacker transfers the domain from Subscription B to a new subscription controlled by the attacker.

4. Because the system links mailboxes to the domain, when the domain is moved the mailboxes and all their contents are transferred to the attacker.

Result:
The attacker gains access to all past and future emails of the mailbox used by the new user, constituting a full privacy breach.

POC: https://admin.alwaysdata.com/support/89714/

—

Impact

Unauthorized access to private messages.

Identity impersonation via email addresses tied to the victim domain.

—

Fix Recommendation

Prevent selecting domains from other subscriptions within the same account when creating a mailbox.

Summary
When two-factor authentication (2FA) is enabled, signing in via OAuth results in immediate access to the account without being prompted for the 2FA code. This behavior effectively bypasses the account's second authentication factor.

Reproduction steps:

1. Create or use an existing account on the target site (e.g., user@example.com) and enable 2FA (TOTP).

2. Log out of the site and clear session cookies.

3. Click Sign in with Google and complete Google's OAuth flow using the same email address.

4. Observe: Access to the site is granted immediately and no 2FA prompt is shown.

Expected behavior: After successful OAuth, if the account has 2FA enabled, the site should require the configured 2FA method (TOTP / OTP / push) before issuing an authenticated session.

POC: https://admin.alwaysdata.com/support/89687/ —

Impact:

2FA Bypass

—

Technical root causes (likely)

The server does not check the account's mfa_enabled flag after successful OAuth and issues a session immediately.

—

Recommended fix

Enforce MFA server-side after OAuth: After completing the OAuth/SAML flow, check the user's MFA status and require the configured 2FA verification before issuing the session.

Summary:
When transferring a domain from one Alwaysdata account to another, the associated Mailman mailing lists are not migrated or revoked. The original account retains ownership of these lists and can continue to receive or send emails on behalf of the transferred domain.

Steps to Reproduce:

1. In Account A, add a custom domain (e.g. example.com).

2. Create a Mailman mailing list such as team@example.com.

3. Verify the list is active and receives emails.

4. Transfer the domain example.com to Account B via the official domain transfer process.

5. Observe that the mailing list team@example.com still exists under Account A and can receive/send emails, despite the domain no longer being owned by this account.

POC: https://admin.alwaysdata.com/support/89434/

Impact:

The previous account holder retains unauthorized control over mailing lists linked to a domain they no longer own.

This may allow:

Unauthorized reception of emails intended for the new domain owner.

Sending spoofed emails from the domain.

Potential data leakage of private or sensitive communications.

Severity: High (P2) — because it breaks domain ownership boundaries and enables unauthorized email control.

Recommendation:

When a domain is transferred:

Either migrate all associated mailing lists to the new owner (with consent),

Or revoke and disable them in the old account immediately, ensuring the previous account cannot continue using them.

Severity
P3 – Medium

Product / Area
Account Management / Shared Permissions / Email Management (domain selection when creating a Mailbox)

Summary
A previously reported issue was observed again (Report ID: [203], and it was marked as Fixed on [28/8/2025]). The issue is that an invited user who has not enabled two-factor authentication (2FA) can view the domains of another subscription when attempting to create a Mailbox from their personal account. This behavior reflects a failure to enforce the 2FA requirement and constitutes information disclosure.

This issue was re-observed on 15/09/2025.

Steps to Reproduce:

1. Create a subscription account in Alwaysdata and add a domain.

2. Create another user account (subscription).

3. From the main account, add this user as an Administrator with full permissions.

4. Enable the requirement for 2FA before access.

5. From the secondary account (the other user), attempt to add a Mailbox.

6. The domain list will display, including the main account’s domain, even though the user has not enabled 2FA.

POC: https://admin.alwaysdata.com/support/89183/

(Regression):

The vulnerability was originally reported and marked as Fixed.

Its reappearance means the fix was bypassed.

Severity: Medium – P3

Description:
A security issue was discovered in the account management system on Alwaysdata. When an account owner adds another user as an Administrator and grants them full permissions, but enforces the condition that this user must enable two-factor authentication (2FA) before accessing the shared account, unsafe behavior occurs.

In this scenario, the user who has not yet enabled 2FA can see the list of domains associated with the owner’s shared account when attempting to add a Mailbox in their personal account. Although they cannot create an email using those domains, the mere visibility of the domain names exposes sensitive information about the owner’s infrastructure.

Steps to Reproduce:

1. Create a subscription account in Alwaysdata and add a domain.

2. Create another user account (subscription).

3. From the main account, add this user as an Administrator with full permissions.

4. Enable the requirement for 2FA before access.

5. From the secondary account (the other user), attempt to add a Mailbox.

6. The domain list will display, including the main account’s domain, even though the user has not enabled 2FA.

###POC: https://admin.alwaysdata.com/support/88664/

Impact:

Unauthorized exposure of the owner’s domain names.

This may lead to internal infrastructure information leakage.

An attacker may leverage knowledge of these domains for further attacks.

Note:
If the user is not granted any permissions for email or domains, they cannot see any of the shared account’s domains. This illustrates that domain visibility without 2FA results from the granted permissions interacting with the lack of enforced 2FA, and is not normal system behavior.

Recommendation:
Alwaysdata should ensure that any user who has not enabled 2FA cannot access or even view any sensitive data associated with the shared account, including the domain list.

Summary:
When using the email outbound logs filters in the Alwaysdata admin panel, the CSRF token (csrfmiddlewaretoken) is included as a GET parameter in the URL. This token is supposed to be secret and strictly bound to the user session and to a specific request context. More critically, this token is reusable and can be used with different requests and endpoints, which allows an attacker who obtains it to perform multiple state-changing actions on behalf of the victim without requiring any further user interaction.

Steps to Reproduce:

1. Log in to your Alwaysdata admin panel.

2. Navigate to Emails → Outbound Logs.

3. Apply any filter (e.g., by date or keyword).

4. Observe that the URL now contains a parameter such as: csrfmiddlewaretoken=XXXXXXXXXXXX

5. Copy this URL. You will notice that the token remains valid and can be reused for different requests.

Impact:
Information Disclosure: The CSRF token is exposed in browser history, logs, and potentially leaked via the Referer header when the victim visits external websites afterward.
CSRF Exploitation: Since the token is reusable, an attacker can use it to craft malicious requests (delete, modify, send, etc.) and execute them on behalf of the victim, leading to potential account takeover or severe unwanted actions.

Recommendation:
Completely remove the CSRF token from URL parameters. Pass the CSRF token only as a hidden form field or in a custom HTTP header (e.g., X-CSRFToken). Mark tokens as single-use and ensure they expire after each action.

POC: https://admin.alwaysdata.com/support/87905/

Vulnerability Description:

A vulnerability has been discovered in Alwaysdata's email management system that allows an attacker to retain an active Webmail session even after the associated email address has been renamed in the control panel. This issue enables unauthorized access to the previous email identity and settings, potentially allowing an attacker to maintain control without the new user's awareness.

—

Steps to Reproduce:

1. The attacker adds a custom domain (e.g., test.com) to their Alwaysdata account.

2. They create an email address like admin@test.com and log in to Webmail (webmail.alwaysdata.com), keeping the session active.

3. The attacker then goes to the control panel (admin.alwaysdata.com) and renames the email address to something else (e.g., info@test.com) and saves the changes.

4. Although admin@test.com no longer exists in the interface, its Webmail session remains active.

5. The attacker deletes the domain test.com from their account.

6. The Webmail session for admin@test.com is still valid, and the attacker can access and modify email settings.

—Proof of Concept (PoC) Provided: https://admin.alwaysdata.com/support/86544/

Impact of the Vulnerability:

Modification of email settings.

Wide-scale exploitation: The attacker can repeat the process with multiple domains, allowing them to gain control over different email accounts.

Recommendations to Fix the Vulnerability:

1. Terminate all active sessions immediately when an account is deleted or a domain is removed.

2. Link sessions to the user account instead of just the domain to ensure sessions do not transfer between different users.

This vulnerability poses a serious threat to user privacy and account security, and we strongly recommend fixing it as soon as possible.

Security Report

Subject: Loss of Account Privileges Due to Exploitation of Academy Invitation Feature via Referral Code

—

Summary:

A critical vulnerability has been discovered in the academy invitation mechanism on the AlwaysData platform.
An attacker can exploit the referral system to cause any user (whether a teacher or a regular user) to permanently lose almost all account privileges, leading to near-total account disablement.

—

Technical Details:

Every user on AlwaysData has a unique referral code (for example: X) used to invite new users to register on the platform via the following link:

https://www.alwaysdata.com/en/register/?from=X Additionally, the same referral code is used to invite users to join the user's academy through the following link:

https://admin.alwaysdata.com/academic/attach/?teacher=X

Normally, users without academy administration privileges cannot invite members to an academy.
However, due to the way the invitation link is structured, any user can add themselves to their own academy by modifying the link and adding &attach at the end:

https://admin.alwaysdata.com/academic/attach/?teacher=X&attach

This link causes the user to immediately join their own academy without any notification or additional approval.

—

Attack Scenario:

1. Attacker’s Actions:

The attacker sends the victim their own academy invitation link (using the victim’s referral code):

https://admin.alwaysdata.com/academic/attach/?teacher=X&attach

As soon as the victim clicks the link, they are automatically added to their own academy.

2. Victim’s Actions:

After noticing that they have joined their own academy, the victim may manually leave it,
or they can leave directly using the leave link:

https://admin.alwaysdata.com/academic/detach/

3. After Leaving:

Once the victim leaves their academy, they permanently lose most of their account privileges:

Cannot access Permissions, Billing, Subscriptions, or other administrative sections.

Only able to edit personal information He can't even open a technical support ticket.

Any attempt to access protected sections results in a 403 Forbidden error message.

—POC: Ticket 86507

Impact:

Severe account disablement: The user loses full control over their account.

Data access loss: Access to billing, subscriptions, and key account settings is blocked.

Ease of exploitation: Only the referral code is needed.

Applies to all users: Both teachers and regular users are affected.

Can't open a technical support ticket

—

Recommendations:

Prevent users from joining their own academies using the referral code.

Modify behavior so that leaving an academy does not affect basic account privileges.

Disable automatic addition via &attach, or enforce additional verification before joining an academy.

—

Final Note:

This vulnerability allows any ordinary attacker, without special privileges, to completely cripple any user account with a single click.
It poses a very high security risk to user accounts and requires urgent remediation.

Summary:
The Alwaysdata Academic Cloud system is vulnerable to an attack that allows an attacker to trick students into deleting their own accounts from the platform unknowingly by clicking a specially crafted link.

On-click Delete any student from the Academic Cloud platform by accessing the deletion URL directly.

Steps to Reproduce:

1. Create an account or log into the Alwaysdata Academic Cloud platform.

2. The deletion URL looks like:

https://admin.alwaysdata.com/academic/detach/

3. Create an HTML proof-of-concept file with the following content:

<a href="https://admin.alwaysdata.com/academic/detach/">click</a>

4. Host this HTML page or send it via a link to the victim.

5. Once the victim clicks on the disguised link, their account is deleted from the Alwaysdata Academic Cloud platform without their knowledge or consent.

An attacker can exploit this vulnerability by sending a direct link to the target (student) who has access to the platform.

Impact:
The exploit enables unauthorized deletion of student accounts from the Alwaysdata Academic Cloud platform. This can lead to the loss of critical student data and disrupt academic processes, potentially damaging data integrity and undermining the platform’s security.

Summary:
The Academic Cloud system of the web application is vulnerable to a clickjacking attack that allows an attacker to trick a user into deleting students from their platform unknowingly.

On-click Delete any student from the Academic Cloud platform by accessing the deletion URL directly.

Steps to Reproduce:

1. Create an account or log into the Academic Cloud platform.

2. The deletion URL looks like:
https://admin.alwaysdata.com/academic/release/{student_id}

3. Create an HTML proof-of-concept file with the following content:

<a href="https://admin.alwaysdata.com/academic/release/{student_id}">click</a>

4. Host this HTML page or send it via a link to the victim.

5. Once the victim clicks on the disguised link, the student is deleted from the Academic Cloud platform without their knowledge or consent.

An attacker can exploit this vulnerability by sending a direct link to the target (administrator or teacher) who has access to manage student accounts.

###POC: https://admin.alwaysdata.com/support/86502/

Impact:
The exploit enables unauthorized deletion of students from the Academic Cloud platform. This can lead to the loss of critical student data and disrupt academic processes, potentially damaging data integrity and undermining the platform’s security.

To: Alwaysdata Security Team
From: Mustafa
Date: [17 April 2025]

I would like to clarify that this vulnerability is completely different from the one reported in Report #151. In this case, the subscription account transfer invitation is sent first, followed by the domain transfer invitation while waiting for acceptance, which allows the exploitation of an unprotected time gap.

I also confirm that the vulnerability reported in Report #151 has been fixed.

Please review the details below.

–

### Executive Summary
A critical security vulnerability (High Risk) has been identified in Alwaysdata's domain and site and subscription account management system. This flaw allows an attacker to hijack a victim's domain without their knowledge by exploiting the account invitation transfer mechanism. Immediate action is required due to its direct impact on user data confidentiality and integrity.

—

### Vulnerability Details
#### Exploitation Mechanism
1. Attacker Setup:

1. Account A: Used to send a subscription account transfer invitation to the victim (Account C).
2. Account B: Used to receive a domain transfer invitation from Account A.

2. Attack Steps:

1. Account A sends a subscription account transfer request to Victim C.
2. Simultaneously (or before C accepts), Account A sends a domain transfer request to Account B.
3. When Victim C accepts the subscription transfer, they believe they now own the domain and associated data.
4. Meanwhile, the domain transfer request to Account B remains pending, invisible to C.
5. After C adds sensitive data (emails, mailing lists, configurations), Account B accepts the domain transfer, seizing full control.

#### Why Is This Critical?
- The victim receives no warning about pending domain transfer requests.
- The attacker can choose the timing of the takeover (e.g., waiting until the victim adds critical data).
- All domain-linked services (email, websites, Mailman lists) become compromised.

—POC: https://admin.alwaysdata.com/support/86381/

### Impact Assessment
- High Risk per OWASP/CVE standards:

1. Privacy Breach: Theft of emails and user data.
2. Ownership Hijacking: "Legitimate-looking" domain transfer without user consent.
3. No Traceability: The victim remains unaware until irreversible damage occurs.

—

### Proof of Concept (PoC)
- The scenario is practical and replicable in Alwaysdata's live environment.
- Requires minimal technical skill, only exploiting the timing gap in transfer requests.

—

### Recommended Fixes
1. Transfer Mechanism Patch:

1. Block concurrent transfer requests (subscription + domain) for the same account.
2. Add a conflict check before approving any transfer.

2. User Notifications:

1. Immediately alert users of pending domain transfer requests.
2. Show a clear warning during subscription transfers if a domain transfer is pending.

3. Grace Period:

1. Implement a 24-hour delay for domain transfers with repeated owner notifications.

4. Retroactive Audit:

1. Review past domain transfers for suspicious activity.

—

### Conclusion
This vulnerability severely undermines user trust and poses legal/financial risks. We urge treating it as a P1 priority and transparently informing users of security updates.

Title: Logical Flaw in Account Transfer Allows Unexpected Loss of Site/Domain Ownership After Old Invitation is Accepted

—

Description:

The AlwaysData platform allows users to transfer ownership of assets such as sites and domains, either individually or by transferring the entire account to another user. The vulnerability occurs when an invitation to transfer a specific asset (e.g., a site) is sent to a user who delays accepting it. Later, the entire account — including the previously invited site/domain — is transferred to a different user.

The issue arises when the first user (who received the initial invitation) finally accepts it after the account has already been transferred. This results in the site or domain being unexpectedly and silently pulled from the new account owner and given to the first invited user — a behavior that is both unintended and out of the new owner’s control.

—

Steps to Reproduce:

1. User A owns an account that contains a site (e.g., testss.alwaysdata.net).

2. A sends an invitation to B to transfer the site ownership.

3. B does not accept the invitation immediately.

4. Later, A transfers the entire account (including the site and domain) to C.

5. C begins using the site in a production environment.

6. After some time, B accepts the old invitation for the site.

7. Result: The site is unexpectedly transferred from C to B, causing:

Service downtime if the site is in active use.

Loss of access for C.

Potential data leakage if the site contains sensitive content.

###I sent a proof of concept: https://admin.alwaysdata.com/support/86226/

—

Impact:

Loss of full control: User C, now the legitimate account owner, loses the site/domain without notice.

Privacy and confidentiality breach: If sensitive data exists on the site or domain.

Abuse potential: Malicious actors could deliberately delay accepting invites to hijack assets in the future.

—

Severity:

P2 - High Severity

Ease of Exploitation: No advanced techniques required.

Impact: High, as it affects ownership of critical infrastructure.

Unexpected Behavior: From the new owner’s perspective, the outcome is both surprising and disruptive.

—

Recommendations:

1. Invalidate pending invitations automatically upon account or asset transfer.

2. Redesign ownership logic to bind invitations to current ownership context.

3. Add verification layers to ensure old invitations can't be acted upon after transfer events.

Vulnerability Description:

A vulnerability was discovered in Alwaysdata's domain and email management system, allowing an attacker to maintain an active session even after deleting their account. This vulnerability can be exploited through email domain reuse in Webmail, enabling an attacker to gain access to newly created email accounts without needing to steal login credentials.

Exploitation Steps:

1. The attacker adds the domain evil.com to their Alwaysdata account.

2. They create an email address admin@evil.com via Webmail (webmail.alwaysdata.com).

3. The attacker logs into Webmail and saves the session.

4. They delete their Alwaysdata account, but the Webmail session remains active.

5. A new user adds evil.com to their Alwaysdata account and creates the same email admin@evil.com.

6. Once the new user logs into Webmail, the attacker still has access to the email since their session remains active!

Proof of Concept (PoC) Provided: https://admin.alwaysdata.com/support/85071/

Impact of the Vulnerability:

Modification of email settings.

Wide-scale exploitation: The attacker can repeat the process with multiple domains, allowing them to gain control over different email accounts.

Recommendations to Fix the Vulnerability:

1. Terminate all active sessions immediately when an account is deleted or a domain is removed.

2. Link sessions to the user account instead of just the domain to ensure sessions do not transfer between different users.

This vulnerability poses a serious threat to user privacy and account security, and we strongly recommend fixing it as soon as possible.

Vulnerability Type:

Session Management Issue

Email Account Takeover

User Data Exposure

Severity: P1 (Critical)

This vulnerability allows an attacker to retain a valid session even after a subdomain is deleted or transferred to another user, enabling them to:

Read all incoming emails of the new user.

Send emails on behalf of the new user.

Modify email settings, such as forwarding rules and signatures.

—

Description:

The Alwaysdata platform allows users to create subdomains under alwaysdata.net for hosting websites and managing emails via webmail.alwaysdata.com. However, a critical session management flaw enables an attacker to retain an active session even after deleting or transferring the subdomain to a new user.

—

Scenario 1: Subdomain Reuse

Steps to Reproduce:

1. The attacker creates a subdomain (e.g., attacker.alwaysdata.net).

2. The attacker logs into webmail.alwaysdata.com and keeps the session active.

3. The attacker deletes the subdomain from their account.

4. A new user registers the same subdomain (attacker.alwaysdata.net).

5. The new user logs into webmail.alwaysdata.com.

6. The attacker retains a valid session, allowing them to:

Read all incoming emails of the new user.

Send emails on behalf of the new user.

Modify email settings (forwarding, signature, etc.).

7. The new user may encounter session-related errors, such as:
"Server Error: CREATE: Internal error occurred. Refer to server log for more information."

—

Scenario 2: Subdomain Ownership Transfer

Steps to Reproduce:

1. The attacker creates a subdomain (e.g., attacker.alwaysdata.net).

2. The attacker logs into webmail.alwaysdata.com and keeps the session active.

3. Instead of deleting the subdomain, the attacker transfers ownership to another user via admin.alwaysdata.com.

4. The new user accepts the transfer and starts using the subdomain.

5. The attacker retains an active session, allowing them to:

Read and send emails on behalf of the new user.

Modify email settings.

Access the email account until the session expires.

6. Even if the new user changes their email password via admin.alwaysdata.com, the attacker still has access due to the active session.

—

Impact:

Sensitive Data Exposure: The attacker can read incoming emails.

Identity Theft: The attacker can send emails on behalf of the new user.

Account Compromise: The attacker can modify email settings to maintain access.

Mass Exploitation: The attacker can create and delete multiple subdomains to target many future users.

##POC: https://admin.alwaysdata.com/support/84903/

—

Recommended Fixes:

Terminate all active sessions immediately upon subdomain deletion or transfer.

Link sessions to the user account instead of just the subdomain.

Warn the new user if there was an existing open session for the same subdomain.

Enforce re-authentication when transferring subdomain ownership.

Add an additional verification layer for email-related sessions when ownership changes.

This vulnerability poses a severe risk to user privacy and requires an urgent fix to prevent unauthorized access to email accounts.

1. Summary:

When creating a new account on the platform, the user is required to verify their email address to complete the registration process. However, after completing the initial verification, the user can change the email address associated with the account to another one without the need to verify the new email.
This bypasses the verification mechanism designed to ensure that the user owns the email linked to their account, posing a potential security risk that could be exploited for fraud, account takeovers, and the creation of fake accounts.

2. Steps to Reproduce the Vulnerability:
Create a new account using a valid email address.
Confirm the email address by clicking the verification link sent to the email.
Navigate to account settings and update the email address to a different one.
Notice that no verification is required for the new email, and the change is applied immediately.

3. Impact:

1. Account Takeover (ATO):
If an attacker gains access to another user's account (through a session hijack or weak password reset mechanism), they can change the email address to their own without requiring confirmation.
Once the email is changed, the victim loses access to recover their account, even if they attempt to reset their password.
If the account contains sensitive information (such as payment details or personal data), this could lead to financial losses or identity theft.

2. Fraud and Phishing:
An attacker can change their email address to one resembling official support (e.g., support@company.com).
They can then use this email to send phishing messages to other users, making the attack more convincing.

4. Recommendations & Fixes:

Require users to verify the new email address before updating it in the account.

##Title: Improper Access Control in [admin.alwaysdata.com]

Summary:

A privilege escalation vulnerability was identified in the platform’s access control mechanism for managing specific paths related to site and SSL configurations. When a user is restricted from accessing a specific path within a site (sites path permission denied) but granted access to SSL management, they can still access a URL path intended for restricted site management at /site/xx/ssl. This bypasses intended access restrictions.

Description:

[Note that the path I mentioned to you does not appear to you when you are not given permissions to access the path (site)]

The platform enables administrators to set granular permissions, controlling what paths invited users can access or manage within a site. Two relevant permissions in this context are:

Path Management (sites): Grants access to manage certain paths related to a site.

SSL Management (ssl certificates): Grants access to manage SSL certificates.

There is a permissions inconsistency that allows users with SSL Management permissions, but without specific sites path permissions, to access the /site/xx/ssl path. This path resides within a restricted site-related path, yet contains SSL management functionalities. As a result, users can bypass restrictions on specific paths and potentially access or manipulate SSL settings.

##Link: [https://admin.alwaysdata.com/site/configuration/ssl/]
Steps to Reproduce:

1. Create a user account and assign SSL Management (ssl certificates) permissions, while explicitly denying access to the sites path.

2. Attempt to access the URL path: /site/xx/ssl.

3. Observe that access is granted to the SSL management path within the restricted sites path, despite restrictions on other paths under sites.

Expected Result:

The system should prevent access to paths under /site—including /site/xx/ssl—when specific path permissions are denied.

Actual Result:

The user can access /site/xx/ssl even though access to paths under /site is restricted, allowing them unintended access to certain SSL configurations tied to the site path.

##Proof of Concept: https://admin.alwaysdata.com/support/82440/384175-bandicam%202024-11-12%2004-13-20-975.mp4

Impact:

This vulnerability allows unauthorized users to bypass restrictions on certain paths and access SSL configurations. If exploited, this could lead to unauthorized manipulation of SSL settings, compromising the security integrity of site-related resources.

### Title:
Insecure Direct Object Reference (IDOR) Vulnerability: Unauthorized Commenting on Invisible Reports in [security.alwaysdata.com]

Note: I sent the vulnerability to [flyspray] They did not respond to the security report, and it has been a long time, So I had to send it to you.
—

#### Introduction
A security vulnerability has been identified in the site's report commenting feature, which allows unauthorized users to add comments to reports they should not have access to. This is due to an Insecure Direct Object Reference (IDOR) issue, compromising the integrity of sensitive data.

—

#### Steps to Reproduce
1. Create a New Report: Log in and create a new report.
2. Add a Comment: Use Burp Suite to intercept the HTTP request while adding a comment.
3. Modify the Report ID: Change the report ID in the request to one that is not visible to the public.
4. Submit the Modified Request: Forward the modified request through Burp Suite.
5. Check for Unauthorized Comment: Verify that the comment has been added to the invisible report.

##POC: To prove the concept, I commented on a report from my second account, and this report is not publicly available, Report number: 78
link: https://admin.alwaysdata.com/support/82086/382759-Screenshot_%D9%A2%D9%A0%D9%A2%D9%A4%D9%A1%D9%A0%D9%A2%D9%A4_%D9%A0%D9%A4%D9%A5%D9%A9%D9%A5%D9%A7_Kiwi%20Browser.jpg —

#### Impact
This IDOR vulnerability can lead to:
- Unauthorized Access: Users can manipulate and comment on reports they are not permitted to view.

Title: Access Control Vulnerability in Two-Factor Authentication Management

Summary: This report highlights a security vulnerability related to user account management and two-factor authentication (2FA) within the system. The issue arises when a user invites another user to manage their account, creating a loophole that allows continued access even after 2FA is disabled.

—

Steps to Reproduce:

1. Account Creation:

1. A user creates a new account on[admin.alwaysdata.com].

2. Invite for Account Management:

1. The account owner invites another user to manage their account. The system requires that the invited user enables two-factor authentication on their account to gain management privileges.

3. Two-Factor Authentication Activation:

1. The invited user successfully activates two-factor authentication.

4. Management Access Granted:

1. The invited user can now manage the account of the account owner without restrictions.

5. Disable Two-Factor Authentication:

1. The invited user disables two-factor authentication on their account.

6. Continued Management Access:

1. Despite the deactivation of 2FA, the invited user retains the ability to manage the account of the account owner. This is contrary to the initial requirement that 2FA must be active for management access.

7. Session Management Issues:

1. If the invited user logs out and logs back in, they are prompted to re-enable 2FA to regain management access. However, this inconsistency presents a potential security risk during active sessions, Where the user can keep his session for up to two weeks

—##POC: https://admin.alwaysdata.com/support/81354/

Impact: This vulnerability allows an invited user to maintain management privileges over another user’s account, even after failing to comply with security requirements (2FA). If a malicious element manages to hijack the invited user's session, they can control the account owner’s settings without their consent, leading to potential data breaches

## Security Report: On click Mark all notifications as read in [admin.alwaysdata.com]

Description

When a specific link is sent to another user and clicked, it causes all their notifications to be marked as read

### Steps to Reproduce

1. Log into your account on [admin.alwaysdata.com].
2. Send the link to the user. [https://admin.alwaysdata.com/message/toggle/]
3. The recipient clicks on the link.

All notifications for the user who clicks the link are marked as read.

##POC: https://admin.alwaysdata.com/support/77431/379620-bandicam%202024-09-20%2018-30-42-910.mp4

## Impact

Users may lose track of important notifications. In addition, it raises concerns about the security and integrity of user account management, as an attacker could exploit this vulnerability to manipulate notification statuses.

Title: Two-Factor Authentication Bypass Issue in [admin.alwaysdata.com]

Summary: A vulnerability has been identified that allows an attacker to bypass Two-Factor Authentication (2FA) and manage applications on a user’s account. The attacker can create and delete applications on the account of the user who invited them.

Steps to Reproduce: 1. Create a new account.
2. Add a member to manage your account and activate Two-Factor Authentication (2FA) for that member.
3. Add an application to your account.
4. Log in to the account of the invited member.
5. Navigate to the following link: [https://admin.alwaysdata.com/site/application/script/].
6. Observe that you can create a new application and delete existing applications on the account of the original account holder.

POC: https://drive.google.com/file/d/1v5PbiZaZZK7l30XgdZx7025tsZnDOOf8/view?usp=drivesdk

Impact: Two-Factor Authentication Bypass