All Projects

# Summary:
The discovered vulnerability allows for the bypass of Two-Factor Authentication (2FA) mechanisms through the exploitation of leaked cookies. By intercepting and utilizing these cookies, an attacker can gain unauthorized access to user accounts without the need for the second authentication factor, compromising the security of the system.

# Steps To Reproduce:
1.Navigate to the account settings and enable 2FA.
2.Log out and log back in using valid credentials.
3.Enter the required 2FA code to proceed.
4.Export session cookies using a cookie editor tool.
5.Paste the copied cookies into another browser
6 Access the account without providing the 2FA code,2FA Authentication bypassed.

# Mitigation:
Introduce device-based Two-Factor Authentication (2FA) mechanisms that require additional verification steps when signing in from new or unrecognized devices, browsers, or locations. This adds an extra layer of security by verifying the identity of the user and the device being used for authentication.

# Impact:
The vulnerability allows attackers to bypass Two-Factor Authentication (2FA) mechanisms by stealing and utilizing session cookies obtained through various means, such as man-in-the-middle (MITM) attacks using tools like Evilginx2. By exploiting this vulnerability, attackers can gain unauthorized access to user accounts without the need for the second authentication factor, compromising the security of the system and potentially leading to unauthorized data access, fraudulent transactions, or other malicious activities.

Thank You,

Waleed Anwar

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

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

# Steps to Reproduce:

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

# Impact:

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

# Note:

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

Thank You,

Waleed Anwar

Hi Team,

I wish you a great day ahead, Please take time to review this report and let me know if there is anything I can help you with.

Summary:
A publicly accessible .git/config file has been discovered at https://security.alwaysdata.com/.git/config. This exposure may indicate that the entire .git/ directory is accessible, allowing for potential leakage of source code, repository metadata, internal configuration, and potentially sensitive information.

Proof of Concept (PoC):
1. Visit the following URL: https://security.alwaysdata.com/.git/config 2. The server responds with Git configuration details:

[core]

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

