All Projects

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

Steps to Reproduce:

1. Create a new support ticket.

2. Add another user to the same ticket.

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

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

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

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

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

Summary:
The OAuth implementation relies solely on bearer tokens (RFC 6750). Bearer tokens act like “keys to the kingdom” — anyone holding them gets full access. Without Proof-of-Possession (PoP) or sender-constrained tokens, a stolen token can be reused by an attacker from any device, IP, or session.

Steps to Reproduce:

Log in to the alwaysdata.com application and obtain a valid bearer access token (e.g., via browser dev tools).

Replay the same token from a completely different environment:

Another browser,

Another machine,

Or a proxy/intercepting tool.

Observe that the API/service still accepts the token without verifying the device, TLS channel, or binding key.

Impact:

Token Replay Attacks: Stolen tokens from XSS, CSRF, or insecure storage can be reused by attackers.

Session Hijacking: An attacker can impersonate users indefinitely until the token expires/revoked.

High-Severity Risk: Any token leak = full account compromise.

Severity:
High

Summary:
OAuth account linking occurs automatically and implicitly on the company's web application, without requiring user verification, which can enable account takeover. Suppose an attacker signs up using OAuth with the same email as an existing account (registered via email/password). In that case, they are granted access to that existing account without any ownership validation, which is a critical authentication flaw.

Steps to Reproduce:
Create a target account (victim):

Go to alwaysdata.com

Register a new account using email/password, e.g., victim@example.com.

Log out.

Trigger the issue (attacker):

Go to the website

Log in using an OAuth provider (e.g., Google or Apple) that uses the same email address: victim@example.com.

Observe:

The OAuth login automatically links to the existing account created via email/password.

No verification (like password prompt, email confirmation, or user consent) is required.

The attacker now has full access to the victim's account.

Impact:
This vulnerability allows an attacker to fully compromise accounts by using an OAuth provider with an email address matching an existing account, without needing the victim’s password or any verification step.

Possible consequences:

Unauthorized access to personal data.

Tracking information leakage

Service misuse or device control.

Breach of privacy and user trust.

Recommended Fixes:
Do not auto-link OAuth accounts based solely on email.

Prompt the user for verification when an existing account with the same email exists (e.g., via:

Password input,

Email confirmation,

Explicit linking process in settings).

Provide clear UI/UX for account linking that ensures user intent.

Suggested CVSS (3.1) Score:
8.8 (High)

Attack Vector: Network

Attack Complexity: Low

Privileges Required: None

User Interaction: None

Confidentiality Impact: High

Integrity Impact: High

Availability Impact: Low

Regards,
Mehedi Hasan

Note: I was awarded a $500 reward for the same vulnerability reported to some other companies. They marked this as valid and attempted to fix the bug.

Summary:
Revoking an application's access via the OAuth provider's settings should terminate the session in the main application. However, users are still logged in if the session remains active despite the OAuth disconnection.

Steps to Reproduce:
01. Log in to alwaysdata.com using Google OAuth.
02. Let's say an attacker hijacked your OAuth session, or you logged in to another device not owned by you and forgot to log out from there after using the account, and you wanted to destroy the OAuth session there.
03. Go to the Google OAuth provider’s settings from your Google account and revoke the application’s access.
04. You will see that, even after the OAuth provider disconnects, the session remains valid and doesn't terminate.

Mitigation:
If a user’s OAuth access is revoked, force the application session to require re-authentication using OAuth. This ensures unauthorized sessions cannot continue.

Impact:
This flaw allows users or attackers with an active session to retain access even after OAuth access is revoked, creating a significant security risk and bypassing expected session termination mechanisms.

## Note: I was awarded $300 by reporting the same issue to some other companies and they accepted it and fixed it.

Summary:
It is possible to remain authenticated in the application even after deleting the identity account (email/SSO provider) used to log in, resulting in a user session that continues to function despite the underlying identity no longer being valid. This breaks the identity-assurance model and may allow long-term unauthorized access.

Steps To Reproduce:
01. Create an account in the alwaysdata.com application using any email/password registration.
02. Log in successfully and confirm access to protected features.
03. While the session remains active, open a new browser/tab and permanently delete the associated identity account (e.g., delete the Google account/email used to register).
04. Return to the application and refresh or continue using your session.
05. Observe that the application continues to function normally and the user retains complete access.

