Security vulnerabilities

Affected endpoint: `https://security.alwaysdata.com/?getfile=290`

Vulnerability type: Cross-Site Scripting (XSS)
Status: Requires confirmation of application-origin execution
Severity: To be determined based on the execution context and affected users

## Summary

A potentially unsafe file-upload and file-rendering behavior was identified on the application. A test PDF, `test-xss.pdf`, was uploaded and accessed through the application's file retrieval endpoint.

When the PDF was opened, a browser notification displaying “XSS Tested Successfully” appeared, indicating that script-related behavior was triggered in the document-viewing workflow.

Further validation is required to determine whether the behavior constitutes stored XSS in the application's security origin or JavaScript execution isolated to the PDF viewer.

## Steps to Reproduce

1. Upload a PDF containing a benign JavaScript execution test through the application's file-upload functionality.
2. Open the uploaded file using the application's file retrieval endpoint.
3. Observe the PDF viewer and check whether the test notification appears.
4. If authorized, verify the execution origin and whether the same behavior affects another user who opens the uploaded file.

## Observed Result

A browser notification displaying “XSS Tested Successfully” appeared while the PDF was open in the browser.

## Expected Result

Uploaded files should be served and rendered safely. Untrusted document content must not execute script with privileges belonging to the application's origin.

## Security Impact

If the uploaded document can execute JavaScript in the application's origin when opened by another user, an attacker might be able to perform actions within that user's authenticated session, subject to the application's security controls.

If execution is confined to a sandboxed PDF viewer or a separate origin, the impact may be substantially lower.

## Recommendations

* Serve untrusted uploads from a separate, appropriately isolated origin.
* Apply strict file-type validation and safe content-disposition headers.
* Configure an appropriate Content Security Policy where applicable.
* Ensure PDF rendering and JavaScript execution follow the viewer's security model.
* Test uploaded files with a current, securely configured PDF viewer.
* Verify that other users cannot be affected through the same upload-and-view workflow.

## Evidence

The supplied screenshot shows the notification “XSS Tested Successfully” while viewing `test-xss.pdf` through the application's file endpoint.

Severity: High

Affected endpoint:
https://www.alwaysdata.com/en/contact/

Affected field(s):
“Name” field (confirmed), “Message” field (submitted, pending confirmation — see note below)

Vulnerability class:
Blind Stored XSS / HTML Injection (CWE-79)

Description:
The contact form on the above page does not appear to sanitize or encode user input before it is processed/stored/rendered elsewhere (e.g., in an internal admin panel, notification system, or email client used by staff). An HTML/JS payload submitted via the “Name” field triggered an out-of-band DNS callback to a Burp Collaborator server, confirming execution outside of my own browser session.

Proof of Concept:
The following payload was submitted in the “Name” field:

html
<img src="pleatfo27nan3vme473ekhdhy84zspge.oastify.com">

Evidence of execution:
The Collaborator server logged two separate DNS A-record lookups for the payload domain:

# Time (UTC) Type Source IP
17 2026-10-09 11:22:33.308 DNS 172.217.33.215
18 2026-10-09 11:22:33.331 DNS 172.253.1.218

The lookups occurred shortly after submission, from IPs distinct from my own testing IP, indicating the payload was parsed/rendered by a system other than the submitting browser (consistent with internal review tooling, a notification pipeline, or similar).

Steps to Reproduce:

1. Navigate to https://www.alwaysdata.com/en/contact/ 2. In the “Name” field, enter: <img src="[unique-id].oastify.com"> (or equivalent Collaborator/callback payload)
3. Fill remaining required fields with valid test data
4. Submit the form
5. Monitor the Collaborator/callback server for an inbound DNS/HTTP interaction
6. Observe the out-of-band callback confirming the payload was parsed as HTML outside the submitter’s own session

Impact:
If rendered in an internal tool without sanitization, this could allow an attacker to execute arbitrary JavaScript in the context of whatever system/staff session processes contact form submissions — potentially enabling session token theft, internal tool manipulation, or lateral exposure, depending on that system’s privileges.

Suggested remediation:
Sanitize/encode all contact form input before storage, display, or forwarding to any internal system (output encoding appropriate to the destination context — HTML-escape for HTML rendering, etc.).