Security vulnerabilities

This is the security vulnerability reporting site for alwaysdata. Please make sure you read our bug bounty program before registering and creating a new task to submit a vulnerability you've discovered.

Once processed, the reports are public. Any private information can be transmitted via a support ticket on our administration interface.

ID Summary  desc Status Date closed
 17  Lack of password confirmation on account deletion Closed19.01.2024 Task Description

Hello support teams,
I hope this email finds you well. I am Devansh . I am a security researcher and I found a vulnerability in your website.

bug name : Lack of password confirmation on account deletion

Description: the user account can be deleted without confirming user password or re authentication.
The removal of an account is one of the sensitive parts of any application that needs to be protected, therefore removing an account should validate the authenticity of the legitimate user.

steps to reproduce:

1. Go to account settings and click on delete account.

2. There will be a next page where I click on delete my account now option.

3. You will see the message of account has been deleted and get logged out

Remediation:
System must confirm authentic user before performing such task. A link can be sent to the user email id that can be used for delete operation. Otherwise user password should be provided to the application to confirm the entity identity.

It seems to be of very low impact,but consider a situation when a user forgets to logout from his account or someone gets access to his phone and deletes the account. This situation is more severe than account takeover as there is no way to get an account again. All the save information and data including previous record, card information etc can be deleted.

video poc is attached

Thanks and regards
Devansh

https://

 53  Lack of Email Confirmation During Account Creation Closed05.06.2024 Task Description

Severity: High

Vulnerability Description:
The website allows users to create accounts without verifying their email addresses. This practice poses significant security and usability risks.

Impact:

Spam and Fake Accounts:

Malicious users can create multiple fake accounts, leading to spam and abuse of the platform.
Automated scripts (bots) can exploit this vulnerability to flood the system with fake accounts, overwhelming resources and degrading performance.
Account Security:

Unauthorized users can create accounts using someone else's email address, potentially leading to privacy breaches and unauthorized access to personal information.
Genuine users might be unable to access their accounts if their email addresses are misused by others.

Communication Failures:

Users may not receive important notifications, updates, or password reset instructions, leading to poor user experience and support issues.

Reputation and Trust:

The lack of basic security measures can lead to loss of trust among users and damage the website's reputation.
Users might perceive the platform as insecure and unreliable, leading to reduced user retention and engagement.
Steps to Reproduce:
Navigate to the account creation page.
Enter any email address (including ones that do not belong to the user) and complete the registration process.
Observe that the account is created and accessible without any email verification step.

Recommended Mitigation:

Implement Email Verification:

During registration, send a confirmation email to the provided email address containing a unique verification link.
Require users to click on the verification link to activate their accounts.
Use CAPTCHA:

Incorporate CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart) during the registration process to prevent automated bots from creating accounts.

Rate Limiting:

Implement rate limiting on the account creation endpoint to prevent mass account creation from the same IP address within a short period.

Audit Existing Accounts:

Review existing accounts for potential fake or unauthorized accounts and take appropriate actions, such as sending verification requests or disabling suspect accounts.

References:
OWASP Authentication Cheat Sheet: OWASP Authentication Cheat Sheet
NIST Digital Identity Guidelines: NIST SP 800-63B

 109  Issue with password change Closed26.11.2024 Task Description

Issue with password change

Hello Team, i hope you are doing well. While, researching in your domain, i found issue with password change bug.

When a password is changed in user's profile, then a notification about password change is sent to the user (email).
However, user not always gets a notification about password change - when a password is changed via password reset link, then such a notification is not send to the user. In your domain notification not sent to user, when he/she change the password in profile setting and with reset password.

Thank You,

Waleed Anwar

 114  Issue with password change Closed04.12.2024 Task Description

Issue with password change

Hello Team, i hope you are doing well. While, researching in your domain, i found issue with password change bug.

When a password is changed in user's profile, then a notification about password change is sent to the user (email).
However, user not always gets a notification about password change - when a password is changed via password reset link, then such a notification is not send to the user. In your domain notification not sent to user, when he/she change the password in profile setting and with reset password.

