Security vulnerabilities

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

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

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

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

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

Description:

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

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

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

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

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

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

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

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

Intel Source:

IntelX and Telegram Monitoring

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

Impact

References:

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

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

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

https://www.infostealers.com/

- Implement mandatory credential rotation protocols.

- Thoroughly examine computing systems for any lingering malware presence.

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

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

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

- Disseminate information discouraging the installation of unverified software.

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

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

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

Vulnerability Title: LaTeX Injection via Billing Invoice Annotation Allows Server-Side Arbitrary File Read

Severity: Critical (CVSS 9.1)

Affected Endpoint: POST https://admin.alwaysdata.com/billing/annotate/

Summary

The billing annotation feature allows authenticated users to add text notes to their invoice transactions. This annotation is rendered into a PDF invoice using xelatex without any input sanitization or LaTeX command escaping. An attacker is able to inject LaTeX commands (such as \input{/path/to/file}) into the annotation field, causing the server to read arbitrary files accessible to the www-data user and embed their contents into the generated PDF.

Steps to Reproduce

1. Log into https://admin.alwaysdata.com with a valid account.
2. Navigate to Billing in the sidebar.
3. Ensure you have at least one transaction (add credit if needed to generate one).
4. Open the transaction and add an annotation with the following payload:

\input{/etc/hostname}
5. Save the annotation.
6. Download the invoice PDF for that transaction.
7. Open the PDF — the server's hostname (overlord-core) appears embedded in the invoice text, confirming server-side file read.

To read files containing special characters (underscores, hashes, dollar signs), use:

