Security vulnerabilities

# HTTP Parameter Pollution Lead to Crash the Website of admin.alwaysdata.com:

Hello Sir, I hope you are doing well. While, Researching on your domain, I found HTTP Parameter Pollution Lead to Crash the Website of admin.alwaysdata.com.

Steps to Reproduce:

1. Login into admin.alwaysdata.com.
2. Go to https://admin.alwaysdata.com/search/?q=1.
3. Input &q= after q=1
4. Input long string which is attached below in the report.
5. You can see that Chrome are crashed and not responding.

Impact:

When attacker can send this https://admin.alwaysdata.com/search/?q=1&q=longstring to any authenticated user, his/her browser was crashed for long time.

#Note:

Tested in Chrome, Mozilla and Microsoft Edge.

Thank You,

Waleed Anwar

Description:

There is a logic flaw in the permissions system. When a user is deleted through the /permissions/[id]/delete/ endpoint, the system does not properly check if the requester is allowed to delete that specific user.

By intercepting the request and changing the id value, a user can delete the main admin — even if they don't have permission to do so. This can lead to full account takeover if the attacker had added themselves earlier as a user

Steps to Reproduce:

1. Create a new account on alwaysdata with the following email:

 `ebrahimmagdy517@gmail.com`  

 (will be referred to as the **primary account** / Account A)

2. Inside the admin panel, go to:

 `https://admin.alwaysdata.com/permissions/`

3. Add a second email address as a team member/user:

 `testhackers663@gmail.com`  
 (will be referred to as (secondary account) / Account B)

4. Accept the invitation and activate Account B via the link received in email.

5. As Account A (ebrahimmagdy517@gmail.com), go to the Permissions panel again.

6. You will (see Account B) listed and a “delete” button next to it.

 However, you **cannot delete Account A (yourself)** — which is expected.

7. Use Burp Suite to intercept the deletion request for Account B, for example:

POST /permissions/402834/delete/

8. Modify the ID in the request to match Account A’s ID (e.g.,402812 ):

9.Send the modified request. (It will succeed), even though you are trying to delete the owner of the project

10. As a result:
- Account A is no longer part of the project and has lost access.
- Account B now fully controls the project/domain (`aqaqwq.alwaysdata.net`) including settings, databases, and any hosted files.

Impact:

An attacker can exploit an IDOR vulnerability to delete the main admin account by modifying the user ID in a delete request. This leads to:

  Full account and domain takeover

  Loss of access for the original owner

  Complete control over data, settings, and services

If an attacker gains temporary access to the admin’s email, they can add their own account, then remove the real owner — resulting in a critical security breach

Recommendation:

- Implement strict access control checks on the `/permissions/[id]/delete/` endpoint.
- Deny deletion requests for project owners, regardless of ID manipulation.
- Ensure server-side validation enforces user role & permissions.
- Consider using UUIDs or scoped IDs instead of numeric incremental IDs for more secure object references.

Proof of Concept (Video):

https://drive.google.com/file/d/1XMGLchHjj1Wl6EsgRPUZeniTexVCTJsb/view?usp=drive_link

Severity:Critical

Bug Theory
Server Security Misconfiguration happens when an app exposes sensitive functionality without proper controls. In this case, the platform allowed account deletion without any password confirmation, which is a clear misstep in authentication logic.

Even though the user is logged in, critical actions like deleting an account should always require re-authentication to prevent abuse via stolen sessions, CSRF, or insider misuse.

Step
Navigated to the Account Settings after logging in as a regular user.
Clicked on “Delete Account”.
✅ Expected : The application should prompt the user to re-enter their account password, or at least send an OTP/email confirmation before deleting the account.
❌ ActualThe account was deleted instantly without any verification — just a single click and the user data was gone.

That’s it. No alerts. No hesitation.

Business Context Impact
Because this platform is used to coordinate offline car transactions, accounts are tied to:

Active car listings
Buyer/seller chat history
Scheduled meetings or test drives
Deleting an account disrupts the entire transaction process, damages user trust, and may result in financial losses or wasted in-person efforts.

#Attacker Can Force to Stop Victim to Forget their Account Password in admin.alwaysdata.com.