Note:

Second time i am reporting this issue to you, please make a test account and do that thing in your end so you clearly understand about it.

Thank You,

Waleed Anwar

 83  Issue: Application Allowing Old Password to be Set as N ...Closed26.10.2024 Task Description

Summary:
The application at https://admin.alwaysdata.com allows users to set their old password as the new password when resetting their password via the "Forgot Password" link. This weakens the security of the platform by not enforcing password uniqueness, which is crucial for maintaining account security, especially after a password reset.

Description:
When a user resets their password via the "Forgot Password" link, the application allows them to reuse their old password as the new password. This behavior reduces the effectiveness of the password reset process, which is meant to provide users with fresh, secure credentials. If the old password was compromised, allowing the user to reset it back to the same password negates the entire purpose of the password reset feature.

Steps to Reproduce:
1.Go to the login page of https://admin.alwaysdata.com and click on Forgot Password.
2.Enter your registered email address and request a password reset link.
3.Use the received password reset link to reset your password.
4.Enter your current/old password as the "New Password" in the password reset form.
5.Confirm the password reset.
6.Notice that the application allows the old password to be reused without any restrictions.

Impact:
Weakens Account Security: Reusing the old password negates the purpose of a password reset, especially if the old password was compromised. This significantly increases the risk of account compromise.
Non-Compliance with Best Practices: Regulatory and security guidelines, such as OWASP and NIST password standards, require that new passwords must differ from previous ones to enhance security.

Recommendation:
Enforce Password History: Track the user’s password history (e.g., the last 5 passwords) and ensure that the newly set password during a reset is not one of the previously used passwords.

 170  Insecure Cache-Control Leading to View Email and Passwo ...Closed13.05.2025 Task Description

# 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

 145  Insecure Account Removal Closed26.03.2025 Task Description

Summary:
Deleting accounts without proper credentials or verification can lead to unauthorized access, data loss, account takeovers, compliance violations, and legal penalties. It can also disrupt services, damage reputation, create audit gaps, increase fraud risks, and burden customer support. Proper security measures and verification processes are essential to prevent these issues.

Weakness: Improper Authorization and Broken Authentication (CWE-285)
Severity: High

Steps to Reproduce: -
1. Log in to your https://admin.alwaysdata.com/login/.
2. click on account profile.
3. Choose the "Delete this profile" option and there by click on submit .
4. Notice that there is no password confirmation required to proceed with the account deletion.
5. Confirm the account deletion request the account will be deleted without requiring the user to enter their password.

impact:
Deleting an account without a password or proper verification can have several serious consequences. Unauthorized deletions may result in legitimate users losing access to important data, files, or services, which can be difficult or impossible to recover. Data loss can be catastrophic for both individuals and organizations, especially if the account contained sensitive information or intellectual property. Additionally, if an attacker gains control and deletes the account, this could lead to account takeovers or impersonation attempts.

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

Thanks and regards,
spyhacker

 64  Insecure Account Deletion Closed22.07.2024 Task Description

Summary:
The removal of account is one of the sensitive part of a web application that needs to protect, therefore removing an account should validate the authenticity of the user, however i have found that when removing an account, the system did not require the user to input the account password.
Steps To Reproduce:
1.Create an account on https://alwaysdata.com
2.Go to My account section DELETE ACCOUNT.
3.Click on delete and you will see it will delete the account without any kind of verification or password confirmation.

Impact
Exploit Scenario: The user logins to a shared computer (office, library, cafe) Left the account open. Intruder came and try to delete the users account Intruder can easily delete the account because the system did not protect it by asking the password to validate that the person deleting the account is the real user.

Regards
Raghav Sharma

POC Link -: https://drive.google.com/file/d/1iu1gb0l44_sTqG2Ol-ZTbLc0ZKHYkO-f/view?usp=drive_link

 43  Information Disclosure PHPpgAdmin Closed03.04.2024 Task Description

Vulnerability Detail

PHPpgAdmin setup page is accessible over the internet in which it's possible for the user setup the servers with required details.

