All Projects

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.

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

No Rate Limit On Reset Password in admin.alwaysdata.com

welcome all :
i found that no rate limit in reset password in ::: https://admin.alwaysdata.com/password/lost/ Summary:
No rate limit check on forgot password which can lead to mass mailing and spamming of users and possible employees
A little bit about Rate Limit:
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.
Steps To Reproduce The Issue
1- create account and go to reset password
2- intercept burp and send request to intruder
3- make payload and start attack

Impact
1- Attacker could use this vulnerability to bomb out the email inbox of the victim.
2- Attacker could send Spear-Phishing to the selected mail address.
3-Causing financial losses to the company

unverified password change in [admin.alwaysdata.com]

Hello team!

I have found an interesting flaw where an attacker can change the account password without knowing the old password

When the user requests a password reset link, it accesses the activity log inside the account and this bug can be exploited by an attacker

Steps to reproduce the bug :

1-Create a new account on [admin.alwaysdata.com]
2-log in to your account
3-request the password reset link from another browser
4-you will notice that the password reset link you requested has arrived in the activity log

Impact :
If the attacker hijacks the session or gains access to the user account, he can request a password reset link and the link will reach him in the Account Activity Log, from which he can reset the account password without knowing the old password

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.

Security Report:Broken Access Control (BAC) refers to a security vulnerability where users are able to access or manipulate resources that they are not authorized to

Introduction:
Broken Access Control (BAC) refers to a security vulnerability where users are able to access or manipulate resources that they are not authorized to. In this report, we will discuss an instance of BAC where a user is able to delete a technical support ticket to which they have been invited, even though they do not have the necessary permissions to do so.

The user who is added to the ticket does not have the permission to delete the ticket, he is not the one who created it.

Command used to delete:https://admin.alwaysdata.com/support/"Ticket_Number"/delete/

Steps to reproduce the bug:

1- Open a technical support ticket
2- Add a user with you in the ticket
3- Try the delete order I sent you
4- You will notice that the invited user can delete the ticket completely and this is not his prerogative

Impact:
The impact of this vulnerability is significant as it compromises the integrity and confidentiality of the technical support system. Unauthorized deletion of tickets can lead to loss of important information, disruption of support services, and potential security breaches if sensitive information is contained within the tickets.