Impact:
01. Allows long-term access for a user whose identity has been destroyed, violating ownership-based trust assumptions.
02. Increases risk of orphaned sessions or unauthorized access

Recommendation:
01. Implement continuous/periodic checks to verify that the backing identity still exists.
02. Invalidate all user sessions upon account deletion response from the identity provider.
03. Force re-authentication if account verification fails.

Best Regards,
NH Limon

Bug Report — Critical: Registration & Instance Creation — T&Cs / Consent Bypass

Target: https://admin.alwaysdata.com Endpoint(s): /register (web-form POST), root / POST (form that registers/creates instances)
Reported by: Ritanshu Sharma
Testing header: X-Bug-Bounty: SecurityTester-RitanshuSharma-2025
Date: (attach your submission date when sending)
IP: 106.219.120.29
Executive summary (one line)

A critical business-logic vulnerability allows account registration and instance provisioning to succeed without server-side enforcement of Terms & Conditions / consent fields (contract_28, contract_36). The frontend requires checkboxes but the backend accepts requests where those parameters are omitted, empty, or tampered — enabling automated mass account/instance creation and creating major legal/compliance exposure.

Vulnerability classification

Type: Business Logic / Missing Server-side Consent Enforcement

CVSS (reported): 7.5 (High)

Auth required: None

Attack complexity: Low

Root cause

Server-side registration/instance-creation logic does not enforce required consent fields. Frontend checkboxes exist but backend validation is missing or bypassable; consent is not consistently persisted or validated before provisioning.

Proof of Concept (PoC) — exact requests tested
PoC A — Working example (with consent fields included)

This is the valid POST observed (raw headers + body):

POST / HTTP/2
Host: admin.alwaysdata.com
Cookie: django_language=fr; csrftoken=QNCysyCKIwz2VXEOf5V7idzSdxTN5ZeM; sessionid=mfos2ihpy3jh3f0zjfm3tueo2puu3vd7
Content-Length: 164
Cache-Control: max-age=0
Sec-Ch-Ua: "Not)A;Brand";v="8", "Chromium";v="138"
Sec-Ch-Ua-Mobile: ?0
Sec-Ch-Ua-Platform: "Windows"
Accept-Language: en-GB,en;q=0.9
Origin: https://admin.alwaysdata.com Content-Type: application/x-www-form-urlencoded
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/138.0.0.0 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: navigate
Sec-Fetch-User: ?1
Sec-Fetch-Dest: document
Referer: https://admin.alwaysdata.com/ Accept-Encoding: gzip, deflate, br
Priority: u=0, i

csrfmiddlewaretoken=2ZMSUgXC1YtJ9HVJ7MPTF8OuUftCddUCICegcEpczkSBUupncHAQNbdcXCcf82Ye&product=2012&name=nehasharma&password=Hello%40123&contract_28=on&contract_36=on

PoC B — Exploit (omit consent fields)

Send the same request body but remove contract_28 and contract_36. Result: registration / instance creation still succeeds.

curl example (exploit):

curl -k -v -X POST 'https://admin.alwaysdata.com/' \

1. H 'Host: admin.alwaysdata.com' \
2. H 'Content-Type: application/x-www-form-urlencoded' \
3. H 'Cookie: csrftoken=QNCysyCKIwz2VXEOf5V7idzSdxTN5ZeM; sessionid=mfos2ihpy3jh3f0zjfm3tueo2puu3vd7' \
4. H 'Origin: https://admin.alwaysdata.com' \
5. -data 'csrfmiddlewaretoken=2ZMSUgXC1YtJ9HVJ7MPTF8OuUftCddUCICegcEpczkSBUupncHAQNbdcXCcf82Ye&product=2012&name=nehasharma&password=Hello%40123'

Observed behavior: The server responds as if registration succeeded (account/instance created). Screenshot and HTTP traces included in attachments.

Note: I used the csrftoken and sessionid values seen in the browser trace; exploit also succeeds when supplying a valid CSRF + session or when using other valid sessions in testing.

Additional tests to confirm scope

Submit POST from a curl client (no JS) — succeeds.

