Security vulnerabilities

Hi team,

Any update to this report?

Thank you,

Hello,

We do not reproduce: when the student detach from the teach it only leaves the AAC program but all the access to its own accounts/profile are kept.

Could you give us a video with the whole process? From the creation of the student profile with the validations, the adding permissions to the detachment?

Hello,

Thank you for your reply.

As requested, I have prepared a full Proof of Concept (PoC) video demonstrating the vulnerability from start to finish. The video includes:

1. Creating a new account as a regular user.

2. Accessing the platform and verifying the normal permissions.

3. Exploiting the vulnerability using the referral-based academy join link.

4. Leaving the academy.

5. Showing how the permissions are lost (403 errors).

6. Demonstrating that the user cannot even submit a support ticket afterward.

POC: ticket 86747

Important note:
This vulnerability is not limited to students or teachers — it affects all user types, including standard users.
The attack does not require any special permissions and can be executed by simply sending a crafted link containing the victim's referral code.

Please let me know if you need anything else or further clarification.

Best regards,

I should have been clearer. We saw your ticket and tested your process - with a profile already created (who just attach its profile and give all rights to the teacher) and a profile created with the AAC and we never obtain this result.

Hello,

Thank you for your feedback.

It seems the scenario you tested differs from the actual one that triggers the vulnerability.
Allow me to clarify the impact more precisely:

This issue affects any regular user, whether they are a teacher, student, or even a user not involved with the AAC system.
The vulnerability does not require the AAC flow or any manual permission assignment.

—

Actual Exploitation Scenario:

1. The attacker obtains the victim's referral code.

2. The attacker sends the following modified link to the victim, using their referral code:
https://admin.alwaysdata.com/academic/attach/?teacher=<victim_referral_code>&attach

3. As soon as the victim clicks the link, they are silently added to their own academy — without any confirmation or notification.

4. If the victim then leaves the academy (manually or via this link:
https://admin.alwaysdata.com/academic/detach/), their account becomes nearly unusable:

Permissions: 403 Forbidden

Billing: 403 Forbidden

Subscription: 403 Forbidden

Support: Unable to open a ticket

Only basic personal profile edits remain accessible

—

This scenario does not follow the standard AAC flow — it is an abuse of the referral/academy invitation system using a modified link.
The attacker doesn’t gain access to anything, but can permanently disable another user’s account with a single click.

Please review the PoC video again, which demonstrates the full steps from account creation to permission loss.

Feel free to request an updated video or any further clarifications.

Best regards,

Hello,

I would like to add an additional clarification regarding my testing. I tried the same scenario on a teacher's account, and I was able to exploit the vulnerability on it as well. After the teacher clicked the modified referral link using their referral code, and then detached from the academy, all of their account permissions were disabled, similar to regular user accounts.

I am here if you need any further clarification.

Best regards,

I tested exactly what you are explaining: using https://admin.alwaysdata.com/academic/attach/?teacher=X&attach then detach manually and I still have the rights to my own profile. Please try again (with now profiles if yours are broken?)

Hello,

Thank you for your continued follow-up.

As requested, I have created a brand new account and repeated the exact steps again. The issue still occurs consistently.

Please find the updated PoC video attached. It clearly shows:

1. Creating a brand new account via the official registration form.

2. Logging into the admin panel.

3. Clicking on a self-generated referral link to join the academy.

4. Manually detaching from the academy.

5. Losing all access to core sections like:

Permissions

Billing

Subscription

Support (cannot open a support ticket)

POC:ticket 86747 401047-bandicam%202025-05-05%2018-47-49-636.mp4

All of these return 403 Forbidden, even though the user is the owner of the account.

This confirms the issue affects any regular user, not just those involved in AAC, and does not depend on account age.

Let me know if you need anything else or further clarification.

Best regards,

Hello,

I have tested the scenario using a student account created through the AAC system, and I granted full permissions to the teacher as you suggested.

After the student clicked on the modified referral link and then left the academy, they lost all of their account permissions — including access to billing settings, subscription, and support.

I’ve attached a video that clearly demonstrates the issue.

POC (5): ticket 86747

In conclusion, this vulnerability affects all users of the Alwaysdata platform — whether they are teachers, students, or regular users — and poses a serious risk to account integrity.

Please don’t hesitate to reach out if you need any further clarification.

Best regards,

We finally understood. You do not need two profiles, but only one. It's when you are using your own ID to subscribe/then detach to your own AAC program that you can face this situation. The report is qualified as invalid: the attacker is the victim.

Hello,

It seems there is some confusion regarding the scenario that was presented. I would like to confirm that the vulnerability was tested correctly, and the explanation provided clearly shows the method that leads to exploitation. Let me walk you through how this vulnerability works step by step.

1. Vulnerability Scenario:

The vulnerability occurs when the attacker sends a modified link (containing the victim's referral code) to the teacher, student, or even a regular user. Once the victim clicks on the modified link, they are automatically added to their own academy.

2. Role of the Attacker:

The role of the attacker in this scenario is to send the modified link to the victim. The attacker does not need to log in or have any special privileges; they only need to send the modified link to start exploiting the vulnerability.

3. What Happens When the Link is Clicked?

For the Teacher: When the teacher clicks on the link, they are added to their own academy but lose their teacher privileges. The teacher will be forced to leave the academy to regain their teacher privileges. However, in doing so, they will lose all account privileges. After leaving, they will not be able to access settings, billing, subscriptions, or technical support, effectively disabling their account.

For the Student: The student will face the same issue, but they will have to leave in order to return to their teacher's academy. In this case, they will be unaware that leaving will result in the loss of all their account privileges, including access to all services.

For the Regular User: The same applies to any regular user. Once they click on the link, they will be added to the academy and will find it illogical to join their own academy. They will be forced to leave, and upon doing so, they will lose all their account privileges.

4. Final Clarification: The victim (whether a teacher, student, or regular user) will not realize that leaving is the cause of losing their account privileges. In fact, they will believe that leaving is necessary to regain their previous privileges, but in the end, they will face a complete account disablement after leaving the academy.

5. Summary: The vulnerability does not require multiple accounts or a special academic flow. All the attacker needs is the modified link. The victim will be forced to leave the academy to restore their privileges, which will result in the loss of all their account privileges.

—

I hope this explanation clears things up. If there are any further questions or details that need clarification, I am always here to help.

Best regards,

Thanks a fix has been applied to better control the attachment to the AAC program. Could you validate it then come back to us via the support ticket?

Hello

I tested the scenario again after the update, and I can confirm that the vulnerability has already been fixed and the same exploit can no longer be performed as before.

Best regards,