All Projects

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.

Summary:
The session management does not include any IP address, geolocation, or device fingerprinting checks. Once a session token is obtained, it can be replayed from any device, browser, or country, allowing attackers to bypass contextual integrity checks and maintain unauthorized access.

Steps to Reproduce:
Log in to alwaysdata.com and capture the session token (e.g., via browser DevTools or proxy).

Move to a different device, browser, or VPN geolocation.

Replay the captured token (e.g., by importing cookies or using the token in API headers).

🎯 Result: The session remains valid — no reauthentication, MFA challenge, or warning is triggered.

Impact:
Allows session hijack from another country or device without detection.

No context-aware defense such as:

IP or ASN consistency checks

Browser/device fingerprinting

Geo-velocity anomaly detection

Supports stealthy unauthorized access, even if login alerts or 2FA are present.

Summary:
The OAuth implementation relies solely on bearer tokens (RFC 6750). Bearer tokens act like “keys to the kingdom” — anyone holding them gets full access. Without Proof-of-Possession (PoP) or sender-constrained tokens, a stolen token can be reused by an attacker from any device, IP, or session.

Steps to Reproduce:

Log in to the alwaysdata.com application and obtain a valid bearer access token (e.g., via browser dev tools).

Replay the same token from a completely different environment:

Another browser,

Another machine,

Or a proxy/intercepting tool.

Observe that the API/service still accepts the token without verifying the device, TLS channel, or binding key.

Impact:

Token Replay Attacks: Stolen tokens from XSS, CSRF, or insecure storage can be reused by attackers.

Session Hijacking: An attacker can impersonate users indefinitely until the token expires/revoked.

High-Severity Risk: Any token leak = full account compromise.

Summary:
The application allows users to reuse their existing password when performing a password change or password reset. This undermines the security intent of these features, as users can bypass the enforcement of setting a new, stronger, and unique credential. Allowing password reuse increases the risk of account takeover, brute-force persistence, and failure to comply with security best practices (such as NIST SP 800-63B and OWASP ASVS), which explicitly recommend preventing the reuse of the same password.

Steps to Reproduce:

Log in to the alwaysdata.com application using valid credentials.

Navigate to the Change Password or Password Reset functionality.

Enter the current password in both the "Old Password" and "New Password" fields (or set the reset password to the same as the old one).

Observe that the operation succeeds, and the password remains unchanged.

Impact:

Defeats the purpose of password change/reset: attackers with leaked or compromised credentials can maintain persistence by resetting to the same password.

Increases susceptibility to brute force and credential stuffing, since the password remains weak or already compromised.

Violates industry-standard best practices for credential management (OWASP, NIST).

Reduces the effectiveness of incident response: if credentials are suspected to be exposed, forcing a reset but allowing reuse leaves accounts vulnerable.

Security Best Practices Reference:

NIST SP 800-63B: Recommends preventing password reuse and enforcing that new credentials differ from previously used ones.

OWASP ASVS 2.1.8: Applications should prevent the use of the same value as the current password when changing or resetting credentials.

Recommendation:

Implement a password history check to ensure that newly set passwords are different from the current one.

Enforce a configurable password history (e.g., last 3–5 passwords cannot be reused).

Provide appropriate user feedback when the entered password matches the old one.

Severity: High – This is a critical flaw because it undermines a fundamental security control designed to mitigate account compromise.

Summary
The application applies rate limiting on failed login attempts per IP address, but does not combine this with account- or device-based throttling. An attacker can rotate IP addresses (using VPNs, proxies, or botnets) and continue brute-force or credential stuffing attempts against the same account, effectively bypassing the rate limit. This allows high-volume automated attacks that can lead to account takeover, credential stuffing success, and large-scale account enumeration.

Steps to Reproduce
In the alwaysdata.com application, choose a target account (e.g., victim@example.com).

From IP A, submit the maximum allowed failed login attempts until the application rate-limits further attempts from IP A. Record the response/status code.

Switch to IP B (use VPN, proxy, or other IP rotation technique).

Attempt to authenticate to the same target account using different password guesses. Observe that attempts from IP B are accepted and counted separately (rate limit not enforced per account).

Repeat with IP C, IP D, etc., and observe continued unrestricted attempts against the same account.

(Optional) Automate steps 2–4 from a list of rotating IPs to confirm large-scale brute-force is possible.

Expected secure behavior: The system should limit authentication attempts per account (or per account+device fingerprint) in addition to per-IP limits.
Observed insecure behavior: Authentication attempts continue after IP rotation; rate limiting is effectively bypassed.

