|
17 | Lack of password confirmation on account deletion | Closed | 19.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 | Closed | 05.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 | Closed | 26.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 | Closed | 04.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 ... | Closed | 26.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 ... | Closed | 13.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 | Closed | 26.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 | Closed | 22.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 | Closed | 03.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 ... | Closed | 16.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 | Closed | 13.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 | Closed | 23.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 | Closed | 25.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 | Closed | 22.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/ ... | Closed | 08.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
Remove access to the .git folder from the web, e.g. in webserver config or using .htaccess file
Review repository content considering all data compromised because it has been available in public for a while.
|
|
18 | .git file exposed | Closed | 18.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 | Closed | 27.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 | Closed | 15.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:
Username: projets_baltic
Password: LouisCelestin004@#
3. Successfully logging in grants full access to phpMyAdmin.
Proof of Concept (PoC):

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 | Closed | 25.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 ... | Closed | 04.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 | Closed | 17.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 | Closed | 29.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 | Closed | 04.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 | Closed | 17.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 | Closed | 25.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 | Closed | 09.06.2025 | |
|
108 | Email Enumeration | Closed | 26.11.2024 | |
|
41 | Directory Listing of Unauthorized Xapian Files | Closed | 27.03.2024 | |
|
107 | Directory Listing Enabled | Closed | 25.11.2024 | |
|
52 | Direct IP Access of the Domain on HTTP | Closed | 05.06.2024 | |
|
123 | Direct accessing Api on another Browser | Closed | 10.01.2025 | |
|
134 | CSRF TOKEN BYPASS WITH GET REQUEST | Closed | 04.03.2025 | |
|
137 | Critical Vulnerability Report- 1 | Closed | 15.03.2025 | |
|
115 | Credit Card Validation not occurring while signup throu ... | Closed | 04.12.2024 | |
|
48 | Clickjacking (On-click) Vulnerability in Support Ticket ... | Closed | 24.04.2024 | |
|
70 | ClickJacking Leads to deletion of user profile | Closed | 17.08.2024 | |
|
121 | Bypass the Session Expiration in admin.alwaysdata.com | Closed | 08.01.2025 | |
|
112 | Bypass rate limiting on reset password (possibly site-w ... | Closed | 27.11.2024 | |
|
74 | Bypassing Two-Factor Authentication via Account Deactiv ... | Closed | 02.09.2024 | |
|
103 | bxss | Closed | 25.11.2024 | |
|
38 | Bug Title: Prototype Pollution Vulnerability Report | Closed | 19.03.2024 | |
|
45 | Bug Title: Missing access control at password change. | Closed | 09.04.2024 | |
|
85 | Bug Report: XSS Vulnerability via File Upload | Closed | 24.10.2024 | |
|
104 | Bug Report: Vulnerability in User Addition Feature Lead ... | Closed | 25.11.2024 | |
|
159 | Bug Report: Unstyled XML Sitemap Response on Public End ... | Closed | 23.04.2025 | |
|
158 | Bug Report: Directory Traversal via Sitemap XML Referen ... | Closed | 23.04.2025 | |
|
106 | Bug Report: Broken Access Control on 2FA Leading to Pre ... | Closed | 25.11.2024 | |
|
125 | Bug: NPM Dependency Confusion Vulnerability. | Closed | 27.01.2025 | |
|
15 | Bug Bounty|User credential Leaked on Github-dork | Closed | 18.01.2024 | |
|
21 | Bug Bounty Report | Closed | 04.02.2024 | |