Security vulnerabilities

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.

Report Summary:
I discovered a potential security issue where sensitive data is accessible via a URL archived by the Wayback Machine. The URL exposes an invoice containing personal and financial information, which could be misused if accessed by unauthorized individuals.

Details of the Issue:

1.Source of URL: Wayback Machine (Internet Archive)

2.URL: https://admin.alwaysdata.com/billing/337102/pdf/?user_id=150041&token=1657692793-a13e927142b2d5d7f427

3.Exposed Data:

4.Personal Information: Name (Simon Amour), email address (simondiligues@outlook.com).

5.Financial Information: Invoice amount (€100.00), bank account details (IBAN: FR76 1027 8060 4100 0205 8810 110, BIC: CMCIFR2A).

6.Service Details: Public Cloud service (10 GB) for the period 13/07/2022 to 27/07/2023.

7.Reference Numbers: Invoice reference (220713337102), user ID (150041), and token (1657692793-a13e927142b2d5d7f427).

Steps to Reproduce:

1.Access the URL via the Wayback Machine.

2.The PDF invoice containing sensitive data is directly accessible without additional authentication.

Impact:
This issue could lead to unauthorized access to sensitive personal and financial information, potentially resulting in identity theft, financial fraud, or other malicious activities. The fact that this data is archived on a public service like the Wayback Machine increases the risk of exposure.

Summary:
A critical security vulnerability was identified in the file upload on the application. The flaw allows users to upload any file type, including executable files like .pdf, .php, and .exe, with invited members. This presents a significant risk, as malicious files could be uploaded and distributed, leading to potential exploitation and compromise of other systems.

Vulnerable url: https://admin.alwaysdata.com/support/add/

Description:

I discovered a publicly accessible PDF file containing sensitive financial and personal information at the following URL:
https://share.alwaysdata.com/IBAN.pdf AND https://static.alwaysdata.com/docs/IBAN.pdf

The document exposes Personally Identifiable Information (PII) and sensitive banking details, including the International Bank Account Number (IBAN), Bank Identifier Code (BIC), account holder's name, and address. This information could be exploited for unauthorized transactions, fraud, and privacy violations.

Steps to Reproduce:

