All Projects

Critical SSRF via Application Script Source URI — Cross-Tenant Data Leak
Severity: Critical
Target: admin.alwaysdata.com
Auth: Free-tier account (no special permissions)

Summary
The "Installation script source URI" field accepts internal URLs like `<REDACTED>`. The server fetches the URL from its own backend and stores the full response in the script field, readable by the attacker. No IP/port validation exists. This leaks other customers' data, internal server names, and full stack traces.

Steps to Reproduce
1. Log in to `https://admin.alwaysdata.com` (free account works)
2. Go to Web → Sites → Applications → Application scripts → Add 3. Fill required fields with any values. For Installation script enter:

#!/bin/bash
site:

type: custom

echo installed

4. Set Installation script source URI to: `<REDACTED>`
5. Click Submit

6. Click the refresh/update icon next to the script (or visit `/site/application/script/<ID>/update_script/`)
7. Open the script edit page — the Installation script textarea now contains <REDACTED>.

Impact
- Cross-tenant data leak — read other customers' account names, domains, and operations
- Internal infrastructure mapping — server hostnames, paths, stack traces exposed
- Firewall bypass — requests come from the server itself, reaching localhost-only services
- No rate limit — can probe unlimited internal ports/services
- 147 MB exfiltrated in a single request with no size restriction

—

Thank You

## Description

A Cross-Site Request Forgery (CSRF) vulnerability exists in the service management functionality. The application does not properly validate whether a service restart request originates from a legitimate user action.

By crafting a malicious CSRF proof-of-concept (PoC) and replacing the service identifier with a victim's service ID, an attacker can cause the victim's browser to send an authenticated request that restarts the victim's service without their knowledge or consent.

This vulnerability allows unauthorized state-changing actions to be performed on behalf of authenticated users.

—

## CVSS v3.1

Base Score: 4.5 (MEDIUM)

—

# Steps to Reproduce

1. Log in with an attacker account.
2. Navigate to the Services section.
3. Create a new service.
4. Open another browser (or private window) and log in as a victim.
5. Create a service in the victim account.
6. Return to the attacker account.
7. Trigger the Restart Service functionality.
8. Capture the restart request using Burp Suite.
9. Use Burp Suite's Engagement Tools to generate a CSRF PoC.
10. Save the generated HTML file.
11. Replace the attacker's `service_id` with the victim's `service_id`.
12. Modify the request method from POST to GET.
13. Open the modified PoC in the victim's authenticated browser.
14. Click Submit.
15. Observe that the victim's service is restarted successfully without the victim intentionally initiating the request.
16. Verify the restart by checking the service logs.

—

# Actual Behaviour

The application processes the forged request using the victim's authenticated session, allowing the victim's service to be restarted without verifying the request's origin or intent.

—

# Expected Behaviour

The application should reject forged cross-origin requests. Every state-changing action should require valid CSRF protection and proper server-side validation so that only requests intentionally initiated by the authenticated user are accepted.

—

# Impact

* Unauthorized restart of another user's services.
* Service interruption without user consent.
* Attackers can repeatedly restart services, affecting availability.
* Users can be forced into unexpected downtime simply by visiting a malicious webpage while authenticated.

—

# Business Impact

* Reduced service availability and reliability.
* Potential disruption of customer-hosted applications.
* Loss of customer trust due to unauthorized actions.
* Increased support requests resulting from unexplained service restarts.
* Possible abuse for denial-of-service against targeted users by repeatedly triggering service restarts.

—

# Remediation

* Implement robust anti-CSRF tokens for all state-changing requests.
* Validate the CSRF token on the server before processing the request.
* Ensure state-changing operations are not performed through GET requests.
* Validate the `Origin` and `Referer` headers where appropriate.
* Use the `SameSite` attribute (`Lax` or `Strict`) on session cookies to reduce CSRF risk.
* Require explicit user confirmation or re-authentication for sensitive administrative actions when appropriate.

—

# Proof of Concept (PoC)

Google Drive Link: https://drive.google.com/file/d/1EQgdh2HhlPqN1VJXeTHQLhMkmkciEwqJ/view?usp=sharing

—

# Conclusion

The application is vulnerable to Cross-Site Request Forgery (CSRF), allowing attackers to trigger unauthorized service restarts on behalf of authenticated users. Because restarting services directly impacts availability and can disrupt customer workloads, this issue represents a significant security risk. Implementing proper CSRF protections and server-side request validation will effectively mitigate the vulnerability and prevent unauthorized state-changing actions.

Thanks

1. Summary

A Broken Access Control (IDOR) vulnerability exists in the Flyspray-based bug reporting system used by Alwaysdata. The application fails to verify whether the authenticated user is authorized to perform sensitive actions on the supplied task_id and user_id. By manipulating these identifiers, an attacker can perform unauthorized actions on behalf of other users, including privileged administrators.

2. Bug Found

The following vulnerabilities were successfully identified from the same authorization flaw:
Unauthorized Request Closure of Another User's Report
Unauthorized Modification of Watching Status
Unauthorized Voting on Behalf of Another User
Unauthorized Commenting on Private Reports
Administrator-Only Report Closure
Administrator-Only Report Visibility Change (Make Public)
Administrator Account Takeover via IDOR

3. Impact

An attacker can:
Perform unauthorized actions on reports belonging to other users.
Manipulate the bug triage workflow.
Perform administrator-only operations.
Access or expose private vulnerability reports.
Impersonate privileged users.
Fully compromise the administrator account.
Gain complete administrative control over the Flyspray instance.

4. Business Impact

Successful exploitation may result in:
Exposure of confidential vulnerability reports.
Loss of trust in the vulnerability disclosure platform.
Manipulation or deletion of valid security reports.
Unauthorized administrative actions.
Complete compromise of the bug reporting system.
Reputational damage to Alwaysdata.
Potential legal and compliance risks due to unauthorized disclosure of sensitive security information.

5. Actual Behaviour The application accepts user-controlled identifiers (task_id and user_id) without verifying ownership or permissions. As a result, attackers can modify these values to perform actions on resources belonging to other users or administrators.

6. Expected Behaviour The server should verify that the authenticated user is authorized to access or modify the requested resource before executing any sensitive action. Administrator-only operations must be restricted to authenticated administrators, and user-supplied identifiers should never be trusted without proper authorization checks.

7. Root Cause The application lacks proper server-side authorization checks and directly trusts client-supplied object identifiers (task_id and user_id), resulting in a classic Broken Access Control (IDOR) vulnerability.

8. Remediation Implement server-side authorization checks for every sensitive request.
Verify ownership of every task_id before processing actions.
Ignore client-supplied user_id; derive it from the authenticated session.
Restrict administrator-only actions using server-side role validation.
Apply the principle of least privilege.
Perform a complete authorization review across all Flyspray endpoints.
Add security regression tests to prevent similar authorization flaws.

Proof Of Concept Drive_Link→ https://drive.google.com/drive/folders/1HTugxMsYGGNsewghO29t07zKTtpc0rZR?usp=sharing

9. Conclusion The identified vulnerabilities originate from a single Broken Access Control (IDOR) flaw affecting multiple critical features of the Flyspray instance. By exploiting this weakness, an attacker can manipulate reports, impersonate users, execute administrator-only actions, disclose private reports, and ultimately achieve full administrator account takeover. Due to the severity and broad impact, this issue should be treated as Critical and remediated immediately.

Thanks