Submit POST with empty contract_28= or contract_36= — succeeds.

Submit POST to any other registration/instance endpoint (API or admin console) — behavior appears consistent (same lack of server-side consent check).

Check DB (see Audit queries) — many users exist without associated consent records.

Impact

Legal / Compliance: No recorded user consent → GDPR violations (no lawful basis under Article 6 for processing personal data), exposure to regulatory fines and complaints. Noncompliance with contractual terms can void protections.

Operational abuse: Automated mass account/instance provisioning → resource exhaustion, spam, abuse channels.

Business risks: Reputational damage, audit failures (SOC2/ISO27001), insurance/contractual risk, and potential litigation where users deny agreement to terms.

Reproduction evidence (attach when sending)

Screenshots of successful registration via exploit POST.

Video showing: form submission without consents → successful account/instance creation.

Raw HTTP request/response traces (attached).

Root-cause analysis (concise)

Frontend enforces checkbox UI but backend registration/instance creation handler(s) do not require or validate the presence/value of required consent parameters. Consent values are either not required for account creation, not stored, or not validated prior to resource provisioning.

Immediate remediation (apply within 24 hours)

Enforce server-side validation for required consent fields (contract_28, contract_36) in every code path that creates a user or provisions resources. If missing or false, return HTTP 400 with a clear error message. Do not proceed to create accounts or provision resources until consent is validated and persisted.

Persist consent records on acceptance: store {user_id, consent_key, consent_value, consent_version, timestamp, ip, user_agent, request_id}.

Temporarily enable rate-limiting + CAPTCHA on /register and any programmatic registration endpoints to reduce abuse.

Audit & quarantine: Identify accounts/instances created without consent; flag/quarantine them pending follow-up and retroactive consent collection.

Add monitoring/alerts for abnormal registration rates and missing consent storage events.

#Csrf Lead to remove Google auth from account

Hello Team, I hope you are doing well. I found Csrf Lead to remove Google auth from account in admin.alwaysdata.com.

Steps To Reproduce:

1. Login to admin.alwaysdata.co
2. Go to https://admin.alwaysdata.com/user/ and click on delete button and capture the request in burpsuite.
3. Make Csrf Poc and save in to csrf.html.
4. Send this request to another account which have Google Auth.
5. You can see that Google Auth is removed into second account.

Thank You,

Waleed Anwar

Severity: Medium – P3

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

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

Steps to Reproduce:

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

2. Create another user account (subscription).

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

4. Enable the requirement for 2FA before access.

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

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

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

Impact:

Unauthorized exposure of the owner’s domain names.

This may lead to internal infrastructure information leakage.

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

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

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

Summary: There is a problem with how AlwaysData handles email verification during account registration. After clicking the email verification link, the user is automatically logged in without needing to enter their email and password again. This is a security risk.

Steps to Reproduce: 1. Go to: https://www.alwaysdata.com/en/register/, as an attacker.
2. Register a new account using the victim's email address.
3. The victim will click the verification email that looks like this: https://admin.alwaysdata.com/user/validate/?user_id=...&token=...&expiration=… 5. After clicking the link, he will see a message that says: "Your registration is now validated, you can use all the services."
6. Now, the Attacker will click on the link that looks like: "I have validated my registration" and successfully log into the victim's account.
7. As the victim is directly logged into his account, he will not identify that someone has also logged into his account.

Issue: After clicking the email verification link, the website allows users to access their account directly. It does not ask for a password or login again. This means if someone else gets access to your email, they can take over your account without knowing your password.

Recommendations: 1. After clicking the email verification link, the user should be taken to the login page.
2. The system should ask the user to enter their email and password to log in.

POC: https://drive.google.com/file/d/17HZuLeTVPW52kIEH03C2xU-OWnOBFvZG/view?usp=sharing

#Account creation with invalid email addresses / email is accepting % and %0d%0a line termination chars

Hello Team, I hope you are doing well. While, Researching in your domain. I found Account creation with invalid email addresses / email is accepting % and %0d%0a line termination chars in your domain in admin.alwaysdata.com.