[remote "origin"]

  url = https://github.com/flyspray/flyspray.git
  fetch = +refs/heads/*:refs/remotes/origin/*

[branch "master"]

  remote = origin
  merge = refs/heads/master

3. Other files likely accessible:

.git/HEAD

.git/index

.git/logs/HEAD

.git/objects/ (may allow full repo reconstruction)

4. I was able to access the following links :
https://security.alwaysdata.com/.git/config https://security.alwaysdata.com/.git/logs/HEAD https://security.alwaysdata.com/.git/refs/heads/master

Security Impact:
1. Exposed .git/ directories can be exploited to:
2. Download the entire source code via tools like git-dumper or DVCS-Pillage.
3. Identify internal logic, vulnerabilities, or credentials.
4. Facilitate targeted exploitation by analyzing application internals.
5. This is a well-known vulnerability class and has been featured in multiple security advisories (e.g., NCSC CH advisory).

Recommendation:

• Immediately restrict public access to the .git/ directory using server configuration (e.g., .htaccess, nginx rules).

• Audit the repository history for any sensitive data accidentally committed.

• Monitor for any suspicious activity or exploitation attempts.

Disclosure Policy:
This report is submitted in good faith under your published Bug Bounty Program. Please let me know if additional details or testing are needed. I will not disclose this issue publicly without your explicit permission.

Thank you for your attention to this issue.

Best regards,
TheeHerbie

Vulnerability Description:

A vulnerability has been discovered in Alwaysdata's email management system that allows an attacker to retain an active Webmail session even after the associated email address has been renamed in the control panel. This issue enables unauthorized access to the previous email identity and settings, potentially allowing an attacker to maintain control without the new user's awareness.

—

Steps to Reproduce:

1. The attacker adds a custom domain (e.g., test.com) to their Alwaysdata account.

2. They create an email address like admin@test.com and log in to Webmail (webmail.alwaysdata.com), keeping the session active.

3. The attacker then goes to the control panel (admin.alwaysdata.com) and renames the email address to something else (e.g., info@test.com) and saves the changes.

4. Although admin@test.com no longer exists in the interface, its Webmail session remains active.

5. The attacker deletes the domain test.com from their account.

6. The Webmail session for admin@test.com is still valid, and the attacker can access and modify email settings.

—Proof of Concept (PoC) Provided: https://admin.alwaysdata.com/support/86544/

Impact of the Vulnerability:

Modification of email settings.

Wide-scale exploitation: The attacker can repeat the process with multiple domains, allowing them to gain control over different email accounts.

Recommendations to Fix the Vulnerability:

1. Terminate all active sessions immediately when an account is deleted or a domain is removed.

2. Link sessions to the user account instead of just the domain to ensure sessions do not transfer between different users.

This vulnerability poses a serious threat to user privacy and account security, and we strongly recommend fixing it as soon as possible.

Hello Team,

I hope you are doing well. While researching in your domain, I found User can Create Token after Disabling 2fa.

Steps to Reproduce:

1. Login into your account admin.alwaysdata.com
2. Go to Profile Section and enable 2fa for Generate Token.
3. 2fa is Enabled and now you can Generate a Token.
4. After then, Disable 2fa and don't refresh the page and don't logout from your account, you can click on Generate Token Button and if you can see that You can Generate Token after disabling 2fa.

Impact:

User Can Create Multiple token after disabling 2fa, which is the bypass of 2fa also.

Thank You,

Waleed Anwar

Title:
Website uses an outdated version of jQuery detected via Wappalyzer

Environment:

Device: PC / Laptop

Browser: Chrome (latest version)

Tools Used: Wappalyzer Extension

Steps to Reproduce:

1. Open [https://www.alwaysdata.com] in Chrome.

2. Open Wappalyzer extension while on the website.

3. Observe the version of jQuery listed.

Expected Result:
Website should use the latest stable version of jQuery to ensure security, performance, and compatibility.

Actual Result:
Wappalyzer reports that the website is using an outdated version of jQuery (e.g., jQuery 1.12.4 — released in 2016).

Impact:

Potential security vulnerabilities due to known exploits in older jQuery versions.

Compatibility issues with newer browsers or plugins.

Possible performance limitations.

Evidence:
(Screenshot from Wappalyzer showing the outdated jQuery version)

Recommendations:

Update jQuery to the latest stable release (currently [insert version number, e.g., 3.7.1]).

Test the website thoroughly after upgrading to ensure no functionality breaks

Hi Sir,

i am a Security researcher and a full time bug hunter i saw your bug
bounty program so i decided to test some vulnerability and i got No
Rate limiting on login form

here is the brief introduction of my bug please have a look

Severity = 6.5 to 7.5 (Medium to High)

(*) What is No Rate Limiting on the Login Form?

Rate limiting is a security measure that restricts the number of
requests a user can make to a server or system in a defined time
period. It helps mitigate brute force attacks by limiting the number
of login attempts a user can make in a short time frame.

When no rate limiting is applied to a login form, an attacker or
malicious user can send an unlimited number of requests, trying
various combinations of usernames and passwords. This could result in
unauthorized access or application-level denial of service (DDoS)
attacks if abused.

Overview of this Vulnerability During testing of the login functionality, I discovered a rate limiting bypass based on HTTP method manipulation. While the application initially enforced rate limiting when using the PUT method, switching the request method to PUT allowed me to bypass this protection entirely. Using the PUT method, I was able to send over 2,000 login requests without triggering any rate limiting mechanisms such as throttling, CAPTCHA, or account lockout. This confirms that the rate limiting controls are not consistently enforced across different HTTP methods. As a result, the application is exposed to brute force, credential stuffing, and denial-of-service attacks, allowing attackers to automate large-scale login attempts without restriction. Impacts

(1) Brute Force & Credential Stuffing Attacks:

Without rate limiting, attackers can try an unlimited number of
password combinations against the login form. This allows for brute
force or credential stuffing attacks, where an attacker can automate
the process of trying stolen or commonly used passwords for a given
username. With no restrictions on the number of login attempts, it
significantly increases the chances of gaining unauthorized access to
user accounts

(2) Account Takeover (ATO) Risk:

The absence of rate limiting makes it easier for attackers to gain
access to user accounts by attempting multiple password combinations.
Once an attacker successfully cracks a password, they can take over an
account and perform malicious actions, such as stealing sensitive data
or making unauthorized transactions.

(3) Denial of Service (DoS) or Application-Level DDoS:

The lack of rate limiting on the login form means that the server can
be overwhelmed with a high volume of requests. Attackers can flood the
login page with thousands of requests, leading to potential server
downtime or slowdowns. This can prevent legitimate users from
accessing the site, degrading the user experience and disrupting
normal service operations. It can also lead to increased server load
and higher operational costs.

(4) Increased Attack Surface for Automated Tools:

Automated tools like Burp Suite Intruder or Hydra can easily exploit
the lack of rate limiting, allowing attackers to test massive amounts
of login credentials in a short period of time. This increases the
risk of automated attacks, as attackers can use these tools to exploit
the vulnerability without manual intervention.

(5) Loss of Trust and Reputation:

If attackers are able to successfully break into accounts due to the
lack of rate limiting, it can lead to a loss of trust among users. If
users discover that their accounts can be easily compromised, it could
damage the reputation of the service or platform, leading to reduced
user engagement and retention.

Steps to reproduce (1) Navigate to the url https://translate.alwaysdata.com/login/?next=/ (2) Configure Burp Suite or any proxy tool (such as FoxyProxy in
Firefox) to intercept the HTTP request. (3) Attempt to log in with invalid credentials:
Submit a login attempt using incorrect username/password. Intercept this request and send it to Burp Repeater. (4) Send the same request multiple times in Repeater:
Continuously send the POST request.
After a certain number of requests, you’ll observe a 429 Too Many Requests response, confirming that the server has rate limiting in place for POST requests. (5) Modify the request method from POST to PUT in Repeater: Change the HTTP method from POST to PUT (keeping the same endpoint and parameters). Send the modified request and observe the 403 Bad Request response. (6)Send the modified PUT request to Burp Intruder: After modifying the method to PUT, send the request to Burp Intruder to test it with a wordlist.
Load a wordlist (e.g., Word.txt). (7) Send 2,000+ requests: I sent over 2,000 requests with invalid credentials and continued to receive HTTP 403 responses, confirming that rate limiting was bypassed and there were no restrictions for GET requests. (8) Observe Results: The system did not trigger any lockouts, CAPTCHAs, IP blocks, or delays between requests, confirming the absence of rate limiting on the PUT method. Proof of Concept (PoC)

i am providing some videos and screenshot of this vulnerability as proof of concept for this vulnerability

refer this link for all the pocs = https://drive.google.com/file/d/17NAxfE1BfyapBJuy3mCq01b47iBR3zCQ/view

I will be waiting for your reply team

Regards,
Sudo
Security researcher / Bug Hunter

URL:https://www.alwaysdata.com/en/sitemap.xml

🔍 Issue Summary:
The sitemap XML at the above URL is accessible but lacks associated XSL styling, causing the browser to display a raw XML tree with a message stating:

"This XML file does not appear to have any style information associated with it. The document tree is shown below."

💡 Expected Behavior:
The sitemap should either:

Include a reference to an XSL stylesheet to format the output for human readability, OR

Deliver plain XML without browser-rendered HTML or inline styles/CSS that could lead to unintended display artifacts.

📋 Actual Behavior:
The XML document is correctly structured and functional.

However, extraneous CSS code appears to be injected into the XML, potentially due to frontend theme/style conflicts or incorrect server handling.

🧪 Steps to Reproduce:
Navigate to https://www.alwaysdata.com/en/sitemap.xml in any browser.

Observe the browser warning about missing style information.

Scroll down to see unexpected CSS classes and style rules (e.g., .aifnmjmchg.light, :host([class=light])), which are not part of a standard sitemap file.

🧠 Root Cause Hypothesis:
The web server may be unintentionally injecting global CSS or theme-related JavaScript/CSS into all responses, including .xml files.

This could be a misconfigured template handler or inclusion of global styles across all content types.

🎯 Suggested Fix:
Ensure that the sitemap endpoint delivers pure XML with proper MIME type (application/xml) without CSS injection.

Optionally, provide an XSL stylesheet for better browser presentation if needed.

Review middleware or template rendering logic that might be appending global assets to all responses.

✅ Impact:
SEO crawlers are likely unaffected.

However, human readability is degraded, and it may hint at larger asset delivery misconfigurations.

Potentially impacts maintainability, developer trust, or bug bounty program quality.

Bug Name:
Directory Traversal through Sitemap Schema Reference

Severity:
Medium to High (Information Disclosure)

URL Affected:
https://www.alwaysdata.com/en/sitemap.xml → references → http://www.sitemaps.org/schemas/sitemap/0.9 → references → https://www.ietf.org/rfc/

🔁 Steps to Reproduce:
Go to https://www.alwaysdata.com/en/sitemap.xml.

View the linked schema:

<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
Open the namespace URL: http://www.sitemaps.org/schemas/sitemap/0.9

From that page, locate and visit: https://www.ietf.org/rfc/

Observe that the directory listing is enabled on https://www.ietf.org/rfc/.

🧾 Observed Behavior:
The https://www.ietf.org/rfc/ URL is openly listing all files in the directory, including:

PDF documents

HTML versions

JSON files

File sizes and last modified dates

✅ Expected Behavior:
Directory listing should be disabled to prevent information disclosure.

The endpoint should return a 403 Forbidden or a custom error page.

📌 Impact:
Unintended information disclosure through exposed documents and file structures.

Can help attackers understand server structure or gather sensitive metadata.

May affect trust if directory listing is not intended behavior.

poc :

https://drive.google.com/file/d/198YaCBfL4Zn8iAtGN3FdHPg3-JMt-4Q0/view?usp=sharing

Vulnerability Name:

Category:

Risk Level:

Description:

$df -h | grep /home
http16.paris1:/username         3.4T  2.6T  873G  75% /home/username
http14.paris1:/username            3.4T  494G  3.0T  15% /home/username
http13.paris1:/username            3.4T  2.5T  994G  72% /home/username
...

Impact:

Recommendation:

References:

Vulnerability Summary
Title: Privilege Escalation via Unvalidated Invitation Deletion Leading to Unrestricted Account Creation

Severity: High (Potential Impact: Unauthorized Account Proliferation, Bypass of Email Verification)

Vulnerability Type: Logic Flaw / Privilege Escalation

Affected Functionality: User Invitation & Account Registration System

Detailed Vulnerability Description

1. Vulnerability Discovery
While testing the privilege escalation mechanisms on admin.alwaysdata.com, I investigated the account invitation system. The process involves:
- Creating an account using my primary email: akashghoshakg19@gmail.com
- Inviting a secondary email: akashghoshakg19+6@gmail.com (Gmail alias)

2. Unexpected Behavior Observed
After sending the invitation, I deleted the invitation before the secondary email accepted it. However, the invitation link remained functional, allowing the secondary account (akashghoshakg19+6@gmail.com) to successfully register.

How can i sure that

Well, when i deleted my secondary account (akashghoshakg19+6@gmail.com),it sends an confirmation email to my main accout (akashghoshakg19@gmail.com) which shows in the attached video POC.

3. Impact Analysis
- Bypass of Email Verification: The system does not properly invalidate deleted invitations, allowing unauthorized account creation.
- Unrestricted Account Proliferation: An attacker can exploit this flaw to create multiple accounts without proper validation checks.
- Potential Abuse Scenarios:

1. Spamming the platform with fake accounts
2. Bypassing rate limits or sign-up restrictions
3. Conducting fraudulent activities under multiple identities

### 4. Proof of Concept (PoC)
Steps to Reproduce:
1. Register an account with: `akashghoshakg19@gmail.com`
2. Invite a secondary email: `akashghoshakg19+6@gmail.com`
3. Delete the invitation before the secondary user accepts it.
4. Observe that the invitation link still works, allowing `akashghoshakg19+6@gmail.com` to register.
5. Check the primary email (`akashghoshakg19@gmail.com`) – it receives a confirmation, but the system fails to enforce proper validation.

Evidence:

The video POC link: https://drive.google.com/file/d/1VmByRPCRfixrQvDWKmMnRO9KAJjT2GzB/view?usp=sharing

Security Impact
- Privilege Escalation Risk: Attackers can create multiple accounts without proper verification.
- Account Takeover Potential: If combined with other flaws, this could lead to unauthorized access.
- System Abuse: Malicious users can exploit this to evade detection and launch attacks.

Recommendations for Fix
1. Immediate Invalidation of Deleted Invitations:

1. Ensure that once an invitation is deleted, the associated link is immediately invalidated.

2. Strict Session & Token Validation:

1. Implement server-side checks to verify invitation status before allowing registration.

3. Rate Limiting & Monitoring:

1. Enforce stricter rate limits on account creation to prevent mass exploitation.

4. Email Verification Enforcement:

1. Require fresh verification for all invited accounts, regardless of invitation status.

Conclusion
This vulnerability allows bypassing critical security checks in the account registration process, leading to privilege escalation and potential system abuse. Immediate remediation is recommended to prevent exploitation.

Two critical vulnerabilities were identified in the `admin.alwaysdata.com` panel:

1. Broken Access Control via browser back-navigation (Alt+←), exposing sensitive user data post-logout.
2. CSRF (Cross-Site Request Forgery) via a GET request that allows unauthorized deletion of user accounts.

—

### 🧪 Steps to Reproduce

#### 🐞 Part 1: Broken Access Control via Browser Back Navigation

1. Login to the application: [https://admin.alwaysdata.com](https://admin.alwaysdata.com)
2. Navigate to user details:

 Example:  
 `https://admin.alwaysdata.com/admin/details/384337/deletee/`

3. Logout from the application.
4. Press Alt + Left Arrow (or use browser back button).
5. ⚠️ Result: The previously authenticated page is shown again, leaking sensitive user information (even though the user has logged out).

Impact: An attacker who gains temporary access to the session or has physical access to the system can access previously authenticated content even after logout.

—

#### 🐞 Part 2: CSRF - Account Deletion via GET Request

The following endpoint allows account deletion via a GET request, making it vulnerable to CSRF.

##### 🔓 CSRF Exploit HTML

```html

  <body onload="document.forms[0].submit()">
    <form action="https://admin.alwaysdata.com/admin/details/384337/delete/" method="GET">
      <input type="hidden" name="reason" value="Testing CSRF exploit" />
    </form>
  </body>

```

#### Steps:

1. Host this HTML file on any domain under your control.
2. Send the link to a logged-in admin user (victim).
3. When the victim clicks the link, the page auto-submits a GET request to:

 ```
 https://admin.alwaysdata.com/admin/details/384337/delete/?reason=Testing+CSRF+exploit
 ```

4. If he /she click the delete button it will be deleted.

—

### 💥 Combined Impact

By chaining these two issues, an attacker could:

- Extract sensitive data via broken access control (using back-navigation after logout).
- Delete user accounts via CSRF without authentication or confirmation.

—

### 🔐 Recommended Fixes

1. Fix Broken Access Control:

1. Invalidate cached pages using proper cache-control headers:

```http

   Cache-Control: no-store, no-cache, must-revalidate
   Pragma: no-cache
   ```
 - Implement server-side checks to reject requests after session termination.

2. Fix CSRF in Sensitive Actions:

1. Use POST requests for state-changing actions (like deletion).
2. Implement CSRF tokens and validate them on every form submission.

—

POC Link: https://drive.google.com/file/d/1BSTP_m8nxiP4h-bQIq9OsiCRmYlBJuaO/view?usp=sharing

no task description

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.

#2FA is not Initiating on User Account

Hello Team, I hope you are doing well. While Researching in your domain I found 2Fa is not Initiating on User Account in your domain.

Steps to Reproduce:

1: Create a account in admin.alwaysdata.com.
2. Initiate 2fa on your account.
3. Go to Permission Section Add a Email in email Section and Check the 2fa Required box and make some Global Permission you want to proceed and then submit.

4. User receive Profile Initialization in your email, User can fill the form and then submit the form, he/she directly login on o your account without any 2fa Initialization in which administrator can check the 2fa required box.

Impact:

Administrator can imagine he/she initiate 2fa requirement on user account but 2fa is enabled on user account. User can easily access their account and admin permission without 2fa prompting.

Thank You,

Waleed Anwar

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

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,

Hi,
Notification from Flyspray (Registration on security.alwaysdata.com) - Email from security@alwaysdata.com - Marked as SPAM by Filters
(the title had a character length limit)

Repro steps:
Register on your Security site https://security.alwaysdata.com using Gmail.
Receive email titled 'Notification from Flyspray' with 'confirmation code' from Security vulnerabilities security@alwaysdata.com Find this in SPAM folder with warning from Gmail about SPAM

POC:
Mentioned message found in SPAM folder.
On the gray background 'Why did this message go to Spam? The message is similar to those detected by our spam filters.'

It is at least reputation damage.
Makes communication difficult and may prevent the reporting (registration) of security issues.

References:
https://support.google.com/mail/answer/1366858?hl=en OWASP Top Ten 2013 Category A5 - Security Misconfiguration https://cwe.mitre.org/data/definitions/933.html https://cwe.mitre.org/data/definitions/815.html

PS. Can show a screenshot (POC), but can not see here image upload.

Best regards,

Vulnerability Description:

A vulnerability was discovered in Alwaysdata's domain and email management system, allowing an attacker to maintain an active session even after deleting their account. This vulnerability can be exploited through email domain reuse in Webmail, enabling an attacker to gain access to newly created email accounts without needing to steal login credentials.

Exploitation Steps:

1. The attacker adds the domain evil.com to their Alwaysdata account.

2. They create an email address admin@evil.com via Webmail (webmail.alwaysdata.com).

3. The attacker logs into Webmail and saves the session.

4. They delete their Alwaysdata account, but the Webmail session remains active.

5. A new user adds evil.com to their Alwaysdata account and creates the same email admin@evil.com.

6. Once the new user logs into Webmail, the attacker still has access to the email since their session remains active!

Proof of Concept (PoC) Provided: https://admin.alwaysdata.com/support/85071/

Impact of the Vulnerability:

Modification of email settings.

Wide-scale exploitation: The attacker can repeat the process with multiple domains, allowing them to gain control over different email accounts.

Recommendations to Fix the Vulnerability:

1. Terminate all active sessions immediately when an account is deleted or a domain is removed.

2. Link sessions to the user account instead of just the domain to ensure sessions do not transfer between different users.

This vulnerability poses a serious threat to user privacy and account security, and we strongly recommend fixing it as soon as possible.

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

SUMMARY:
As a cybersecurity and darknet researcher, I have discovered a critical security vulnerability in the webmail.alwaysdata platform. The site lacks Two-Factor Authentication (2FA), meaning that if an attacker obtains a user's password, they can gain access without any additional security verification. During my investigation, I also discovered 100 sets of credentials on the dark web, further underscoring the ease with which attackers can exploit this vulnerability. An attacker can use these leaked credentials to log into the webmail portal without any further checks, exposing sensitive internal data such as customer support tickets, billing information, and inventory details, and potentially leading to the defacement of user accounts and unauthorized modifications to administrative settings.

AFFECTED SYSTEM:
Webmail Data Portal (webmail.alwaysdata)

IMPACT LEVEL:
CRITICAL

ATTACK VECTOR:
The absence of 2FA allows attackers to log in using stolen credentials without any additional verification. Once inside, they can manipulate administrative settings and access sensitive information, including user-created support tickets and billing details. The ease of unauthorized access significantly heightens the risk of data exfiltration and system manipulation.

STEPS TO REPRODUCE:

  Use leaked credentials

   https://webmail.alwaysdata.com:younes@alwaysdata.net:MOLImoli1
   https://webmail.alwaysdata.com/:tayssir@alwaysdata.net:Fvdptr87
   https://webmail.alwaysdata.com:eliu@tijuana.ml:2Tekilas

(one of the 100 sets discovered on the dark web) to access the webmail portal.

  Observe that no 2FA is required, granting immediate and unrestricted administrative access.

IMPACT ANALYSIS:

  Confidentiality Impact:

      Unauthorized access to sensitive internal data, including customer support tickets, billing information, and inventory details.

      Exposure of sensitive contractual agreements and cloud infrastructure details.

      Potential for exfiltration of confidential business information, leading to financial and reputational harm.

  Integrity Impact:

      Unauthorized modifications to administrative settings, disrupting normal business operations.

      Manipulation of support ticket data, resulting in miscommunication and incorrect troubleshooting.

  Availability Impact:

      Alteration or deletion of inventory records.

      Data loss and operational downtime, causing prolonged recovery efforts and increased costs.

RECOMMENDATIONS:

  Immediate Mitigation: Revoke compromised credentials and enforce a company-wide password reset. Restrict access to the webmail portal to authorized personnel only.

  Implement Mandatory 2FA: Enforce Two-Factor Authentication for all accounts, with priority given to administrative access.

  Access Control: Apply the principle of least privilege and implement role-based access controls.

  Device Security: Restrict unauthorized device registrations and enforce strict device security policies.

Reported by: Vikash Gupta
Severity Level: Critical
Status: Pending Review
Priority: High
Overview

A Personal Identifiable Information (PII) exposure vulnerability allows unauthorized access to sensitive user data, including names, email addresses, phone numbers, and other personal details. This flaw puts user privacy at risk and may lead to identity theft, phishing attacks, and legal compliance violations.
Vulnerability Details

  Feature Affected: User Data Storage & Retrieval
  Vulnerability Type: PII Information Disclosure
  Description:
      Due to misconfigured access controls, insecure API responses, or improper data exposure, sensitive user data is accessible to unauthorized users.
      Attackers can extract PII from API endpoints, public web pages, or logs without authentication.
      The leaked information may include full names, email addresses, phone numbers, addresses, or other personally identifiable data.

Step to reproduced :-
Dear alwaysdata.com Team

Sir I'm Vikash Gupta & I'm Security Researcher. I found { User PII Information Leaked } Vulnerability in Your Website.

Vulnerable URL :- https://security.alwaysdata.com/task/137

STEP TO REPRODUCED :-

1- Go to Vulnerable Url :- https://security.alwaysdata.com/task/137 2- Scroll Down & You see {User Paypal ID is Leaked in Report}
3- Fix It Immediately.

BOOOOM! I hope You fixed this issue quickly.

Impact Assessment

  Security Risks:
      Identity Theft: Exposed PII can be used for fraudulent activities.
      Phishing & Social Engineering Attacks: Attackers can craft targeted scams using leaked data.
      Financial Risks: Exposed financial details can lead to fraud or unauthorized transactions.

  Business & Compliance Risks:
      Violation of Data Protection Laws: Non-compliance with GDPR, CCPA, and other data privacy regulations may lead to legal actions.
      Loss of User Trust: Users may lose confidence in the platform’s security.
      Reputation Damage: Public exposure of this issue can harm the company’s brand and credibility.

Proposed Solution

  Implement Proper Access Controls:
      Restrict access to PII data using role-based access control (RBAC).
      Ensure only authorized users can access sensitive information.

  Secure API & Web Responses:
      Remove PII exposure in API responses unless explicitly required.
      Mask or encrypt sensitive data in logs and responses.

  Regular Security Audits & Compliance Checks:
      Conduct frequent security assessments to detect and fix data leaks.
      Ensure compliance with data protection laws and industry security standards.

Conclusion

This PII data exposure vulnerability poses a critical security risk, allowing attackers to steal personal user information. Implementing access controls, API security measures, and regular audits is necessary to protect user privacy and prevent legal risks.

Reported by: Vikash Gupta

Vulnerability Type:

Session Management Issue

Email Account Takeover

User Data Exposure

Severity: P1 (Critical)

This vulnerability allows an attacker to retain a valid session even after a subdomain is deleted or transferred to another user, enabling them to:

Read all incoming emails of the new user.

Send emails on behalf of the new user.

Modify email settings, such as forwarding rules and signatures.

—

Description:

The Alwaysdata platform allows users to create subdomains under alwaysdata.net for hosting websites and managing emails via webmail.alwaysdata.com. However, a critical session management flaw enables an attacker to retain an active session even after deleting or transferring the subdomain to a new user.

—

Scenario 1: Subdomain Reuse

Steps to Reproduce:

1. The attacker creates a subdomain (e.g., attacker.alwaysdata.net).

2. The attacker logs into webmail.alwaysdata.com and keeps the session active.

3. The attacker deletes the subdomain from their account.

4. A new user registers the same subdomain (attacker.alwaysdata.net).

5. The new user logs into webmail.alwaysdata.com.

6. The attacker retains a valid session, allowing them to:

Read all incoming emails of the new user.

Send emails on behalf of the new user.

Modify email settings (forwarding, signature, etc.).

7. The new user may encounter session-related errors, such as:
"Server Error: CREATE: Internal error occurred. Refer to server log for more information."

—

Scenario 2: Subdomain Ownership Transfer

Steps to Reproduce:

1. The attacker creates a subdomain (e.g., attacker.alwaysdata.net).

2. The attacker logs into webmail.alwaysdata.com and keeps the session active.

3. Instead of deleting the subdomain, the attacker transfers ownership to another user via admin.alwaysdata.com.

4. The new user accepts the transfer and starts using the subdomain.

5. The attacker retains an active session, allowing them to:

Read and send emails on behalf of the new user.

Modify email settings.

Access the email account until the session expires.

6. Even if the new user changes their email password via admin.alwaysdata.com, the attacker still has access due to the active session.

—

Impact:

Sensitive Data Exposure: The attacker can read incoming emails.

Identity Theft: The attacker can send emails on behalf of the new user.

Account Compromise: The attacker can modify email settings to maintain access.

Mass Exploitation: The attacker can create and delete multiple subdomains to target many future users.

##POC: https://admin.alwaysdata.com/support/84903/

—

Recommended Fixes:

Terminate all active sessions immediately upon subdomain deletion or transfer.

Link sessions to the user account instead of just the subdomain.

Warn the new user if there was an existing open session for the same subdomain.

Enforce re-authentication when transferring subdomain ownership.

Add an additional verification layer for email-related sessions when ownership changes.

This vulnerability poses a severe risk to user privacy and requires an urgent fix to prevent unauthorized access to email accounts.

Critical Vulnerability Report- {Critical BUG #P1} - https://blog.alwaysdata.com/wp-cron.php - vulnerable to DoS attack via wp-cron.php

NOTE: I did not do Exploitation that as this can impact your website.

Hello Security team,

I am a Security Engineer, Cyber Security Researcher, Bug Bounty Hunter & Ethical Hacker. While testing your domain https://alwaysdata.com I have found some important vulnerabilities in your site.

Vulnerability Name: https://blog.alwaysdata.com/ - vulnerable to DoS attack via wp-cron.php

Vulnerable Domain: https://blog.alwaysdata.com/wp-cron.php

Description:

The WordPress application is vulnerable to a Denial of Service (DoS) attack via the wp-cron.php script. This script is used by WordPress to perform scheduled tasks, such as publishing scheduled posts, checking for updates, and running plugins.
An attacker can exploit this vulnerability by sending a large number of requests to the wp-cron.php script, causing it to consume excessive resources and overload the server. This can lead to the application becoming unresponsive or crashing, potentially causing data loss and downtime.

I found this vulnerability at https://blog.alwaysdata.com/wp-cron.php endpoint.

Steps to Reproduce: reference- https://hackerone.com/reports/1888723
navigate to: https://blog.alwaysdata.com/wp-cron.php intercept the request through the burp suite
right click on the request and send it to the repeater
Now send a request, and you will see the response as 200 OK

—

this can be also done by the curl command given below

curl -I "https://blog.alwaysdata.com/wp-cron.php"

POC: Attached

Impact:
If successful, this misconfigured wp-cron.php file can cause lots of damage to the site, such as:

Potential Denial of Service (DoS) attacks, resulting in unavailability of the application.
Server overload and increased resource usage, leading to slow response times or application crashes.
Potential data loss and downtime of the site.
Hackers can exploit the misconfiguration to execute malicious tasks, leading to security breaches.

Exploitation:

Exploitation can be done through a GitHub tool called doser.go https://github.com/Quitten/doser.go

I did not do that as this can impact your website.

Get the doser.py script at https://github.com/Quitten/doser.py Use this command to run the script: python3 doser.py -t 999 -g 'https://blog.alwaysdata.com/wp-cron.php'
Go to after https://blog.alwaysdata.com/ 1000 requests of the doser.py script.
The site returns code 502.

Suggested Mitigation/Remediation Actions:
To mitigate this vulnerability, it is recommended to disable the default WordPress wp-cron.php script and set up a server-side cron job instead. Here are the steps to disable the default wp-cron.php script and set up a server-side cron job:
Access your website's root directory via FTP or cPanel File Manager.
Locate the wp-config.php file and open it for editing.
Add the following line of code to the file, just before the line that says "That's all, stop editing! Happy publishing.":
Code 32 BytesUnwrap lines Copy Download
1define('DISABLE_WP_CRON', true);
Save the changes to the wp-config.php file.
Set up a server-side cron job to run the wp-cron.php script at the desired interval. This can be done using the server's control panel or by editing the server's crontab file.
References:

For more information about this vulnerability, please refer to the following resources:

https://hackerone.com/reports/1888723

https://medium.com/@mayank_prajapati/what-is-wp-cron-php-0dd4c31b0fee

https://developer.wordpress.org/plugins/cron/

Fix Them

I have protected your company and saved it from a big loss so give me some appreciation Bounty Reward.

I am sharing my PayPal ID with you.
Paypal ID: trilokdhaked12345678@gmail.com

there is ability to enumerate email address of users through
admin.alwaysdata.com/password/lost/
if i enter a registered email it will display that email has sent
but if the mail in snot registered it will say
The form contains some errors.
Email address of your account : There is no account with this email address.
so we can brute force using list of emails and get some regestered mails
there is rate limit but it's very poor as waiting 20 seconds after 7 or 8 requests will be ok and not banned with 429 response

suggested solution to say that : email is sent if this email has an account
as in here admin.alwaysdata.com/login/
if email or password are wrong it says credentials are incorrect not say email is incorrect as here emails can be enumerated