Vulnerable Endpoints

https://phppgadmin.alwaysdata.com/phppgadmin/redirect.php?subject=root You can add a server via this endpoint
https://phppgadmin.alwaysdata.com/phppgadmin/redirect.php?subject=server&server=&

Impact Its possible for an attacker to configure the servers without information of the application adminstrator.

 30  Information Disclosure on cAdvisor software via Origin  ...Closed16.02.2024 Task Description

Description

I discovered that cAdvisor, a container monitoring and management tool, is exposed to the public internet. Using OSINT techniques, this endpoint was discovered on one of the company servers. This information disclosure could potentially be used by attackers for various malicious purposes, such as mapping vulnerable targets or launching further attacks.

Proof-of-Concept

To demonstrate this issue, we can access the cAdvisor web interface via the URLs;
http://185.31.41.177:8000/containers/ http://185.31.41.177:8000/metrics/ http://185.31.41.177:8000/api/v1.0/machine http://185.31.41.177:8000/containers/user.slice http://185.31.41.177:8000/containers/system.slice

Browse through the URIs for more information on processes running, users involved, resource usage, container names e.t.c.

Mitigation

Restrict access to cAdvisor. Limit access to the cAdvisor interface to trusted users or networks only.

 47  information disclosure Closed13.04.2024 Task Description

i found this detial in one of the git file on https://security.alwaysdata.com/.git/config

and this file contains
0000000000000000000000000000000000000000 58bea729f4359a45f69aaba274bb2a931155b427 Cyril Baÿ cbay@alwaysdata.com 1704809861 +0100 clone: from https://github.com/flyspray/flyspray.git

this information in the master named file which i think is sensitive as it disclosing the email address and other stuff also
other files like config and packed-refs contain sensitive information , but its all on you to decide weather the information is sensitive or not
contact me on my email bhavishthakral123@gmail.com

 118  Hidden Matomo Tracking Opt-Out Endpoint Closed23.12.2024 Task Description

The endpoint is not publicly visible through the application interface but was discovered using search engine dorking techniques.

https://tracker.alwaysdata.com/index.php?module=CoreAdminHome&action=optOut&language=en

Low severity as it doesn't reveal sensitive server info

 187  Git Metadata Exposure on security.alwaysdata.com Closed25.06.2025 Task Description

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.

 35  Git Folder Forbidden Bypass Closed22.02.2024 Task Description

Hi,
During google search I have found an Open sensitive git directory.
Git metadata directory (.git) was found in this folder. An attacker can extract sensitive information by requesting the hidden metadata directory that version control tool Git creates. The metadata directories are used for development purposes to keep track of development changes to a set of source code before it is committed back to a central repository (and vice-versa). When code is rolled to a live server from a repository, it is supposed to be done as an export rather than as a local working copy, and hence this problem.
Vulnerable URL:-
https://upload.alwaysdata.com/.git/ (403 forbidden)
bypass
https://upload.alwaysdata.com/.git/config https://upload.alwaysdata.com/.git/logs/HEAD

https://security.alwaysdata.com/.git/ (403 forbidden)
bypass
https://security.alwaysdata.com/.git/config https://security.alwaysdata.com/.git/logs/HEAD

These files may expose sensitive information that may help a malicious user to prepare more advanced attacks.
Remove these files from production systems or restrict access to the .git directory. To deny access to all the .git folders you need to add the following lines in the appropriate context (either global config, or vhost/directory, or from .htaccess)
Thanks

 122  .git folder exposed at https://security.alwaysdata.com/ ...Closed08.01.2025 Task Description

https://security.alwaysdata.com/.git/config

