Security vulnerabilities

Attached to Project: Security vulnerabilities
Opened by rulebrekerz - 11.07.2026
Last edited by cbay - 13.07.2026

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