Security vulnerabilities

Attached to Project: Security vulnerabilities
Opened by ahmedsss2233 - 09.05.2026
Last edited by cbay - 11.05.2026

Severity: MEDIUM

Target: admin.alwaysdata.com
Affected endpoint: `POST https://admin.alwaysdata.com/password/lost/`

## Description

The password-reset endpoint returns a different HTTP status (and different body) depending on whether the submitted email belongs to a real account, allowing unauthenticated enumeration of valid alwaysdata user emails.

## Steps to Reproduce

```
# Existing account — redirected to the success page
curl -i -X POST https://admin.alwaysdata.com/password/lost/ \

1. H 'Content-Type: application/x-www-form-urlencoded' \
2. -data 'email=cbay@alwaysdata.com'

# → HTTP/1.1 302 Found
# → Location: /password/sent/

# Non-existent account — form re-rendered with no redirect
curl -i -X POST https://admin.alwaysdata.com/password/lost/ \

1. H 'Content-Type: application/x-www-form-urlencoded' \
2. -data 'email=nonexistent9999@example.com'

# → HTTP/1.1 200 OK
# → (form HTML re-rendered, no redirect)
```

The 302→/password/sent/ vs 200 differential is observable from a single unauthenticated request and was not rate-limited during testing.

## Impact

* Confirms whether an arbitrary email address has an alwaysdata account.
* Enables targeted phishing and credential-stuffing campaigns against confirmed-real customer accounts.
* Combined with ALW-007 (no rate-limiting on the related Flyspray login) and ALW-006 /  FS#329  (Flyspray username enumeration), feeds a chain ending in account-takeover attempts.

## Remediation

* Always return the same response (302 → `/password/sent/` with a generic "if an account exists with that email, a reset link has been sent" page) regardless of whether the email matched.
* Rate-limit the endpoint per source IP and per email (e.g. 5 requests / hour / address).
* Add CAPTCHA after 3 failed attempts.

— Reported by: Ahmed Said (asame8855@gmail.com) — manual testing only.