[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

https://security.alwaysdata.com/.gitignore

flyspray.conf.php
img/veloz.png
attachments/*
/.idea/
/nbproject/*
vendor/*
composer.lock
composer.phar
/_site/
.htaccess
*.PHPEditProject
/avatars/*
/lang/*.php.bak
/lang/*.php.safe
.vscode/*
!.vscode/settings.json
!.vscode/tasks.json
!.vscode/launch.json
!.vscode/extensions.json

https://security.alwaysdata.com/.git/logs/HEAD

0000000000000000000000000000000000000000 58bea729f4359a45f69aaba274bb2a931155b427 Cyril Baÿ 1704809861 +0100    clone: from https://github.com/flyspray/flyspray.git
.gitignore
.travis.yml
LICENSE
README.md
SECURITY.md
includes/.htaccess
cache/index.html
fonts/index.html
caddy.dist
composer.json
...
...
themes/CleanFS/templates/reports.tpl
themes/CleanFS/templates/roadmap.text.tpl
themes/CleanFS/templates/roadmap.tpl
themes/CleanFS/templates/shortcuts.tpl
themes/CleanFS/templates/toplevel.tpl
themes/CleanFS/theme.css
themes/CleanFS/theme_print.css
themes/CleanFS/typography.css
themes/CleanFS/up.png
vendor/.htaccess

Conclusion

  • Git index allows accessing the files list and source code through .git/objects/
  • You can see the top of the list of files above
  • I haven't accessed those files' content because it's not necessary for the report according to the Responsible * Disclosure policy.
  • My assumption is that some of those files contain sensitive information, which can be used to escalate vulnerability.

Resolving suggestions

  1. Remove access to the .git folder from the web, e.g. in webserver config or using .htaccess file
  2. Review repository content considering all data compromised because it has been available in public for a while.
 18  .git file exposed Closed18.01.2024 Task Description

Hello support teams,

I hope this email finds you well. I am Devansh.I am a security researcher and I am writing to bring to your attention a security vulnerability that I have discovered on your website.

Report of bug is as follows:

Vulnerability name: .git file exposed

Website : https://security.alwaysdata.com/.git/config

Overview of the Vulnerability

The danger occurs when the application leaves the “. git” directory, which is in the system root, exposed. By carelessness, an application that uses Git for versioning can expose the “. git” directory.

Steps to Reproduce

1. open this website in the browser https://cdn.anscommerce.com/.git/config

2. you can see the git file is open

3 .by the dotgit extension you can download the git file

It can be exploited more but may cause harm to your website

Impact of the vulnerability

git folder is required to log every commit history and every other information required for your remote repository, version control, commits etc. These things are saved in different folders which have different meanings. Once the folder is created, open it and see the

References :

https://medium.com/stolabs/git-exposed-how-to-identify-and-exploit-62df3c165c37

https://www.acunetix.com/vulnerabilities/web/git-detected/

Please consider this as an urgent matter and prioritize the resolution of this vulnerability . if you require any additional information or assistance. Do let me know

Thank you for your attention to this matter, and I look forward to hearing from you soon.

Regards
Devansh

 42  Git Configuration Exposure Closed27.03.2024 Task Description

Vulnerability Git Configuration Exposure

Severity Level Critical

Vulnerable Domain:
https://upload.alwaysdata.com/.git/config

1. Executive Summary: The Git Configuration Exposure vulnerability poses a significant threat to web applications, allowing unauthorized access to sensitive source code repositories. Through the discovery of exposed .git/ directories, attackers can leverage this information to extract the complete source code of a website. This breach can result in the unauthorized disclosure of sensitive information, including proprietary code, configuration files, and other critical assets. This executive summary outlines the discovery, impact, and recommended mitigation strategies for this vulnerability.

2. Overview The vulnerability arises when an attacker identifies the presence of a .git/config directory. This discovery provides a direct route to the Git repository of a web application. By employing specialized tools such as those available in Kali Linux, an attacker can download the entire source code of the website, gaining access to proprietary code, scripts, and configuration files. The consequences of this exposure extend beyond the compromise of intellectual property to potential security risks and the unauthorized retrieval of sensitive information.

3. Vulnerability Discovery The vulnerability is discovered through directory research, where the presence of a .git/config directory is identified. Attempts to access this directory reveal the underlying Git repository, providing a pathway for unauthorized individuals to exploit the exposed version control system.

4. Impact Unauthorized Access to Source Code: Attackers can download the complete source code of the website, enabling the extraction of proprietary code, scripts, and configuration files.
Intellectual Property Theft: The compromise of source code poses a significant risk of intellectual property theft, potentially leading to unauthorized use or distribution.
Sensitive Information Exposure: The extracted source code may contain sensitive information, such as API keys, database credentials, and other critical data, compromising the overall security of the web application.

5. Mitigation Strategies

Git Configuration Hardening: Implement strict access controls and configure Git repositories to restrict access to authorized personnel only.
Directory Listing Prevention: Disable directory listing to prevent the exposure of .git directories during web server configuration.
Git Repository Hosting Security: If using third-party Git repository hosting services, ensure proper access controls are in place, and sensitive information is not exposed.

6. Steps To Reproduce:

1- Visit this URL = https://upload.alwaysdata.com/.git/config 2- You can see the Config file.
3- Using the gitdumper tool, in which I was able to dump the whole .git directory.
4- Boom!! I have access to the whole source code of the application.
4- Command
–> ./git_dumper.py https://upload.alwaysdata.com/.git/ your/any/directory/of/kali

Important Note: Another thing I'd like to share with you is that I haven't extensively exploited this vulnerability. Otherwise, I could have easily downloaded the entire website's source code, which often contains many and many sensitive information.

Proof of concept As you can see that I am able to access the entire source code. Now, if I put the output command to my command, I can download the whole source code.

[-] Testing https://upload.alwaysdata.com/.git/HEAD [200]
[-] Testing https://upload.alwaysdata.com/.git/ [403]
[-] Fetching common files
[-] Fetching https://upload.alwaysdata.com/.git/hooks/commit-msg.sample [200]
[-] Fetching https://upload.alwaysdata.com/.git/hooks/pre-commit.sample [200]
[-] Fetching https://upload.alwaysdata.com/.gitignore [200]
[-] Fetching https://upload.alwaysdata.com/.git/hooks/applypatch-msg.sample [200]
[-] Fetching https://upload.alwaysdata.com/.git/COMMIT_EDITMSG [404]
[-] https://upload.alwaysdata.com/.git/COMMIT_EDITMSG responded with status code 404
[-] Fetching https://upload.alwaysdata.com/.git/hooks/post-commit.sample [404]
[-] https://upload.alwaysdata.com/.git/hooks/post-commit.sample responded with status code 404
[-] Fetching https://upload.alwaysdata.com/.git/hooks/pre-push.sample [200]
[-] Fetching https://upload.alwaysdata.com/.git/hooks/pre-rebase.sample [200]
[-] Fetching https://upload.alwaysdata.com/.git/hooks/pre-receive.sample [200]
[-] Fetching https://upload.alwaysdata.com/.git/index [200]
[-] Fetching https://upload.alwaysdata.com/.git/info/exclude [200]
[-] Fetching https://upload.alwaysdata.com/.git/objects/info/packs [404]
[-] https://upload.alwaysdata.com/.git/objects/info/packs responded with status code 404
[-] Fetching https://upload.alwaysdata.com/.git/hooks/update.sample [200]
[-] Fetching https://upload.alwaysdata.com/.git/hooks/prepare-commit-msg.sample [200]
[-] Fetching https://upload.alwaysdata.com/.git/hooks/post-receive.sample [404]
[-] https://upload.alwaysdata.com/.git/hooks/post-receive.sample responded with status code 404
[-] Fetching https://upload.alwaysdata.com/.git/hooks/post-update.sample [200]
[-] Fetching https://upload.alwaysdata.com/.git/hooks/pre-applypatch.sample [200]
[-] Fetching https://upload.alwaysdata.com/.git/description [200]
[-] Finding refs/
[-] Fetching https://upload.alwaysdata.com/.git/info/refs [404]
[-] https://upload.alwaysdata.com/.git/info/refs responded with status code 404
[-] Fetching https://upload.alwaysdata.com/.git/ORIG_HEAD [404]
[-] Fetching https://upload.alwaysdata.com/.git/config [200]
[-] https://upload.alwaysdata.com/.git/ORIG_HEAD responded with status code 404
[-] Fetching https://upload.alwaysdata.com/.git/FETCH_HEAD [404]
[-] https://upload.alwaysdata.com/.git/FETCH_HEAD responded with status code 404
[-] Fetching https://upload.alwaysdata.com/.git/logs/HEAD [200]
[-] Fetching https://upload.alwaysdata.com/.git/packed-refs [200]
[-] Fetching https://upload.alwaysdata.com/.git/refs/heads/master [200]
[-] Fetching https://upload.alwaysdata.com/.git/refs/remotes/origin/master [404]
[-] https://upload.alwaysdata.com/.git/refs/remotes/origin/master responded with status code 404
[-] Fetching https://upload.alwaysdata.com/.git/refs/stash [404]
[-] https://upload.alwaysdata.com/.git/refs/stash responded with status code 404
[-] Fetching https://upload.alwaysdata.com/.git/refs/remotes/origin/HEAD [200]
Many More File will be Fatched…..!

 100  Full Privilege Access to phpMyAdmin on alwaysdata.com Closed15.11.2024 Task Description

Overview:
While conducting research on alwaysdata.com, I discovered sensitive credentials publicly exposed on a Telegram channel. These credentials provided direct access to alwaysdata’s phpMyAdmin instance, exposing database management functionalities that could lead to unauthorized data access, modification, or deletion. This issue represents a serious security risk, as it could enable malicious actors to compromise databases hosted on alwaysdata.

Steps to Reproduce:
1. Navigate to [https://phpmyadmin.alwaysdata.com/](https://phpmyadmin.alwaysdata.com/).
2. Use the following credentials found on the Telegram channel:

  1. Username: projets_baltic
  2. Password: LouisCelestin004@#

3. Successfully logging in grants full access to phpMyAdmin.

Proof of Concept (PoC):

![PoC](https://imgur.com/NZ33jM2.png)

Impact:
- Unrestricted access to phpMyAdmin allows any user to view, edit, or delete data within the accessible databases.
- Potential exposure of sensitive customer or internal data, which could result in data breaches.
- Elevates the risk of unauthorized database modifications, compromising data integrity and system security.

Remediation Suggestions:
- Immediately change the credentials for the affected phpMyAdmin user accounts and review logs for any unauthorized access.
- Implement IP or role-based access restrictions to phpMyAdmin to prevent unauthorized external access.
- Monitor and periodically audit for publicly shared or leaked credentials, especially on social media and messaging platforms.

Motivation for Reporting:
This report highlights the potential for data compromise on alwaysdata’s phpMyAdmin, as exposed credentials grant full access to manage sensitive databases. Addressing this issue will help alwaysdata protect its customers’ data and maintain the integrity of its hosted environments.

References:
- [OWASP Secure Credential Storage](https://owasp.org/www-project-proactive-controls/v3/en/c8-protect-data-everywhere)
- [NIST Guidelines on Access Control](https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final)

Please feel free to reach out if additional details or verification are required.

 160  Found a No Rate limit bypass on login form  Closed25.04.2025 Task Description

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

 149  Failure to invalidate sever after password change in We ...Closed04.04.2025 Task Description

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

 124  Failure to invalidate session after password change Closed17.02.2025 Task Description

Failure to invalidate session after password change

Hello Team,

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

Steps to Reproduce:

1.Go to https://admin.alwaysdata.com/mailbox/id/ and set a password and then submit.
2.Then, go to another browser and login into https://webmail.alwaysdata.com/?from_roundcube=1.
3.Again go to https://admin.alwaysdata.com/mailbox/id/ and then change the password and submit it.
4.You can see that session is still login in https://webmail.alwaysdata.com/?from_roundcube=1 and you can make any Changes in https://webmail.alwaysdata.com/?from_roundcube=1.

Impact
If attacker have user password and logged in different places, As other sessions is not destroyed, attacker will be still logged in your account even after changing password, cause his session is still active.. Malicious actor can complete access your account till that session expires! So, your account remains insecure even after the changing of password.

Thank You,

Waleed Anwar

 165  Exposed Private SSH Key in Public GitHub Repository Closed29.04.2025 Task Description

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


	
 148  Expired Encryption Key in Security alwaysdata.com Site Closed04.04.2025 Task Description

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,

 69  EXIF metadata not stripped Closed17.08.2024 Task Description

Summary: When uploading images in ticket option, the EXIF metadata is not removed or changed in any way.
Description: When answering in the ticket, you can upload a file, and if you upload an image with EXIF metadata on it, it isn't stripped. This can lead to disclosure of location where photo was taken or other personal information by the photo uploader if their group is public, as anyone can download the logo and check the metadata.
Steps To Reproduce:
1) Create a ticket.
2) Upload an image with exif metadata.
3) Now, download the same image and check the metadata.

Link to POC: https://drive.google.com/file/d/1KflN8xTcF6Gq-0x1wo-n65KkT9ScNHMl/view?usp=sharing

 81  Encoded XSS and SQL Injection in Registration Page Closed25.10.2024 Task Description

Hello Team,

I hope you are doing well. I found a Encoded XSS and SQL Injection In Registration Page Which is Redirecting to 500 Internal Server Error.

Steps:
1. Go to https://www.alwaysdata.com/en/register/ 2. Input Full Url Encoded XSS(%3c%73%63%72%69%70%74%3e%61%6c%65%72%74%28%31%29%3c%2f%73%63%72%69%70%74%3e)@mail.com in Email Address and then input password.

3. Click on Login Button.

It will redirect in 500 Internal Server Error.

Impact
Reflected XSS, An attacker can execute malicious javascript codes on the target application (email input specifically). It is highly recommended to fix this one because it is found in sensitive input (email).

Kind Regards.

Waleed Anwar

 175  Email Validation Bypass on AlwaysData Closed09.06.2025
 108  Email Enumeration Closed26.11.2024
 41  Directory Listing of Unauthorized Xapian Files Closed27.03.2024
 107  Directory Listing Enabled Closed25.11.2024
 52  Direct IP Access of the Domain on HTTP Closed05.06.2024
 123  Direct accessing Api on another Browser Closed10.01.2025
 134  CSRF TOKEN BYPASS WITH GET REQUEST Closed04.03.2025
 137  Critical Vulnerability Report- 1 Closed15.03.2025
 115  Credit Card Validation not occurring while signup throu ...Closed04.12.2024
 48  Clickjacking (On-click) Vulnerability in Support Ticket ...Closed24.04.2024
 70  ClickJacking Leads to deletion of user profile Closed17.08.2024
 121  Bypass the Session Expiration in admin.alwaysdata.com Closed08.01.2025
 112  Bypass rate limiting on reset password (possibly site-w ...Closed27.11.2024
 74  Bypassing Two-Factor Authentication via Account Deactiv ...Closed02.09.2024
 103  bxss  Closed25.11.2024
 38  Bug Title: Prototype Pollution Vulnerability Report Closed19.03.2024
 45  Bug Title: Missing access control at password change. Closed09.04.2024
 85  Bug Report: XSS Vulnerability via File Upload Closed24.10.2024
 104  Bug Report: Vulnerability in User Addition Feature Lead ...Closed25.11.2024
 159  Bug Report: Unstyled XML Sitemap Response on Public End ...Closed23.04.2025
 158  Bug Report: Directory Traversal via Sitemap XML Referen ...Closed23.04.2025
 106  Bug Report: Broken Access Control on 2FA Leading to Pre ...Closed25.11.2024
 125  Bug: NPM Dependency Confusion Vulnerability. Closed27.01.2025
 15  Bug Bounty|User credential Leaked on Github-dork Closed18.01.2024
 21  Bug Bounty Report Closed04.02.2024
Showing tasks 101 - 150 of 162 Page 3 of 4

Available keyboard shortcuts

Tasklist

Task Details

Task Editing