Security vulnerabilities

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.

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.

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

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

Summary:
An accessible phpinfo page at https://net2ftp.alwaysdata.com/skins/php.php discloses detailed configuration information about the PHP environment. This information can be leveraged by attackers to identify potential vulnerabilities, misconfigurations, and outdated software components.

Details:

PHP Version: 5.6.40
System Information:
Operating System: Linux (kernel version 6.6.30-alwaysdata)
Server API: CGI/FastCGI
Configuration Exposure:
Paths to configuration files (php.ini) and directories
Enabled/disabled PHP functions and security settings (e.g., disable_functions, open_basedir)
Loaded extensions and their versions
Environment details such as server API and build dates
Steps to Reproduce:
Navigate to the URL: https://net2ftp.alwaysdata.com/skins/php.php Observe that the page displays comprehensive PHP configuration details.
Impact:
Information Disclosure: The exposed details provide attackers with insights into the server configuration, which could be used to tailor further attacks.
Risk of Exploitation:
-Identification of outdated software (PHP 5.6.40 is no longer supported and may have known vulnerabilities).
-Knowledge of disabled functions and active extensions can assist in formulating targeted exploitation strategies (e.g., leveraging known vulnerabilities in specific extensions or misconfigurations).
-Potential Follow-on Attacks: While phpinfo itself is not a direct vulnerability, the information disclosed could aid in other attacks, such as Local File Inclusion (LFI) or Remote Code Execution (RCE), if combined with other weaknesses.
Severity:
Risk Level: High the server also runs outdated or unpatched components and the phpinfo page is publicly accessible without any authentication or access control.
Recommendations:
-Restrict Access:
Remove or restrict access to the phpinfo page from the public internet. Consider using authentication or IP whitelisting if the page is needed for internal diagnostics.
-Update PHP:
Upgrade to a supported and secure version of PHP to mitigate potential exploits that target known vulnerabilities in PHP 5.6.40.
-Harden Configuration:
Ensure that sensitive functions (e.g., exec(), shell_exec()) are disabled if not necessary.
Review and adjust settings such as open_basedir to limit access to the file system.

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

producing steps:
By using google dorks and write
site:alwaysdata.com intitle:index.of
it will show 2 sites
https://files.alwaysdata.com/ https://files.alwaysdata.com/migrations/software-2020/ the 2 files give me 404 forbidden

poc
searching for files.alwaysdata.com in waybackmachine
i can access now the pages without forbidden message
it contains software-2017 and software 2020
https://web.archive.org/web/20241007181407/https://files.alwaysdata.com/migrations/ it is an index page , appears software files that can be downloaded

#CSRF TOKEN BYPASS WITH GET REQUEST.

Hello Team, I hope you are doing well. While, Researching in your domain I found Csrf Token Bypass with Get Request Method.

#Steps to Reproduce:

1. Login https://webmail.alwaysdata.com/?from_roundcube=1.
2. Go to https://webmail.alwaysdata.com/roundcube/?_task=settings&_action=folders and Click on Save Button and Capture the Post Request in BurpSuite.

3. You got the POST request like this.

POST /roundcube/ HTTP/1.1
Host: webmail.alwaysdata.com
Cookie: csrftoken=xxxxxxxxxxxxxxxxxxxxxxx; roundcube_sessid=xxxxxxxxxxxxxxxxx; mailviewsplitterv=165; mailviewsplitter2=405; prefsviewsplitter=195; colorMode=light; sessionid=xxxxxxxxxxxxxxxxxxxxxxxxxxx; roundcube_sessauth=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:135.0) Gecko/20100101 Firefox/135.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://webmail.alwaysdata.com/roundcube/?_task=settings&_action=add-folder&_mbox=&_framed=1 Origin: https://webmail.alwaysdata.com Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: iframe
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: same-origin
Sec-Fetch-User: ?1
Priority: u=4
Te: trailers
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 89

_token=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx&_framed=1&_task=settings&_action=save-folder&_name=test&_parent=INBOX&_viewmode=0

4. Change the POST Request to GET and remove the token into null request.
5. Send this request to someone, he/she create folder without token and CSRF Protection also bypassed.

#Before Changing the Request(POST Method):