Hello Sir, I hope you are doing well. While, Researching on your domain, I found Attacker Can Force to Stop Victim to Forget their Account Password in admin.alwaysdata.com.

Steps to Reproduce:

1. Go to https://www.alwaysdata.com/en/register/ for Signup.
2. Input Meow.bow+evil@domain.com.Burp Collab and then input password and click on submit to register your account.
3. Verify this account and after login and then logout from the account.
4. Register another account in https://www.alwaysdata.com/en/register/.
5. Input Meow.bow+evil1@domain.com.Burp Collab and then input password and click on submit to register your 2nd account.

6.After that verify your 2nd account in admin.alwaysdata.com.
7.Registering two account in admin.alwaysdata.com and then go to https://admin.alwaysdata.com/password/lost/ to forget their account.

8. Input first and second account email to forget their password but you can see that when you click on reset button it should say that email doesn't have account register.

Impact:

When victim register their account with email Meow.bow+evil@domain.com.Burp Collab and attacker know victim email then he/she can use abuse email Meow.bow+evil1@domain.com.Burp Collab to register the account, If victim forget their password and victim want to forget their password with https://admin.alwaysdata.com/password/lost/, victim lost their account can can't forget their account.

#Note:

Try to remove symbols in email to prevent from this.

Thank You,

Waleed Anwar

Description
Reflected cross-site scripting (or XSS) arises when an application receives data in an HTTP request and includes that data within the immediate response in an unsafe way.

Impact
It was observed that the web app was vulnerable to reflect based xss attack due to improper input validation.An attacker can steal a user’s cookies and download malware on their system, and many more attacking scenarios a skilled attacker can perform with XSS. E.g.: • Cookie stealing with Session hijacking • Malicious code injection • Advance phishing page with iframe technique • Stored XSS to Remote Code Execution

Recommendation
To remedy XSS vulnerabilities, it is important to never use untrusted or unfiltered data within the code of an HTML page. Filtering of untrusted data typically involves converting special characters to their HTML entity encoded counterparts (however, other methods do exist, see references). These special characters include: * `&` * `<` * `>` * `'` * `'` * `/`

Step 1: go to this url https://admin.alwaysdata.com/support/add/ step 2: the we going vulnerable parameter "Other participants" input field input the "><script>alert(document.domain)</script> then submit the from after that got XSS popup

Dear alwaysdata security Team,

My name is Vedant Tanaji Vhatkar. I’ve identified two critical vulnerabilities in your account system that may severely compromise user security and platform trust.

Observed Behavior: User accounts can be deleted without requiring password re-entry, SMS, email confirmation, or any second form of identity validation.

Steps to Reproduce:

Log into a valid user session.
Navigate to account deletion option.
Trigger deletion without further verification.
Account is deleted immediately or queued for deletion, with no challenge mechanism.
Impact (Attacker’s Perspective):

Attacker can delete accounts instantly after session hijack — no password or re-verification needed.
Account deletion erases forensic logs and obscures evidence of compromise.
Users lose access to warranties, devices, purchase history — often irreversibly.
Automated bots could mass-delete accounts, causing serious platform damage.
No confirmation step = silent victimization and loss of customer trust.
Recommendations:

Enforce password re-entry and multi-factor authentication for deletion.
Introduce a deletion grace period and notify users via email or SMS.
Log and alert users of deletion attempts across all devices

Video poc :https://drive.google.com/file/d/1pORDqY43T-GedPP_avOvlCqzU2MrM9AQ/view?usp=drive_link

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.

Description:
A stored XSS vulnerability exists in the support ticket submission functionality of the AlwaysData admin panel. An attacker can upload a specially crafted file (xss.poc) as an attachment while submitting a new ticket. When the ticket is submitted and the attached file is later opened by a staff member or user, malicious JavaScript embedded in the file is executed in their browser context.

This vulnerability allows attackers to perform actions such as stealing session cookies, executing arbitrary actions as the victim, or performing phishing attacks from within the trusted domain.

Steps to Reproduce:
Navigate to:
https://admin.alwaysdata.com/support/add/

Fill out the New Ticket form:

