Security vulnerabilities

  • Status Closed
  • Assigned To
    cbay
  • Private
Attached to Project: Security vulnerabilities
Opened by nexxp66 - 16.07.2026
Last edited by cbay - 17.07.2026

FS#413 - Cross-Site Request Forgery (CSRF) Allows Logs Refresh of Another User's

Description

The application does not properly validate whether a Logs Refresh request is initiated by the authenticated user. By creating a malicious CSRF PoC and replacing the service_id with the victim's service ID, an attacker can force a victim's authenticated browser to execute the Logs Refresh action without the victim's knowledge or interaction.

This allows unauthorized actions to be performed on behalf of authenticated users.

Steps to Reproduce

Log in with an attacker account.
Navigate to the Services section.
Create a new service.
Open another browser/private window and log in as a victim.
Create a service in the victim account.
Return to the attacker account.
Trigger the Logs Refresh functionality.
Capture the Logs Refresh request using Burp Suite.
Use Burp Suite Engagement Tools to generate a CSRF PoC.
Save the generated HTML file.
Replace the attacker's service_id with the victim's service_id.
Open the modified PoC in the victim's authenticated browser.
Click Submit.
Observe that the victim's Logs Refresh action is executed successfully without the victim intentionally performing the action.

Expected Behavior

The application should validate that Logs Refresh requests are intentionally initiated by the authenticated user and should reject cross-origin requests without proper CSRF protection.

Actual Behavior

The application accepts the forged request and performs the Logs Refresh action using the victim's active session without requiring any additional validation.

Impact

An attacker can force authenticated users to execute Logs Refresh actions without their knowledge through a CSRF attack.
The attacker can repeatedly trigger Logs Refresh requests on behalf of the victim, potentially consuming the victim's available Logs Refresh quota/limit.
This may result in abuse of limited resources and prevent the victim from using the Logs Refresh functionality when needed.

Closed by  cbay
17.07.2026 12:13
Reason for closing:  Invalid
Admin
cbay commented on 16.07.2026 15:07

Hello,

The application does not properly validate whether a Logs Refresh request is initiated by the authenticated user.

Your video doesn't show that at all.

Kind regards,
Cyril

Hello Team,

Thank you for the feedback.

I understand your concern. I will provide an updated video demonstrating the complete CSRF flow, including the victim being authenticated, the victim not manually performing the Logs Refresh action, and the action being triggered through the CSRF PoC.

I will share the updated proof for your review.

Admin
cbay commented on 17.07.2026 07:17

Your video doesn't show that the forged requests do succeed.

I have updated the PoC video and now demonstrated the forged request along with the successful response. The video shows that the CSRF request is executed successfully from the victim's authenticated session.

Admin
cbay commented on 17.07.2026 10:46

CSRF concerns state-changing operations, which is not the case here.

If the victim opens the CSRF PoC, the Logs Refresh action will be triggered without their intention and can consume the allowed refresh/restart limit.

As a result, when the user later tries to refresh the logs themselves, the action will not be performed because the limit has already been reached, and the logs will be stopped with the message "Maximum restart attempts reached."

Admin
cbay commented on 17.07.2026 12:13

It's not a "logs refresh" action, it's simply an endpoint to view the logs.

the logs will be stopped with the message "Maximum restart attempts reached."

That's a hallucination, it doesn't exist.

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing