Malicious repo config triggers code execution in Knowns LSP

A critical arbitrary code execution flaw in the Knowns Language Server Protocol (LSP) pipeline lets anyone who controls a repository run commands on the machine of whoever opens it, according to an advisory published on 6 October 2026. The issue is tracked as CVE-2026-86540 and GHSA-mc52-mwq4-vfx3, and affects the npm package knowns. The advisory rates it critical.

According to the advisory, the Knowns LSP detection and startup code blindly trusts the settings.lsp.languages.<lang>.binary field in a project's .knowns/config.json file. That field is never checked against an allowlist of managed binaries, and absolute paths are implicitly accepted. Opening a malicious repository, or a legitimate one where the config has been tampered with, therefore results in the immediate execution of an attacker-chosen binary.

The advisory sets out a four-step attack. An attacker commits a .knowns/config.json containing a binary path such as /tmp/evil.sh. A victim, or an AI coding agent acting on their behalf, clones the repository and opens it with knowns mcp or knowns browser. Auto-detection scans the project, finds a matching source file and loads the config. The payload then runs twice: once during the initial version check, described in the advisory as runVersionCheck, and again when Server.Start() spawns the LSP server process. The second run leaves the malicious process running as a long-lived background daemon.

Three files are named as the weak points. In internal/models/config.go, the advisory says the ProjectSettings.Validate() function checks task lifecycle durations but completely ignores the Binary field, so shell interpreters and untrusted executables are silently accepted. In internal/lsp/detect.go, the Detector.resolve() function passes the unvalidated override to exec.LookPath() before calling the binary with its check arguments. In internal/lsp/server.go, Server.Start() passes the same resolved path to a process command and starts it.

The advisory classifies the bug as CWE-829, inclusion of functionality from an untrusted control sphere, and compares it to what it calls the "malicious workspace" problem familiar from editors, citing historical VS Code issues where .vscode/settings.json could point to malicious interpreter paths. The core failure, it says, is the absence of a strict allowlist for executable paths: relying on exec.LookPath() means an attacker can bypass name resolution simply by supplying an absolute path or any path containing a slash.

The advisory also describes a chained scenario. Combined with previously identified config overwrite vulnerabilities, reached via path traversal in code.replace, a remote attacker could overwrite .knowns/config.json in a target project, inject a payload and trigger an LSP restart through docs.update or a server reload. That chain, the advisory says, yields remote code execution with no user interaction at all.

The agent angle is explicit in the write-up. Execution happens automatically on project load, and the LSP detector triggers on file extensions. In AI-driven workflows where agents scan project files to build context, the advisory notes, neither the user nor the agent needs to run a build or any other explicit command for the payload to fire.

The incident record lists the vulnerability's status as reported.