Title: Test XSS Ticket

Message: Please see the attached file.

Attach the malicious file xss.poc:

Submit the ticket.

After submission, navigate to the Support section and view the created ticket.

Click on the uploaded xss.poc attachment.

Result: A JavaScript alert box with the message XSS is triggered, confirming that the script executed in the browser.

Impact:
Arbitrary JavaScript execution in a user or admin context.

Session hijacking

Credential theft

Phishing within trusted domain

Full compromise of account integrity if an admin account is exploited

Recommendations:
Sanitize and validate all uploaded files both client-side and server-side.

Do not render or parse user-uploaded files as HTML or SVG content directly in the browser.

Use proper Content-Disposition headers to force downloads:

Affected Users:
All users or administrators who open ticket attachments through the admin panel.

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

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

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

PoC and screenshot included in the attached PDF report.

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

**How We Discovered**

Potential Impact

Blind SSRF

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

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

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

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

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

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

Steps to Reproduce:

1. Log in to your Alwaysdata admin panel.

2. Navigate to Emails → Outbound Logs.

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

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

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

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

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

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

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

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

haxorsistz+axorsistzhaxorsistzhaxorsistzhaxorsistzhaxorsistzhaxorsistzhaxorsistzhaxorsistzhaxorsistzhaxorsistzhaxorsistzhaxorsistzhaxorsistzhaxorsistzhaxorsistzhaxorsistzhaxorsistzhaxorsistzhaxorsistzhaxorsistzhaxorsistzhaxorsistzhaxoailrsistzh@gmail.com

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

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

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

Thank You,

Waleed Anwar

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

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

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

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

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

[remote "origin"]

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

Check other common Git paths:

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

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

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

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

For Nginx:
nginx
location ~ /\.git {

  deny all;

}

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

Rotate any exposed credentials or API keys, if applicable.

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

Description:

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

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

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

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

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

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

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

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

Intel Source:

IntelX and Telegram Monitoring

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

Impact

References:

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

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

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

https://www.infostealers.com/

- Implement mandatory credential rotation protocols.

- Thoroughly examine computing systems for any lingering malware presence.

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

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

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

- Disseminate information discouraging the installation of unverified software.

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

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

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

Hi Team,

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

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

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

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

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

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

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

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

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

Regards,
Ranjet

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

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

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

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

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

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

Regards,
Ranjeet

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Vulnerability Name: Email verification bypass on https://admin.alwaysdata.com/

Steps To Reproduce:
1. Create an account with attacker controlled email like nathanlion1983@gmail.com 2. Verify the email. Go to the accounts page https://admin.alwaysdata.com/admin/details/ 3. Now, change personal details and change the email to victim's email alexandrafredrique@gmail.com 
4. It will update the email without asking for any email verification this time, so the sign up is protected with email verification but the internal section doesn't ask for email verification before changing the email.
5. Now what an attacker can do is, add another user(controlled by him) or create access token in this account, and these will give him persistent access of this account, and whenever in future the user comes and uses the account after recovery the attacker will have access to the account with access tokens/the user added by him which has full access.