{\catcode`\_=12\catcode`\^=12\catcode`\#=12\catcode`\$=12\catcode`\%=12\input{/etc/passwd}}

This disables LaTeX's special character handling and includes the raw file content in the PDF.

Confirmed file reads:
- /etc/hostname → overlord-core
- /etc/machine-id → c23a410ea94a4695a56726c80307ad0e
- /etc/debian_version → 12.14
- /etc/passwd → all 42 lines of system accounts

And many more

Impact

- Arbitrary file read on the central management server (overlord-core) as www-data.
- Attacker can read Django application source code, configuration files, and potentially credentials stored under /data/www/production/.
- Any authenticated user (including free-tier accounts) can exploit this — no special privileges required.
- The annotation field has a 255-character limit, but \input{/path} payloads are short enough to fit easily.

Root Cause

In the invoice PDF template (invoice_pdf.tex), the annotation is rendered with autoescape disabled and no LaTeX-specific escaping:

{% autoescape off %}
transaction.annotations.first

The PDFAnnotationForm accepts any text in the annotation CharField with no validation or filtering of LaTeX commands. When _generate_pdf() is called, it runs xelatex -halt-on-error on the template, executing any LaTeX commands present in the annotation.

Remediation

1. Sanitize annotation input — strip or escape LaTeX special characters and commands (\, {, }, $, #, ^, _, %, ~) before saving the annotation. A whitelist approach (allow only alphanumeric + basic punctuation) is safest.
2. Use a LaTeX escape filter in the template — replace transaction.annotations.first with a custom |latex_escape template filter that escapes all LaTeX control characters.
3. Sandbox xelatex — run PDF generation with –no-shell-escape and disable \input/\include/\read/\openin commands via a restricted TeX configuration or by using –shell-restricted mode.
4. Run xelatex in a container with no access to sensitive files — mount only the template directory, not the entire filesystem.

Video Proof of concept is attached

Description:

The website lacks proper email verification.During the user registration process,it only sending a greeting email upon registration. The absence of email verification could lead to create unverified accounts and host content with any email address, potentially poses a serious security risk.

Impact :

The absence of email verification poses a significant security risk, allowing the potential use of any email address for registration on a hosting site without proper authentication. This could lead to the creation of accounts under false identities, enabling malicious actors to host illegal content anonymously.

The free hosting service, which doesn't require valid details, may be exploited for unauthorized activities, emphasizing the need for robust email verification procedures to ensure account legitimacy and prevent abuse like.

Spam distribution

Phishing campaigns

Distribution of illegal or harmful content

Reputational damage to the platform

So, I am Reporting this issue to the platform's security team for addressing the vulnerability and enhancing overall security.

### Summary
The website does not verify email addresses during the account creation process, which can lead to various security issues such as spam, abuse, and account recovery problems.

### Steps to Reproduce
1. Go to the account creation page.https://www.alwaysdata.com/en/register/ 2. Enter any email address and complete the registration process.
3. Notice that no email verification step is required.

### Impact
- Spam and Abuse: Unverified accounts can be used to flood the system with spam or perform malicious activities.
- User Impersonation: An attacker can use someone else's email address, leading to possible impersonation issues.
- Account Recovery Problems: Users might face difficulties in recovering their accounts if email addresses are not verified.

### Recommendation
Implement email verification as a mandatory step in the account creation process to ensure that the email addresses are valid and belong to the users registering them.

Summary:

A vulnerability was discovered where the delete account functionality lacks password confirmation and is vulnerable to GET-based CSRF, potentially allowing attackers to delete accounts without authorization.

Impact:

- Unauthorized account deletion
- Potential data loss
- Increased risk of account takeover

Expected Result:

- Password confirmation should be required to delete an account
- CSRF protection should prevent unauthorized requests

Actual Result:

- No password confirmation is required to delete an account
- GET-based CSRF vulnerability allows unauthorized account deletion

Steps to Reproduce:

1. Login to the application
2. Trick the user into clicking a malicious link to delete their account: https://admin.alwaysdata.com/admin/details/1/delete 3. User click submit
4. Observe the account being deleted without password confirmation

Recommended Fix:

1. Implement password confirmation requirement for delete account functionality
2. Implement CSRF protection for delete account functionality
3. Validate requests to prevent unauthorized account deletion

Conclusion:

This vulnerability poses a critical risk to user accounts and data. Implementing password confirmation and CSRF protection for delete account functionality will prevent unauthorized account deletion and ensure the security and integrity of user accounts.

Overview of the Vulnerability
User accounts are more susceptible to account takeover when there is no password confirmation on certain actions. For example, change of email address, change of password, management of Multi-Factor Authentication details, and account deletion.
The application lacks password confirmation on the delete account function which could be abused by an attacker who has access to the user’s account (eg. a public computer the user has not logged out of). From here the attacker could delete a user’s account.
## Business Impact
This vulnerability can lead to reputational damage and indirect financial loss to the company as customers may view the application as insecure.
## Steps to Reproduce
1. Enable a HTTP interception proxy, such as Burp Suite or OWASP ZAP1. Use a browser to navigate to: admin.alwaysdata.com 2. Use delete account functionality1. Intercept the request in a Web Proxy
3. Adjust and forward the following request to the endpoint:
4. Observe that no password confirmation is required

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

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

Vulnerable Assets
- Activity Log Module
- /log/{log_id}/detail/

Menu menus whose logs are accessible to limited access accounts:
1. https://admin.alwaysdata.com/site/configuration/ 2. https://admin.alwaysdata.com/domain/ 3. https://admin.alwaysdata.com/environment/ 4. https://admin.alwaysdata.com/advanced/log/

Vulnerability Type
Broken Access Control

Vulnerability Description
In the test scenario, there are two types of accounts:
- Account A: Full access (Admin/Owner)
- Account B: Limited access
By design, account B does not have permission to view the system audit logs. The log menu is not available in account B's UI. However, by manually adding the URL path, account B can still access certain log details. By accessing the endpoint: /log/{id}/detail/
Account B successfully views audit log information without any authorization validation on the backend. This indicates that access control is only implemented at the user interface (UI) level, not the backend API.

Sensitive data accessible to account B includes:
1. Actions (Create, Update, Delete)
2. Objects (modified resources)
3. Users (accounts performing the actions)
4. Resources
5. IP addresses
6. Date and time
7. Change details (Detail)

Reproduction Steps
1. Log in using account B (limited access).
2. Ensure the audit log menu is not available in the UI.
3. Access the URL directly, for example: /log/11032585/detail/
4. Audit log details are successfully displayed even though the account does not have permissions.

Security Impact
1. Leakage of Sensitive Information
2. Reconnaissance for Advanced Attacks
3. Violation of the Principle of Least Privilege

Recommended Improvements
1. Implement authorization validation in the backend for each audit log endpoint.
2. Ensure that only roles with appropriate permissions can:
View log lists and Access log details
3. Avoid relying on UI restrictions as the sole security control.

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

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

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.

An authenticated user with SSH access can enumerate all internal alwaysdata staff accounts, their root-group (GID=0) privilege assignments, and the internal role hierarchy via the NSS database. This is distinct from customer account names.

Vulnerable asset:
ssh://ssh-[account].alwaysdata.net
Files: /alwaysdata/etc/passwd (mode 644), /alwaysdata/etc/group (mode 644)

Root cause:
The custom NSS module (configured as "passwd: compat db alwaysdata" in /etc/nsswitch.conf) serves staff account entries to any authenticated user. The files /alwaysdata/etc/passwd and /alwaysdata/etc/group are world-readable.

Steps to reproduce:

1. Create a free hosting account on alwaysdata.com
2. SSH in:

  ssh [account]@ssh-[account].alwaysdata.net

3. Enumerate staff accounts:

  $ getent passwd | grep "/alwaysdata/home/"
  nferrari:x:501:0:nferrari:/alwaysdata/home/nferrari:/bin/bash
  cbay:x:502:0:cbay:/alwaysdata/home/cbay:/bin/bash
  xlefloch:x:503:0:xlefloch:/alwaysdata/home/xlefloch:/bin/bash
  hdegorce:x:506:0:hdegorce:/alwaysdata/home/hdegorce:/bin/bash
  ngeoffroy:x:508:0:ngeoffroy:/alwaysdata/home/ngeoffroy:/bin/bash
  fnonnenmacher:x:512:0:fnonnenmacher:/alwaysdata/home/fnonnenmacher:/bin/bash
  flesueur:x:513:0:flesueur:/alwaysdata/home/flesueur:/bin/bash

All 7 accounts have GID=0 (fourth field = root group).

4. Enumerate internal role hierarchy:

  $ getent group | grep "alwaysdata_"
  alwaysdata_team:x:500:cbay,hdegorce,ngeoffroy,nferrari,xlefloch,fnonnenmacher,flesueur
  alwaysdata_admins:x:501:nferrari,cbay,xlefloch,ngeoffroy,flesueur
  alwaysdata_support:x:502:hdegorce

5. Confirm files are world-readable:

  $ ls -l /alwaysdata/etc/passwd /alwaysdata/etc/group
  -rw-r--r-- 1 root root 440 Dec  9  2024 /alwaysdata/etc/passwd
  -rw-r--r-- 1 root root 187 May 21  2025 /alwaysdata/etc/group

6. Verify staff accounts are NOT public subdomains:

  $ host cbay.alwaysdata.net
  Host cbay.alwaysdata.net not found: 3(NXDOMAIN)
  $ host hdegorce.alwaysdata.net
  Host hdegorce.alwaysdata.net not found: 3(NXDOMAIN)

PoC script (run via SSH on any alwaysdata account):

  #!/bin/bash
  echo "[*] Staff accounts (GID=0):"
  getent passwd | grep "/alwaysdata/home/"
  echo ""
  echo "[*] Internal groups:"
  getent group | grep "alwaysdata_"
  echo ""
  echo "[*] Config file permissions:"
  ls -l /alwaysdata/etc/passwd /alwaysdata/etc/group
  echo ""
  echo "[*] NSS config:"
  grep "^passwd:" /etc/nsswitch.conf
  echo ""
  echo "[*] Subdomain check:"
  for u in cbay hdegorce fnonnenmacher; do host ${u}.alwaysdata.net | head -1; done

Scope clarification:
This is NOT "account names accessible in many ways." Staff accounts differ from customers:
- Separate namespace: /alwaysdata/home/ (not /home/)
- All have GID=0 (root group), customers do not
- Do not resolve as .alwaysdata.net subdomains (NXDOMAIN)
- Not listed on any public alwaysdata page
The sensitive data is the privilege level and organizational hierarchy, not names alone.

Impact:
- Identity correlation: username pattern (first-initial + lastname) enables targeted social engineering against specific administrators
- Privilege mapping: GID=0 confirms root-group access, identifying highest-value credential targets
- Authorization model disclosure: three-tier structure (5 admins, 1 support, 7 team) reveals internal access model

Qualifying category: "Exposure of Sensitive members information"

Suggested fix:
1. Filter staff entries from NSS responses for non-privileged users
2. Set /alwaysdata/etc/passwd and /alwaysdata/etc/group to mode 640 root:alwaysdata_team
3. Consider a separate NSS source for staff, not queried in customer sessions

#Insecure Cache-Control Leading to View Email, Password and User Information in https://www.alwaysdata.com/en/marketplace/ (All Applications).

Hello Team, I hope you are doing well. I found Insecure Cache-Control Leading to View Email, Password and User Information in https://www.alwaysdata.com/en/marketplace/ (All Applications).

Steps to Reproduce:

1. Go to https://www.alwaysdata.com/en/marketplace/.
2. Click on Install any application button you want to install.
3. Fill the form and submit the request.
4. It will go https://admin.alwaysdata.com/user/validation-needed/.
5. Press Back Button and you can see all of these information you are submitted these are shown in the form.

# 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, Firefox and Microsoft Edge.

Thank You,

Waleed Anwar

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

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

# Steps to Reproduce:

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

# Impact:

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

# Note:

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

Thank You,

Waleed Anwar

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

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

# Steps to Reproduce:

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

# Impact:

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

# Note:

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

Thank You,

Waleed Anwar

no 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

Description:
An insecure account deletion vulnerability has been identified on the AlwaysData admin platform. The application allows account deletion without requiring re-authentication or password confirmation, which can lead to unauthorized account deletion on shared or public devices.

Exploit Scenario:

A legitimate user logs into their AlwaysData admin account on a shared device (e.g., library, internet café, or office).

The user accidentally leaves the session open without logging out.

An attacker accesses the session and navigates to the following URL:
https://admin.alwaysdata.com/admin/details/

The attacker clicks "Delete this profile".

The system allows the deletion of the user account without requiring password re-entry or secondary confirmation, leading to account loss.

Steps to Reproduce:

Log in to your admin account at: https://admin.alwaysdata.com/

Navigate to: https://admin.alwaysdata.com/admin/details/

Click on the "Delete this profile" button.

Observe that no password or identity confirmation is required to proceed with account deletion.

Security Impact:
This lack of re-authentication introduces a critical security risk, especially on shared or publicly accessible machines. It allows any unauthorized person with temporary access to the session to delete the account permanently.

Recommended Mitigation:
Implement a re-authentication mechanism before executing sensitive actions like account deletion. This should include:

Prompting the user to re-enter their password.

Validating a session token or sending a secondary confirmation email/code.

This ensures that only an authenticated and intended user can perform account deletion.

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

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.

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.

step to reproduce:
1. go to https://blog.alwaysdata.com/wp-sitemap-users-1.xml

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