Description

OpenYak is a local-first agent runtime for reliable tool-using models, with a desktop workspace built on top. Prior to version 1.1.3, the OpenYak desktop backend binds an HTTP API to `127.0.0.1:<random port>` (commonly 19141) without server-side Origin validation, loopback authentication, or Content-Type enforcement, and with a wildcard CORS policy. Any webpage a user visits while OpenYak is running can issue cross-origin requests to this local server — the browser acts as a proxy into loopback, bypassing OS-level network isolation. Chained, this lets a malicious page execute arbitrary shell commands on the host (RCE) via the build agent with `permission_presets.bash=true`, shut down the service, and exfiltrate chat history and account PII — with no user interaction beyond opening the page. Version 1.1.3 patches the issue.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.6",
  "pubDate": "2026-08-07T23:17:03.243Z",
  "pubdate": "2026-08-07T23:17:03.243Z",
  "executiveSummary": "A critical security vulnerability exists in the OpenYak desktop backend prior to version 1.1.3, involving an unauthenticated local HTTP API lacking proper origin validation and content-type enforcement.\nThe vulnerability allows any malicious webpage visited by a user while OpenYak is running to issue arbitrary cross-origin HTTP requests to the local server, effectively utilizing the browser as a proxy to bypass operating system-level network isolation.\nSuccessful exploitation enables an external web attacker to achieve remote code execution (RCE) on the host system via the build agent when permission_presets.bash is enabled, terminate the local service, and exfiltrate sensitive data including chat history and account personally identifiable information (PII).\nThe attack requires no user interaction beyond visiting a malicious webpage while the local OpenYak runtime is active.\nThe risk implication is severe, as local loopback services assuming implicit trust are exposed to browser-based attacks through permissive Cross-Origin Resource Sharing (CORS) configurations.",
  "technicalDetails": "The root cause of the vulnerability stems from the OpenYak desktop backend binding an HTTP API to a local loopback address (127.0.0.1) on a dynamic or predictable port (commonly 19141) without enforcing server-side Origin validation, loopback authentication, or Content-Type verification.\nAdditionally, the server implements a wildcard CORS policy, permitting arbitrary cross-origin requests from any external web origin.\nBecause web browsers automatically attach cookies and route requests to loopback interfaces when prompted by scripts, a malicious external website can abuse the browser as a proxy to communicate directly with the local OpenYak API.\nThe step-by-step attack flow proceeds as follows: First, the victim navigates to a malicious webpage while the OpenYak desktop application is running locally. Second, the malicious script embedded in the webpage executes asynchronous JavaScript requests targeting the local HTTP API endpoint (e.g., http://127.0.0.1:19141/). Third, due to the wildcard CORS policy and the absence of origin checks, the local OpenYak server processes the incoming cross-origin requests.\nChained exploitation allows the attacker to invoke sensitive internal functions, such as interacting with the build agent configured with permission_presets.bash=true, thereby executing arbitrary shell commands on the host operating system under the privileges of the running OpenYak process.\nFurthermore, the attacker can issue commands to shut down the service or query endpoints to exfiltrate confidential data such as chat histories and account PII.\nThe vulnerable component is the OpenYak desktop backend HTTP server implementation in versions prior to 1.1.3.\nThe attack requires no authentication, no special privileges on the target machine, and relies entirely on network exposure of the loopback interface combined with browser-based request dispatching."
}