1. Navigate to the URL: [https://static.alwaysdata.com/docs/IBAN.pdf] and [https://share.alwaysdata.com/IBAN.pdf]
2. Download the file (IBAN.pdf).
3. Open the file to view the sensitive details

Impact:

• Financial Risks: An attacker could misuse the exposed banking details for unauthorized transactions or fraudulent activities.
• Privacy Concerns: The document discloses the account holder’s name and address, increasing the risk of phishing or other targeted 
        attacks.
• Legal Compliance: Public exposure of such information may violate data protection regulations, such as the GDPR (General Data 
        Protection Regulation) in the EU.

Mitigation:

1. Immediately remove the file from public access.
2. Audit all publicly accessible files to ensure sensitive information is not exposed.
3. Use preventive measures like robots.txt or noindex tags to prevent indexing by search engines.
4. Review the system to ensure sensitive files are stored securely and not inadvertently exposed.

Severity: High – This issue involves the public disclosure of sensitive financial and personal information, which could lead to significant harm if exploited.

Suggested Timeline for Fix: Immediate – This issue should be prioritized for resolution to prevent potential abuse.

Hope this will be fixed soon.
Do let me know if you need any further assistance.

NOTE: While Making this report public please make sure to mask or remove the sensitive information that is written in the report.

Thanks
Best Regards
Aakarsh Mishra

Hope everything going well on your side.

Recently, while enumerating over alwaysdata.net and alwaysdata.com i came across a js file which contain a npm dependency which you also used using command require('nw.gui') . When i check it on npm registry it does not exist over there. So i claimed it. I also came across other dependencies which are used in other js files with the exact syntax but they are already exist on npm registry but only this dependency does not exist over npm registry. So, it could easily result in npm dependency confusion vulnerability which could severe consequences like if anytime you update/install it will easily give rise to Remote Code Execution over user/developer system even if it in scope or not.

## Step to reproduce:

1. Enumerate over your domain and find all endpoints.
2. From endpoints extract all js files.
3. In JS files search npm dependecies.


4. You will find dependency which I mentioned above.


Follow this js-file : [Link](https://foxrewards.alwaysdata.net/jeu/js/rpg_core.js)
5. Claimed the dependency.


## Impact:

1. If anytime you update/install it will easily give rise to Remote Code Execution over user/developer system which could be fatal.
2. Reputation damage of the company.

## Mitigation
Once you have reviewed this report, I can unclaim the package and you can upload your own ones there.

Failure to invalidate session after password change

Hello Team,

I hope you are doing well. While Researching in your domain I found Failure to invalidate session after password change vulnerability in your domain.

Steps to Reproduce:

1.Go to https://admin.alwaysdata.com/mailbox/id/ and set a password and then submit.
2.Then, go to another browser and login into https://webmail.alwaysdata.com/?from_roundcube=1.
3.Again go to https://admin.alwaysdata.com/mailbox/id/ and then change the password and submit it.
4.You can see that session is still login in https://webmail.alwaysdata.com/?from_roundcube=1 and you can make any Changes in https://webmail.alwaysdata.com/?from_roundcube=1.

Impact
If attacker have user password and logged in different places, As other sessions is not destroyed, attacker will be still logged in your account even after changing password, cause his session is still active.. Malicious actor can complete access your account till that session expires! So, your account remains insecure even after the changing of password.

Thank You,

Waleed Anwar

Direct accessing Api on another Browser.

Hello Team, I hope you are doing well. Well, researching in your domain I found Direct accessing Api on another Browser, steps are given below:

Steps to Reproduce:

1.Go to https://admin.alwaysdata.com/ and login into your account.
2 Go to Profile Section and create your token.
3.Then, go to https://api.alwaysdata.com/v1/account/ and sign in into your account.
4.Copy your login account Url and paste it into another browser, you can see that you can direct accessing the account without sign in the account.

Impact:

Create another session into another browser for accessing the account, If attacker gain the victim session or laptop access, so he/she can directly access the victim Api account in https://api.alwaysdata.com/v1/account/ .

#Note:

I deleted all the cookies from the browser, after that I visit in https://api.alwaysdata.com/v1/doc so I can directly accessing the account without sign in again.

Thank You,

Waleed Anwar

https://security.alwaysdata.com/.git/config

[core]
    repositoryformatversion = 0
    filemode = true
    bare = false
    logallrefupdates = true
[remote "origin"]
    url = https://github.com/flyspray/flyspray.git
    fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
    remote = origin
    merge = refs/heads/master

https://security.alwaysdata.com/.gitignore

flyspray.conf.php
img/veloz.png
attachments/*
/.idea/
/nbproject/*
vendor/*
composer.lock
composer.phar
/_site/
.htaccess
*.PHPEditProject
/avatars/*
/lang/*.php.bak
/lang/*.php.safe
.vscode/*
!.vscode/settings.json
!.vscode/tasks.json
!.vscode/launch.json
!.vscode/extensions.json

https://security.alwaysdata.com/.git/logs/HEAD

0000000000000000000000000000000000000000 58bea729f4359a45f69aaba274bb2a931155b427 Cyril Baÿ 1704809861 +0100    clone: from https://github.com/flyspray/flyspray.git

.gitignore
.travis.yml
LICENSE
README.md
SECURITY.md
includes/.htaccess
cache/index.html
fonts/index.html
caddy.dist
composer.json
...
...
themes/CleanFS/templates/reports.tpl
themes/CleanFS/templates/roadmap.text.tpl
themes/CleanFS/templates/roadmap.tpl
themes/CleanFS/templates/shortcuts.tpl
themes/CleanFS/templates/toplevel.tpl
themes/CleanFS/theme.css
themes/CleanFS/theme_print.css
themes/CleanFS/typography.css
themes/CleanFS/up.png
vendor/.htaccess

Conclusion

• Git index allows accessing the files list and source code through .git/objects/
• You can see the top of the list of files above
• I haven't accessed those files' content because it's not necessary for the report according to the Responsible * Disclosure policy.
• My assumption is that some of those files contain sensitive information, which can be used to escalate vulnerability.

Resolving suggestions

1. Remove access to the .git folder from the web, e.g. in webserver config or using .htaccess file
2. Review repository content considering all data compromised because it has been available in public for a while.

Bypass the Session Expiration in admin.alwaysdata.com

Hello Team, I hope you are doing well, while I found Bypass the Session Expiration in admin.alwaysdata.com bug steps are given below:

Steps To Reproduce:

1.Logged into the website on both of mobile phone and a laptop.
2.Then go to https://admin.alwaysdata.com/support/?status=open&status=unread in mobile phone and open a ticket to just for test.

3.Fill the form and upload any thing you just want.
4. Turned Off Wifi or mobile data in your mobile phone and click on submit button and you see that no internet connection occurs in mobile phone web browser.

5. Logout from admin.alwaysdata.com in your laptop.
6. After that, Turned On Wifi or mobile data in your mobile phone and refresh the page in the web browser of your mobile phone and you can see that you are still login in the account while session was expired from the laptop and session was bypassed in the mobile pone browser.

#Note: I tested in hackerone and portswigger website they don't have this kind of bug, their session are out while someone can logout from their account in the laptop of Pc.

Thank You,

Waleed Anwar

Summary:

During testing, I discovered that the 2FA (Two-Factor Authentication) feature can be abused to block legitimate users from registering on the platform. This vulnerability arises because the application allows users to update their email addresses without disabling 2FA. When users update their email while 2FA is enabled, the application requires the 2FA code to log in with the new email. An attacker can exploit this flaw by registering an account using his email, enabling 2FA, and then updating the account's email to the victim's. This process effectively locks the victim out of their email address and prevents them from registering to the platform.

Steps to Reproduce:

1. create account at : https://admin.alwaysdata.com/admin/details/

1. The attacker creates an account using their email address.

1. the attacker logs in and enables 2FA.

1. The attacker then updates their email address to the victim's.

1. If the victim tries to register an account using their email address, they receive an error stating that the email already exists.

1. If the victim attempts to reset the password using the "Forgot Password" feature:

1. The victim receives the password reset link and successfully updates their password.

1. Upon attempting to log in, the application prompts for the 2FA code.

1. Since the victim cannot access the 2FA code the attacker sets, they cannot log in.

PoC :

https://drive.google.com/file/d/1iKnoKLZXCREeIidrOzvH2SXDNDLPqsLH/view?usp=sharing

Impact

This behavior effectively locks the victim out of their email address, preventing them from registering or accessing an account on the platform.

Non-functional 2FA recovery codes

Hello Team,

I hope you are doing well. While researching in your domain https://admin.alwaysdata.com/ I found that their is Non-Functional 2FA recovery code option in your domain.

The users that had enabled 2FA were not able to recover their accounts in case of a missing phone or authentication device. The issue was caused by improper error handling on the client during account recovery.

You should add a back-up recovery option so user or customer should back-up their account easily.

Thank You,

Waleed Anwar

The endpoint is not publicly visible through the application interface but was discovered using search engine dorking techniques.

https://tracker.alwaysdata.com/index.php?module=CoreAdminHome&action=optOut&language=en

Low severity as it doesn't reveal sensitive server info