All Projects

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

Security Report: Disclosure of Two-Factor Authentication Status in [admin.alwaysdata.com]

Summary:

A vulnerability exists where the two-factor authentication (2FA) status of a user account can be determined by adding the user as an administrator to your account. This issue exposes whether the user has 2FA enabled or not.

Steps to Reproduce:

1. Attempt to Log In with Incorrect Credentials:

1. Start by trying to log in with incorrect credentials. This demonstrates that you cannot determine whether 2FA is enabled based on the failed login attempt alone.

2. Observe the Failed Login Behavior:

1. Note that with incorrect login credentials, it is not possible to ascertain the 2FA status of the user account.

3.You can't know that the account has activated two-factor authentication until you provide the correct credentials and then it will transfer you to the next stage where you will be asked for the two-factor authentication number

4. Add the User as an Administrator:

1. Add the user in question as an administrator to your account.
2. Upon doing so, you will be able to see whether this user has 2FA enabled or not.

I sent a proof of concept:https://admin.alwaysdata.com/support/77431/377370-bandicam%202024-08-26%2019-23-18-853.mp4

Impact:

The ability to determine the 2FA status of a user account can pose a security risk. Attackers who gain administrative access could potentially use this information to tailor their attacks based on whether a target user has an additional layer of security.

*Title: Unauthorized Email Sending Exploit in [alwaysdata.com] Summary: A vulnerability has been discovered in the site's email handling system. The site assigns each user a unique email address. However, it is possible to send an email from any email account, bypassing the intended email restrictions and validation mechanisms. Vulnerability Details: - Type: Email Spoofing
- Impact: Unauthorized email sending
- Affected Component: Email Handling System Description: The application generates a unique email address for each user. However, it is possible to exploit the system to send emails from any arbitrary email address. This issue arises due to insufficient validation of the email sender’s address. Proof of Concept: 1. Exploit Steps: - Use an email client or script to send an email through the application.
- Modify the "From" address to any arbitrary email address, not restricted to the user's assigned address. 2. Result: - The email is sent successfully. Follow the steps in the video: https://admin.alwaysdata.com/support/77431/376905-bandicam%202024-08-20%2003-19-32-375.mp4 Impact:**

This vulnerability allows an attacker to send emails appearing as if they are from any user.

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

On-click Delete any invitation in [admin.alwaysdata.com]

*Summary:*
The [Create My Own Site] web application system is vulnerable to a click grabbing attack that allows an attacker to trick the user into deleting invitations that they have sent or received without their knowledge.

*Reproduction steps:*
1. Send an invitation to another user.
2. Receive an invitation and try it on the other account.
3. Get the direct link to the invitation and add the /cancel/ command to the URL.
4. Create an HTML proof-of-concept file with the following content:

Programming Language

<a href="https://admin.alwaysdata.com/transfer/Invitation_Number/cancel/----">Click</a>

5. Host this HTML page or send it via link to the victim.
6. Once the victim clicks on the masked link, the invitation is deleted without their explicit consent or knowledge.

An attacker could use their location and attach an HTML file instead of sending a file that the user clicks.

I have sent a proof of concept:
https://admin.alwaysdata.com/support/77431/374245-bandicam%202024-07-14%2007-00-17-624.mp4

*Impact:*
The exploit allows the deletion of any invitation that the user has sent or reached another user without his consent.

*Vulnerability Summary: Unauthorized Account Takeover via Invitation Exploitation in [admin.alwaysdata.com] Vulnerability Description: A critical security vulnerability was identified in the account invitation process of [Service that allows the user to create a site]. This vulnerability allowed an unauthorized user to gain administrative control over another user's account through the invitation feature. Below is a detailed timeline of events leading to the account takeover: 1. Account Creation: - A user (referred to as User A) created an account on [Service that allows the user to create a site]. 2. Incorrect Invitation: - User A intended to invite a member to become an administrator but mistakenly sent the invitation to another user (User B). 3. Invitation Deletion: - Realizing the mistake, User A promptly deleted the invitation intended for User B. 4. Correct Invitation: - User A subsequently invited their colleague (referred to as User C) to become an administrator of their account. 5. Acceptance by Colleague: - User C accepted the invitation, assuming administrative rights as intended by User A. 6. Unauthorized Acceptance: - Meanwhile, User B, who received the initial invitation in error, noticed the invitation and, potentially unaware of the implications, accepted it. 7. Account Takeover:**

1. By accepting the invitation, User B gained administrative access to User A's account, effectively taking ownership of the account.

I've sent a proof of concept: [REDACTED]

Impact:
Account Takeover

*Title:* Two-Factor Authentication Bypass via Support Ticket Creation in [admin.alwaysdata.com]

*Summary:*
A critical security vulnerability has been identified in the [admin.alwaysdata.com]'s account management system where a user with administrative privileges but mandated to use two-factor authentication (2FA) can bypass this requirement by initiating a support ticket under the name of the primary account holder without triggering 2FA.

*Description:*
This vulnerability allows an added user, who is supposed to be restricted by 2FA, to perform actions appearing as the primary account holder by submitting support tickets. This circumvents the security protocol intended to protect sensitive account operations via 2FA, potentially leading to unauthorized actions without the account holder's consent or knowledge.

*Steps to Reproduce:*
1. Create two user accounts, Account A (primary) and Account B.
2. From Account A, add Account B as another user with full administrative privileges but enforce 2FA on actions.
3. Log into Account B.
4. Navigate to the support section and initiate a support ticket, selecting Account A as the affected account.
5. Submit the ticket without being prompted for 2FA verification.

I sent a proof of concept : https://admin.alwaysdata.com/support/77431/367474-VID-20240423-WA0000.mp4

*Impact:*
The primary account holder's security is compromised as the added user can perform sensitive operations under their guise without completing the necessary 2FA checks. This vulnerability may lead to unauthorized access and control over the primary account's sensitive functions and data.

*Title:* Clickjacking (On-click) Vulnerability in Support Ticket Attachment Deletion in [admin.alwaysdata.com]

*Summary:*
The support ticket system of the web application is vulnerable to a clickjacking attack that allows an attacker to trick a user into deleting attachments from their support tickets unknowingly.

On-click Delete any attachment for users in support tickets Delete any attachment for users in technical support tickets

*Steps to Reproduce:*
1. Create a support ticket in the application.
2. Attach a file to the support ticket.
3. Obtain the direct link of the attachment and append the /delete/ command to the URL.
4. Create an HTML proof-of-concept file with the following content:

html

  <a href="https://admin.alwaysdata.com/support/----/delete/----">click</a>

5. Host this HTML page or send it via link to the victim.
6. Once the victim clicks on the disguised link, the attachment is deleted without their explicit consent or knowledge.

An attacker can use his location and attach an html file instead of sending a file that the user clicks on.

*Impact:*
The exploit enables unauthorized deletion of any attachment from user-created support tickets. This can result in loss of critical data and potential breach of information security, affecting data integrity and user trust.

This is in addition to this report as I explained in another way but I remembered now that the attacker had to delete any technical support ticket in the way I explained in this report
link: https://security.alwaysdata.com/task/24