Proof Of Concept: (How can we add the screenshots as POC, we don't see any option to upload photos)

Impact: CVSS : 9.1Integrity & Confidentiality: attacker can do anything on this account impersonating the user which impacts confidentiality. Can also add things which will be consistent in the account, which results in persistent access which impacts integrity of the account.Similar email verification bypass reports are - https://hackerone.com/reports/617896 https://hackerone.com/reports/1040047 (but the mentioned reports doesn't have persistent access, these only demonstrate email verification bypass, thus our vulnerability is Critical and the mentioned are High)

Mitigation: The backend is trusting the email after email change, as the account was already verified  at account creation, but it needs to ask for email verification at the email change stage as well, otherwise no point putting email verification at registration.

To: Alwaysdata IT Security Team
From: Raden Adhiyaksa Indiharto
Date: June 9, 2025
Vulnerability: Sensitive Data Exposure

Dear Alwaysdata Security Team,

I hope this message finds you well. I am reaching out to responsibly disclose a security issue I have identified within your infrastructure that may pose a risk to your services and your users.

Vulnerability Summary During passive reconnaissance of your publicly accessible infrastructure, I discovered multiple sensitive API keys and service credentials exposed in plaintext, including:
1. Twilio ACCOUNT_SID and APP_SID values
2. Heroku API keys
3. Amazon AWS S3 bucket URLs

These secrets were found in a file named secret.txt on your domain (alwaysdata.com). The exposed credentials could potentially allow unauthorized access to third-party services, leakage of customer data, or resource abuse.

Steps to Reproduce 1. Access the Alwaysdata public directory.
2. Locate the file named secret.txt.
3. Run the following commands to filter sensitive credentials:

cat secret.txt | grep Heroku
cat secret.txt | grep twilio
cat secret.txt | grep aws

4. This revealed a number of API keys and identifiers, as shown in the screenshots I have attached to this report.

Suggested Remediation 1. Immediately remove the publicly exposed file or restrict access to it.
2. Revoke and rotate all exposed API keys (Twilio, Heroku, AWS, etc.).
3. Conduct an internal audit to ensure no unauthorized access has occurred using these credentials.
4. Consider implementing secret scanning tools in your CI/CD pipelines to prevent future exposures.

Additional Note At this point, no further exploitation has been carried out, and no services have been interacted with using the exposed credentials. However, if you require a deeper assessment or verification of the actual impact and exploitability, I am open to performing controlled testing with your permission.

Please advise if the investigation should stop at this discovery phase, or if you would like me to assist further in validating the scope of the exposure.

Disclosure Policy This report has not been shared publicly. I am committed to responsible disclosure and will not publish or use this information in any way that may harm your services or users. Please let me know if you need any further details or assistance in mitigating this issue.

Thank you for your attention, and I look forward to your response.

Kind regards,
Raden Adhiyaksa Indiharto

email: radenadhiyaksa89@gmail.com

Link Video, Image, and File PoC
https://drive.google.com/drive/folders/1pTvtlZmsxj9LIhyAwNnDN5ZRqGnweZs3?usp=sharing

Hi my name is Rehan and I discovered that the login endpoint at https://admin.alwaysdata.com/login/?next=/ doesn't have any sort of rate limiting in place.

This leads to account takeover of any user. You just have to know his/her email. That's the only prerequisite.

What I did:
1. I sent 50 login requests using intruder.

2. Set the intruder with fake 49 passwords and 50th being the correct password.

3. All requests go through without any error like too many requests, IP block or even temporary account lockout.

4. All 49 requests were processed with 200 OK implying that the password is wrong. However the 50th request gives a 302 error confirming the correct password.

IMPACT:
Account takeover:

This will give an attacker a way to send lot of requests and ultimately takeover the victim account when the response shows a 302 redirection.

I have read your stance on absence of rate limit on password reset endpoints as i read the tasklist. I know email flooding isn't really a big of a problem. However, I'm sending you this report because having no rate limit on login endpoint doesn't seem all too well. This is because having no rate limit on login leads to account takeover of any user.

It's not about flooding someone's inbox but actually taking over someone else's account. I hope you get my point here.

Recommendation:

1. Implement rate limiting after certain number of attempts. Give the user some time to try again like after 5 minutes.

2. Block the IP from sending more requests and send an automated message to victim informing him of login attempts.

#No email verification required when we change email from settings

Hello Team,

Issue:
When we try to signup with an email, it asks us for clicking a email validation link which is sent to our email, then we have to login, without clicking that link, we cannot login, but when we change email from user settings page/edit settings page, it doesn't asks us for validation..

Impact:
For example, a user creates an account with his email (user@example.com) and verifies it using the link which has been sent to his email, as he/she have access to user@example.com, but next he goes to settings and in email change mechanism, he can put any email like (president@whitehouse.gov) and no verification is required, and the user can login with that email and access his account with the email president@whitehouse.gov, and do some abusive or not good activities and the company will be blamed!

New steps to reproduce:
Go to profile settings
Enter any email
Submit settings → Account will be accessible without verification!

How to fix?
Email verification/validation should be required when a user changed email from user settings page..
I hope you'll fix it soon.

Thank You,

Waleed Anwar