REQUEST CHECK FAILED
For your protection, access to this resource is secured against CSRF.
If you see this, you probably didn't log out before leaving the web application.

Human interaction is now required to continue.
Please contact your server-administrator.

# After Changing the Request(GET Method):

Location
Folder name
Parent folder

— Settings
List view mode

List

Thank You,

Waleed Anwar

A PDF file containing bank account details and sensitive codes is publicly accessible without authentication. This exposure poses a high risk as it could lead to financial fraud, identity theft, or unauthorized transactions.

Steps To Reproduce:

  Locate the exposed PDF file:
      Access the file directly via the URL:

  https://share.alwaysdata.com/IBAN.pdf ,https://static.alwaysdata.com/docs/IBAN.pdf

  No authentication is required to view the pdf .

Confirm sensitive data exposure:

  Open the PDF and verify that it contains:
      Bank account number
      Sensitive codes BIC (Bank Identifier Code)

Impact:

🔴 Severity: High

  Financial Risk: Attackers could misuse exposed bank details for fraudulent transactions or identity theft.
  Compliance Violation: The exposure may violate GDPR, PCI DSS, and financial security policies.
  Reputation Damage: If exploited, this could lead to customer trust loss and regulatory fines.

Recommendation:

Restrict Access: Implement authentication & access control for sensitive files.
Disable Directory Listing: Prevent public file browsing on the server.
Remove Exposed Files: Securely delete or relocate sensitive PDFs.
Use Robots.txt & No-Index Headers: Prevent search engines from indexing sensitive documents.
Supporting Material/References:

  Exposed URL :https://share.alwaysdata.com/IBAN.pdf
               https://static.alwaysdata.com/docs/IBAN.pdf

#PHP info page disclosure

Hello Team, I hope you are doing well. While Researching on your domain, I found PHP info page disclosure.

Steps to Reproduce:

1.Ping www.alwaysdata.net
2.Found 185.31.40.5
3.Next thing I did was a Whois request on that domain to find the Netrange of this IP Address.
inetnum: 185.31.40.0 - 185.31.40.255
netname: ALWAYSDATA-PARIS1
country: FR
admin-c: ALWS1-RIPE
tech-c: ALWS1-RIPE
status: ASSIGNED PA
mnt-by: ALWAYSDATA
created: 2024-09-24T12:04:24Z
last-modified: 2024-09-24T12:04:24Z
source: RIPE

4.Then I wrote a bash script to find Sensitive Data on IP Address.
#!/bin/bash
for ipa in 185.3{1..0}.{40..255}.{0..255}; do
wget -t 1 -T 5 http://${ipa}/phpinfo.php; done &
and yes the result was the one i’ve found above.

5. I found http://185.31.41.136/phpinfo.php

An attacker can obtain information such as:
Exact PHP version.
Exact OS and its version.
Details of the PHP configuration.
Internal IP addresses.
Server environment variables.
Loaded PHP extensions and their configurations and etc.

Impact
This information can help an attacker gain more information on the system. After gaining detailed information, the attacker can research known vulnerabilities for that system under review. The attacker can also use this information during the exploitation of other vulnerabilities.

Thank You,

Waleed Anwar

Description:

During the test of the web application, I have discovered a stored XSS in the support Inbox portal and observed that a malicious PDF file could be uploaded in place of a valid one, eventually leading to a stored XSS vulnerability.

Reproduction Steps:

Get login Go to Support inbox Upload the attached pdf XSS Open the pdf, it will not trigger Click on Print, the XSS will trigger on another tab

POC URL: https://admin.alwaysdata.com/support/84461/393820-x.pdf

POC Video: https://drive.google.com/drive/folders/1LxN8LxuTCF9Np4JyM1opB00Wc3jcoGGP?usp=sharing Payload: https://drive.google.com/file/d/1F44yeQMuWoIfSNdoyB4QAtwr7jztYkNQ/view?usp=sharing

Similar vulnerability report as reference: https://hackerone.com/reports/1481207 https://hackerone.com/reports/881557

Impact:

A stored XSS attack can have a significant impact, allowing attackers to steal sensitive user information like cookies, hijack user sessions of internal support users or admin whoever opens the ticket.