Summary:
Alwaysdata SignUp feature is misconfigured with email parameter. Email address parameter is accepting % and %0d%0a character along with genuine email address. Using this technique alwaysdata user account can be created but cannot be verified as there is not possible to verify those invalid email accounts. Basically random use of invalid email address, attacker can create multiple accounts.

Description:
As email address field always being verified with any special character (except @ and .) but here email is accepting % and line termination char %0d%0a

#Steps to Reproduce:

1.SignUp in admin.alwaysdata.com
2.Use email address adding with character like % or %0d%0a, account will be created and you will get account validation message.

3.Even if you try now to login using same above email and password then you will get same message for account validation and need to verify email.
4.You can not use the same invalid email again, as it will show an error of reuse of that invalid email address.

Impact
Garbage value can be stored in database using user account signup form
Multiple account can be created, just like if any use has real account with his email address, then also account can be created by adding %0d%0a or % char
Account is created using invalid email address, but can not be used.

Thank You,

Waleed Anwar

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.

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.

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

*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

Subject: Business Logic Flaw

Dear Security Team,

I trust this message finds you well in safeguarding our digital domain. I have successfully conducted a penetration test and am pleased to present the detailed findings in the attached report below.

Vulnerability Details:

Type: Business Logic Flaw
Severity: Medium
Vulnerable Endpoint: https://admin.alwaysdata.com/admin/account/add/ Description: The vulnerability enables attackers to bypass the restriction limiting the creation of only one Free Public Cloud (100MB). By exploiting this vulnerability, known as a race condition, an attacker can create more than 1 instances of the Free Public Cloud (100MB), potentially leading to resource abuse and unauthorized usage.

Reproduction Steps:
Log into the attacker’s account.
Remove all previous accounts from the attacker’s main account.
Attempt to add 2 Free Public Cloud (100MB), which will fail due to the existing function limitation.
To bypass this limitation, delete all Free Public Cloud (100MB) instances and capture the request to add a Free Public Cloud (100MB) using BurpSuite.
Duplicate the captured request in multiple tabs and modify the account names in each request.
Group all the requests and configure them to be sent in parallel (Single Packet Attack) in BurpSuite.
This will result in the addition of more than one Free Public Cloud (100MB).
Proof Of Concept:

Image & video-based POC is connected to the email.

Impact:

The impact of this vulnerability is significant as it allows attackers to bypass restrictions and manipulate the system to their advantage. By exploiting this flaw, attackers can create multiple instances of the Free Public Cloud (100MB), despite the intended limitation of only one. This can lead to several adverse consequences

Mitigations:
Increased resource usage and financial losses.
Risks of data breaches and damage to reputation.

NOTE: THESE ATTACKS HAVE BEEN DONE WHILE KEEPING SERVER’S SECURITY IN MIND, ENSURING THAT THE SERVER DOES NOT INCUR ANY DAMAGE. THIS ATTACK HAS BEEN PERFORMED WITH CAUTION.

Regards,
Zeeshan Beg

Google Drive POC Link : https://drive.google.com/file/d/1qz6s7g6l1dYsF1aq3PpAoIyzeodZTUBx/view?usp=sharing

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

Description

A vulnerability has been discovered in the student management system, which allows a normal user account to bypass access controls. ANY registered low-level user, with no knowledge or involvement in a class, can globally detach any student involved just by manipulating the UID. Even without tutorship/academic privileges and regardless of tutor access control.

Impact

A malicious attacker could fuzz predictable UID values and remove multiple students, abusing the privesc as a nuisance.

Proof-of-Concept

1) First, we logged in to an actual tutor account where I've added a few students. Next, I take note of the IDs of each student involved.

2) Then, I logged out and just to validate this exploit, I would create a NEW account.

3) This is the vulnerable endpoint:

https://admin.alwaysdata.com/academic/release/<USER_ID>

I replaced the <USER_ID> param with the various IDs I recorded from the tutor account.

4) Visit these URLs on the new account and observe the results.

5) Then, log out and re-login to the tutor account. Visit https://admin.alwaysdata.com/academic/ and confirm poc validity.

Mitigation

Implement proper access controls and role-based permissions to restrict normal users from utilizing global admin/tutor privileges. Conduct a thorough review of the authentication and authorization processes to ensure that no other similar vulnerabilities exist.

POC video: https://file.io/DRmuH2Qk7wZk