Impact
Account Takeover (High): Continuous attempts across rotated IPs increase the probability of successfully brute-forcing a password or succeeding with credential stuffing.

Mass Credential Stuffing (High → Critical): Attackers can target many accounts at scale by cycling IPs, causing large-scale account compromise.

Recommended Fixes
Enforce account-based throttling (primary)

Track failed authentication attempts per account (email/username) and apply progressive throttling or temporary lockouts. Example policy: after 5 failed attempts for an account within 15 minutes, block further attempts for that account for 15 minutes.

Combine IP + account limits (defense-in-depth)

Use a hybrid key: limit_key = hash(account_id + ip) plus a separate limit_key = account_id. This reduces false positives while preventing IP-rotated attacks.

Severity:
High

Summary:
OAuth account linking occurs automatically and implicitly on the company's web application, without requiring user verification, which can enable account takeover. Suppose an attacker signs up using OAuth with the same email as an existing account (registered via email/password). In that case, they are granted access to that existing account without any ownership validation, which is a critical authentication flaw.

Steps to Reproduce:
Create a target account (victim):

Go to alwaysdata.com

Register a new account using email/password, e.g., victim@example.com.

Log out.

Trigger the issue (attacker):

Go to the website

Log in using an OAuth provider (e.g., Google or Apple) that uses the same email address: victim@example.com.

Observe:

The OAuth login automatically links to the existing account created via email/password.

No verification (like password prompt, email confirmation, or user consent) is required.

The attacker now has full access to the victim's account.

Impact:
This vulnerability allows an attacker to fully compromise accounts by using an OAuth provider with an email address matching an existing account, without needing the victim’s password or any verification step.

Possible consequences:

Unauthorized access to personal data.

Tracking information leakage

Service misuse or device control.

Breach of privacy and user trust.

Recommended Fixes:
Do not auto-link OAuth accounts based solely on email.

Prompt the user for verification when an existing account with the same email exists (e.g., via:

Password input,

Email confirmation,

Explicit linking process in settings).

Provide clear UI/UX for account linking that ensures user intent.

Suggested CVSS (3.1) Score:
8.8 (High)

Attack Vector: Network

Attack Complexity: Low

Privileges Required: None

User Interaction: None

Confidentiality Impact: High

Integrity Impact: High

Availability Impact: Low

Regards,
Mehedi Hasan

Note: I was awarded a $500 reward for the same vulnerability reported to some other companies. They marked this as valid and attempted to fix the bug.

Summary:
Revoking an application's access via the OAuth provider's settings should terminate the session in the main application. However, users are still logged in if the session remains active despite the OAuth disconnection.

Steps to Reproduce:
01. Log in to alwaysdata.com using Google OAuth.
02. Let's say an attacker hijacked your OAuth session, or you logged in to another device not owned by you and forgot to log out from there after using the account, and you wanted to destroy the OAuth session there.
03. Go to the Google OAuth provider’s settings from your Google account and revoke the application’s access.
04. You will see that, even after the OAuth provider disconnects, the session remains valid and doesn't terminate.

Mitigation:
If a user’s OAuth access is revoked, force the application session to require re-authentication using OAuth. This ensures unauthorized sessions cannot continue.

Impact:
This flaw allows users or attackers with an active session to retain access even after OAuth access is revoked, creating a significant security risk and bypassing expected session termination mechanisms.

## Note: I was awarded $300 by reporting the same issue to some other companies and they accepted it and fixed it.

Summary:
It is possible to remain authenticated in the application even after deleting the identity account (email/SSO provider) used to log in, resulting in a user session that continues to function despite the underlying identity no longer being valid. This breaks the identity-assurance model and may allow long-term unauthorized access.

Steps To Reproduce:
01. Create an account in the alwaysdata.com application using any email/password registration.
02. Log in successfully and confirm access to protected features.
03. While the session remains active, open a new browser/tab and permanently delete the associated identity account (e.g., delete the Google account/email used to register).
04. Return to the application and refresh or continue using your session.
05. Observe that the application continues to function normally and the user retains complete access.

Impact:
01. Allows long-term access for a user whose identity has been destroyed, violating ownership-based trust assumptions.
02. Increases risk of orphaned sessions or unauthorized access

Recommendation:
01. Implement continuous/periodic checks to verify that the backing identity still exists.
02. Invalidate all user sessions upon account deletion response from the identity provider.
03. Force re-authentication if account verification fails.

Best Regards,
NH Limon