Target IP: 185.31.40.185Date: February 24, 2025Tester: Ziad Ali

1. Summary of Findings

The penetration test conducted on the target system revealed multiple vulnerabilities across different services, with a focus on Avahi, Exim, and MariaDB. Below is a high-level summary:

Avahi mDNS (CVE-2011-1002) – DoS Vulnerability Detected

Exim Mail Server (Version 4.92) – Multiple Exploits Available

MariaDB (Version 10.4.33) – Critical Privilege Escalation and RCE Vulnerabilities

2. Detailed Findings

2.1 Avahi mDNS (CVE-2011-1002)

Service: Avahi (Multicast DNS, UDP 5353)

Impact: Remote attackers can send NULL UDP packets to disrupt network service.

Proof of Concept:

The system responded to a NULL UDP packet sent to 224.0.0.251, indicating potential for exploitation.

Remediation:

Disable Avahi if not needed (systemctl stop avahi-daemon).

Update Avahi to the latest patched version.

Restrict multicast traffic using firewall rules (iptables -A INPUT -s 224.0.0.251 -j DROP).

2.2 Exim SMTP Server (Version 4.92)

Service: Exim SMTP (TCP 465)

Impact: Multiple privilege escalation and RCE vulnerabilities detected.

Vulnerabilities:

CVE-2019-16928 (Heap Overflow, RCE) – CVSS Score: 9.8

CVE-2019-15846 (Remote Code Execution) – CVSS Score: 9.8

Exploit Available: Metasploit modules exist for these exploits.

Remediation:

Upgrade Exim to the latest stable version.

Implement security best practices such as restricting access to SMTP services.

2.3 MariaDB Server (Version 10.4.33)

Service: MariaDB (TCP 3306)

Impact: Critical privilege escalation and remote code execution vulnerabilities.

Vulnerabilities:

CVE-2012-2750 (Authentication Bypass) – CVSS Score: 10.0

CVE-2016-9843 (Arbitrary Code Execution) – CVSS Score: 9.8

Exploit Available: Public exploits exist for privilege escalation.

Remediation:

Upgrade MariaDB to the latest stable version.

Restrict database access using firewall rules.

Implement strong authentication mechanisms.

3. Conclusion & Recommendations

The target system has multiple critical vulnerabilities that could lead to unauthorized access, privilege escalation, and denial-of-service attacks. The following actions should be prioritized:

Immediate Patch Deployment: Update Exim and MariaDB to secure versions.

Disable or Secure Avahi Service: Unless required, disable Avahi or limit its exposure.

Firewall Hardening: Restrict access to SMTP, IMAP, and database services.

Security Monitoring: Implement IDS/IPS solutions to detect exploit attempts.

Severity Assessment: Critical – Immediate action is recommended to mitigate risks.

Description:
The invoice issued by AlwaysData contains sensitive personal and financial information, which is publicly accessible through a web archive. This includes:

Personal details of the customer (Name: Simon Amour, Email: simondiligues@outlook.com).
Banking information such as the IBAN and BIC codes.
The invoice total and payment details.

Steps to Reproduce:
1.Access the : https://web.archive.org/web/20220713065916/https://admin.alwaysdata.com/billing/337102/pdf/?user_id=150041&token=1657692793-a13e927142b2d5d7f427

2.View the invoice, noting that it contains unredacted sensitive information, such as:
IBAN: FR76 1027 8060 4100 0205 8810 110
BIC: CMCIFR2A
Customer's Full Name: Simon Amour
Customer’s Email: simondiligues@outlook.com

3.The invoice is accessible without authentication, allowing any user to view it.

Impact:
This exposure of sensitive financial information could lead to identity theft, fraud, and financial loss. Unauthorized access to such data can also result in reputation damage for both the service provider (AlwaysData) and the customer (Simon Amour).

Suggested Remediation:
Remove the exposed document from the public web archive immediately.
Redact sensitive details such as IBAN, BIC, and personal information from invoices before uploading them to any public platform.
Implement access control mechanisms so that sensitive data is only accessible by authorized users.
Regularly audit publicly accessible data and ensure no personal or sensitive information is exposed.