Security vulnerabilities

Title: Security Report: Public Exposure of Sensitive Information

Introduction:
The purpose of this report is to highlight a critical security issue involving the public exposure of sensitive information on the website security.alwaysdata.com. The exposed data includes details about supervisors, the number of reports they have sorted, and some reports that remain unprocessed and may contain sensitive information and unpatched vulnerabilities.

Exposure of Supervisor Information:
The website security.alwaysdata.com hosts a page that displays information about all users, including supervisors. The URL format for accessing supervisor information is https://security.alwaysdata.com/user/1. By manipulating the numeric value in the URL, it is evident that any user can access information about all users and supervisors on the site. This unrestricted access poses a significant security risk as it allows unauthorized individuals to view sensitive user data, potentially compromising the privacy and security of the users and the platform as a whole.

Unsecured Reports:
Furthermore, the website contains reports that are in an unprocessed state and have not been closed. These reports are accessible to the public through the URL format https://security.alwaysdata.com/task/23?dev=1. The presence of such reports in an open state poses a severe security threat as they may contain sensitive information that should not be shared with regular users. Additionally, these reports may reveal unpatched vulnerabilities in the platform, further increasing the risk of exploitation by malicious actors.

Recommendations:
1. Immediate Restriction of Access: It is imperative to implement access controls to restrict public access to supervisor information and unprocessed reports. Access should be limited to authorized personnel with appropriate privileges.

2. Review and Remediation: All unprocessed reports should be reviewed to identify and address any sensitive information or vulnerabilities they may contain. Once remediated, these reports should be appropriately secured and closed.

3. Security Awareness Training: Conduct security awareness training for all personnel involved in managing and maintaining the website. Emphasize the importance of safeguarding sensitive data and the potential consequences of data exposure.

4. Regular Security Audits: Implement regular security audits to identify and address any potential security loopholes, including unauthorized access to sensitive information and unsecured reports.

Conclusion:
The public exposure of supervisor information and unsecured reports on security.alwaysdata.com poses a significant security risk, potentially compromising user privacy and platform integrity. Immediate action is necessary to address these vulnerabilities and ensure the confidentiality and security of user data. Failure to mitigate these risks could lead to severe repercussions for the organization and its users.

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.

Description:

I discovered a publicly accessible PDF file containing sensitive financial and personal information at the following URL:
https://share.alwaysdata.com/IBAN.pdf AND https://static.alwaysdata.com/docs/IBAN.pdf

The document exposes Personally Identifiable Information (PII) and sensitive banking details, including the International Bank Account Number (IBAN), Bank Identifier Code (BIC), account holder's name, and address. This information could be exploited for unauthorized transactions, fraud, and privacy violations.

Steps to Reproduce:

1. Navigate to the URL: [https://static.alwaysdata.com/docs/IBAN.pdf] and [https://share.alwaysdata.com/IBAN.pdf]
2. Download the file (IBAN.pdf).
3. Open the file to view the sensitive details

Impact:

• Financial Risks: An attacker could misuse the exposed banking details for unauthorized transactions or fraudulent activities.
• Privacy Concerns: The document discloses the account holder’s name and address, increasing the risk of phishing or other targeted 
        attacks.
• Legal Compliance: Public exposure of such information may violate data protection regulations, such as the GDPR (General Data 
        Protection Regulation) in the EU.

Mitigation:

1. Immediately remove the file from public access.
2. Audit all publicly accessible files to ensure sensitive information is not exposed.
3. Use preventive measures like robots.txt or noindex tags to prevent indexing by search engines.
4. Review the system to ensure sensitive files are stored securely and not inadvertently exposed.

Severity: High – This issue involves the public disclosure of sensitive financial and personal information, which could lead to significant harm if exploited.

Suggested Timeline for Fix: Immediate – This issue should be prioritized for resolution to prevent potential abuse.

Hope this will be fixed soon.
Do let me know if you need any further assistance.

NOTE: While Making this report public please make sure to mask or remove the sensitive information that is written in the report.

Thanks
Best Regards
Aakarsh Mishra

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.

Description

Mailman handles email address casing (Uppercase/Lowercase) inconsistently between user creation, account association, and permission assignment.

This issue leads to unauthorized access between users and complete takeover of the resources associated with the targeted account.

Steps to Reproduce

1. Log in to the first Alwaysdata account (Victim).

2. Create one or more domains.

3. Create one or more mailing lists using Mailman.

4. Create a Mailman user with the email address "Test@example.com".

5. Assign this user as an Administrator on all mailing lists.

6. Log in to another Alwaysdata account (Attacker).

7. Create a new Mailman user with the email address "test@example.com".

8. Access the Mailman interface from the attacker's account.

9. Observe that the attacker gains access to the victim's Mailman account and all associated permissions.

10. The attacker can now fully manage the victim's mailing lists, including members, settings, and list moderation.

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

Impact

An attacker can take over another user's Mailman account and obtain all permissions granted to it.

This results in:

- Unauthorized access to the victim's Mailman account.
- Inheritance of all permissions associated with the account.
- Full control over the victim's mailing lists.
- Adding or removing members.
- Modifying mailing list settings.
- Performing all actions available to the legitimate administrator.

This results in a complete takeover of the victim's Mailman account and unauthorized control over its resources.

Suggested Fix

Normalize email addresses before user creation, authentication, or permission assignment by converting all addresses to lowercase.

Additionally, prevent the creation of multiple Mailman users whose email addresses differ only by letter case.

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.

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.

*Title:* Insufficient Validation Allows Multiple Accounts Creation Under Single Subscription Plan

*Description:*
A vulnerability has been identified in the subscription management system which allows users to create multiple accounts under the same subscription plan. This issue can be exploited to bypass restrictions on the number of accounts per plan and gain unauthorized benefits.

*Steps to Reproduce:*

1. *Create an Account:*

1. Sign up for a new account with a specific subscription plan (e.g., "Free Plan").

2. *Create a Duplicate Account:*

1. Attempt to create another account using the same subscription plan as the first account.
2. Notice that the system does not prevent the creation of multiple accounts under the same subscription plan.

3. *Create a Similar Plan Account:*

1. From the newly created account, sign up for a subscription plan similar to the first account's plan.

4. *Send an Invitation:*

1. Send an invitation from the second account to the first account to become an admin of the plan created by the second account.

5. *Accept the Invitation:*

1. After accepting the invitation, the first account will now have two accounts under the same subscription plan.

I sent a proof of concept: https://admin.alwaysdata.com/support/77431/375639-poc.mp4

*Impact:*

This vulnerability allows users to circumvent subscription limitations by creating multiple accounts under the same plan

### 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: 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.

Description:
An exposed .git folder has been discovered on the website https://security.alwaysdata.com, which allows unauthorized access to sensitive files related to the site's source code repository. This could potentially lead to the leakage of sensitive information, such as configuration settings and code, which can facilitate further attacks.

URL:
https://security.alwaysdata.com/.git/config

Details:
By accessing the .git folder, the following sensitive files were found to be publicly accessible:

.git/config
.git/index
.git/packed-refs
.git/info/exclude
.git/logs/HEAD
And many more.

Example of Sensitive Information Exposed:

[core]

  repositoryformatversion = 0
  filemode = true
  bare = false
  logallrefupdates = true

[remote "origin"]

  url = https://github.com/flyspray/flyspray.git
  fetch = +refs/heads/*:refs/remotes/origin/*

[branch "master"]

  remote = origin
  merge = refs/heads/master

Using a tool such as GitDump, the entire .git directory was successfully dumped, providing full access to the contents of the repository. This may lead to further exploitation by attackers.

Exposed URLs:
https://security.alwaysdata.com/.git/index https://security.alwaysdata.com/.git/packed-refs https://security.alwaysdata.com/.git/info/exclude https://security.alwaysdata.com/.git/logs/HEAD

Impact:
Unauthorized Access to Source Code: Attackers can gain access to the complete source code, potentially uncovering proprietary algorithms, logic, and confidential information that could be misused for malicious purposes, including code analysis or redistribution.
Sensitive Information Disclosure: The .git/config file and other repository metadata may contain sensitive information, such as database credentials, API keys, or other secrets, which could allow attackers to gain unauthorized access to critical components of the infrastructure.
Potential for Further Exploitation: With access to the source code and potentially sensitive configuration details, attackers may be able to exploit additional vulnerabilities or gain deeper access to the system.

Remediation:
Remove these files from production systems or restrict access to the .git directory. To deny access to all the .git folders you need to add the following lines in the appropriate context (either global config, or vhost/directory, or from .htaccess):

<Directory ~ ".git">
Order allow,deny
Deny from all
</Directory>

If further information is required, please let me know.

Thanks.

#Description:
During testing, I found that the TOTP code verification does not properly validate the expiry window. Even after waiting for the OTP to expire (30s), I was still able to use the expired code to perform sensitive actions like updating my profile.

#Impact:

Replay attack possible using previously used OTPs.

Weakens 2FA mechanism.

May allow attackers to bypass intended security checks.

#Steps to Reproduce:

Enable 2FA on account.

Generate OTP via authenticator app.

Wait for 30 seconds until OTP expires.

Submit the expired OTP.

Server still processes the action (profile updated).

#Expected Behavior:
The expired OTP should be rejected.

#Actual Behavior:
Expired OTP is accepted.

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.

Severity: Critical

Description

There is a logic flaw in the domain transfer workflow that allows a previously created transfer request to remain valid and executable even after the domain has already been transferred to another user.

The application does not invalidate or revalidate pending transfer requests when the domain’s ownership or state changes. As a result, an attacker can create a transfer request targeting an email address they control, retain this request, and then allow the domain to be legitimately transferred to the victim’s account.

After the transfer is completed, the previously created transfer request remains valid. The attacker can therefore use it at a later time to transfer the domain from the victim’s account to an account controlled by the attacker.

In other words, the attacker can retain a persistent path to take over the domain even after the domain has become owned by the victim.

Steps to Reproduce

  Create a domain from an attacker-controlled account.
  Navigate to Domain Settings → DNSSEC.
  Toggle the DNSSEC status between Active and Deactivated approximately 6 times.
  Create a transfer request for the domain to another account controlled by the victim.
  Have the victim accept the transfer request.
  During the short period before the transfer state is fully reflected, the attacker cancels the visible transfer request.
  The attacker immediately creates another transfer request for the domain to an email address they control.
  The transfer request accepted by the victim is processed, and the domain reaches the victim’s account.
  Despite the domain ownership having been transferred to the victim, the previously created transfer request by the attacker remains valid and usable.
  The attacker can later accept the old transfer request, causing the domain to be transferred from the victim’s account to the attacker’s account.

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

Impact

The vulnerability results in unauthorized domain takeover with a persistent path to regain control of the domain.

The issue is not merely temporary access or unauthorized modification of a transfer request; the attacker can retain a valid transfer request that can be used later, even after ownership of the domain has been legitimately transferred to the victim.

After the domain is transferred to the attacker’s account, they can control the resources hosted on or associated with the domain, including, depending on the resources associated with it:

  The website associated with the domain.
  DNS configuration.
  Email addresses and mailboxes.
  Mailing Lists.
  Users associated with the domain.
  Databases and other resources associated with the domain.

Therefore, the ultimate impact is complete loss of domain ownership and control over the hosted infrastructure and resources associated with it, rather than merely manipulating a transfer request.

Suggested Remediation

Transfer Requests should be treated as stateful, single-use transactions and must not remain valid after the domain’s ownership or transfer state changes.

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

*Title: Critical Security Vulnerability: Unauthorized Account Deletion via Limited Permissions* in [admin.alwaysdata.com]

Summary:*
During my investigation, I discovered a significant security flaw in the system's account management feature.

*Description:*
The system allows users to invite others to manage their accounts with varying permissions, including the ability to enforce two-factor authentication (2FA) before accessing account management privileges.

*Vulnerability Details:*
I identified a vulnerability wherein an invited user, even without sufficient permissions or 2FA activation, can delete the inviting user's account from their own account. This deletion occurs regardless of whether 2FA was enabled during the invitation process.

*Steps to Reproduce the Bug:*
1. Create two accounts.
2. Invite a user to administer your account and enable 2FA.
3. From the invited user's account, delete the account of the inviting user.
4. Observe that the inviting user's account is permanently deleted, despite prior 2FA activation or the absence of sufficient permissions granted.

I sent proof of concept: https://admin.alwaysdata.com/support/77431/374527-bandicam%202024-07-17%2003-48-55-255.mp4

*Impact:*

This security vulnerability poses a significant risk to user accounts within the system. It allows an invited user, even with limited permissions and without activating two-factor authentication (2FA), to permanently delete the account of the inviting user. This action occurs despite security measures initially set up, such as 2FA activation during the invitation process or inadequate administrative permissions granted.

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/

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.

*Title:*: Bypassing Email Address Restriction for Account Creation

*Description:*
The ban on an email can be bypassed

An example is the following e-mail address: "admin@alwaysdata.com"

*Steps to Reproduce:*
1. Attempt to create an account using a blocked email address. The system will display a message stating that the email address is blocked and prevent account creation.
2. Create an account using a different email address.
3. Once the account is successfully created, navigate to the account settings.
4. Change the email address of the account to the previously blocked email address.
5. Save the changes. The email address will be updated to the blocked one, bypassing the initial restriction.

*Impact:*
This issue allows users to circumvent email address restrictions.

*Recommendation:*
Implement server-side checks to ensure that email address restrictions are enforced consistently across all account management functionalities. Additionally, review the email update process to prevent such bypasses.

*POC:*

poc1: https://admin.alwaysdata.com/support/77431/375912-poc.22.png poc2: https://admin.alwaysdata.com/support/77431/375911-bandicam%202024-08-05%2009-36-57-769.mp4

*Title:* Account Creation and Impersonation Vulnerability in [admin.alwaysdata.com]

*Summary:*
It is possible to create a new account on the site using the domain name admin1@alwaysdata.com. After creating this account, the username can be changed to that of a legitimate site administrator. This vulnerability allows the account to generate support tickets and invite users, In this way he can defraud users.

*Steps to Reproduce:*
1. Register a new account on the site using the email admin1@alwaysdata.com , Or by any other name
2. Change the account username to that of a real site administrator.
3. Use the account to create a support ticket and invite users.

poc: https://admin.alwaysdata.com/support/77431/375910-poc.alwaysdata.png

*Impact:*
This vulnerability enables attackers to impersonate site administrators within the support system, Which enables the attacker to impersonate the administrators of the site and deceive users

*Recommendation:*
To mitigate this risk, implement restrictions to prevent the creation of accounts with administrative email domains.

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

A rate limiting algorithm is used to check if the user session (or IP address) has to be limited based on the information in the session cache. In case a client made too many requests within a given time frame, HTTP servers can respond with status code 429: Too Many Request. I just realized that on the reset password page, the request has no rate limit which can be used to loop through one request

Steps to reproduce-

.Go to the alwaysdata password reset page.
.Enter the email address of a test account controlled by the researcher.
.Submit the password reset request.
.Repeat the same request multiple times within a short period using the same email address.
.Observe that the application continues accepting the requests without showing a cooldown, CAPTCHA, temporary block, or rate-limit error.

Observed Result:
The application allows repeated password reset email requests for the same account without visible throttling or blocking.

Expected Result:
The password reset endpoint should apply abuse protection, such as:

Per-account cooldown.
Per-IP rate limiting.
CAPTCHA after repeated attempts.
Temporary blocking after excessive requests.
Generic response message to reduce abuse.

Security Impact:
An attacker could abuse this behavior to repeatedly send password reset emails to a target user. This may cause inbox flooding, harassment, and abuse of the platform’s email-sending resources.

I tested this only against my own account and did not attempt to target other users or perform high-volume testing.

Proof of Concept is in the video below

Description:

Content spoofing, also referred to as content injection, “arbitrary text injection” or virtual defacement, is an attack targeting a user made possible by an injection vulnerability in a web application. When an application does not properly handle user-supplied data, an attacker can supply content to a web application, typically via a parameter value, that is reflected back to the user. This presents the user with a modified page under the context of the trusted domain. This attack is typically used as, or in conjunction with, social engineering because the attack is exploiting a code-based vulnerability and a user’s trust.

Impact:

An attacker can use text injection vulnerability to present a customized message on the application that can phish users into believing that the message is legitimate. The intent is typical to tick victims, although sometimes the actual purpose may be to simply misrepresent the organization or an individual.

Steps to Reproduce:

1: Navigate to given URL: https://admin.alwaysdata.com/ 2: At the end of the URL enter /hacker
3: Now on the page you will see hacker is reflecting on page.

Poc: https://https://drive.google.com/file/d/1gG_U7sszvkvv3Rz8CxK89EW2wp7xtxC8/view?usp=sharing

test