CVE-2026-86540: Arbitrary Code Execution via LSP Binary Override in knowns

The vulnerability CVE-2026-86540 describes an arbitrary code execution vulnerability in knowns, a developer tool and repository management application. The issue is located within the workspace configuration processing component, which handles project-level settings when a workspace directory is opened.\n\nIn vulnerable versions of the application, opening a directory containing a crafted .knowns/config.json configuration file allows the application to automatically parse and load settings without verification. The vulnerability is triggered during workspace startup, when the application attempts to initialize the Language Server Protocol (LSP) environment using paths specified in the configuration file.\n\nBecause the workspace initialization occurs automatically upon opening the directory, the application requires minimal user interaction to trigger the vulnerability beyond opening the workspace. This behavior exposes a significant attack surface to untrusted repositories, such as open-source projects or shared codebases.

The root cause of CVE-2026-86540 is a failure to sanitize and validate input in the settings.lsp.languages.<lang>.binary configuration property, which is mapped to the CWE-78 weakness class (Improper Neutralization of Special Elements used in an OS Command).\n\nWhen knowns initializes, the internal/lsp/detect.go component resolves the configured binary path via Detector.resolve. The resolution logic reads the user-supplied string from the local project configuration and instantiates a Binary object directly using this parameter without validation.\n\nBecause there is no verification that the user-supplied string matches a safe or pre-registered executable binary name, the application passes this unvalidated string to execution subshells. The execution is performed twice during the application workflow: first during workspace detection routines using functions like exec.LookPath, and second when starting the language server daemon via StartLanguage in internal/lsp/manager.go. Consequently, any system command or path to a local executable specified in the configuration file is executed with the privileges of the running application process.

The following diagram illustrates the technical execution flow from loading the malicious configuration to process execution under the user's privilege context.\n\nmermaid\ngraph LR\n A["Malicious Directory Opened"] --> B["Parse .knowns/config.json"]\n B --> C["Extract settings.lsp.languages.go.binary"]\n C --> D["Instantiate Binary with raw string"]\n D --> E["Detector.resolve checks binary"]\n E --> F["System executes payload via exec.LookPath / StartLanguage"]\n

The vulnerability exists in the way internal/lsp/detect.go resolves overrides. In vulnerable versions, the application takes the raw string directly from the config file and creates a Binary structure.\n\nBelow is the vulnerable code block from version 0.29.1:\n\ngo\n// Vulnerable Code in internal/lsp/detect.go\nfunc (d *Detector) resolve(ctx context.Context, root string, lang Language, override string) (ServerCommand, bool) {\n\tbinaries := lang.Binaries\n\tif override != "" {\n\t\tbinary := Binary{Name: override} // Raw, unvalidated override string is accepted\n\t\tif len(binaries) > 0 {\n\t\t\tbinary.CheckArgs = append([]string(nil), binaries[0].CheckArgs...)\n\t\t}\n\t\tbinaries = []Binary{binary}\n\t}\n\t// ...\n}\n\n\nThe official patch in version 0.30.0 addresses this by introducing strict whitelist verification functions within internal/lsp/binary_override.go. The validation functions verify that the override string is an exact match for one of the pre-registered binaries associated with the corresponding language adapter.\n\nBelow is the patched implementation of the verification and resolution routines:\n\ngo\n// Patched Code in internal/lsp/binary_override.go\nfunc selectBinaryOverride(override string, candidates []Binary) (Binary, error) {\n\tif strings.TrimSpace(override) != override || override == "" {\n\t\treturn Binary{}, invalidBinaryOverride(override)\n\t}\n\tfor _, candidate := range candidates {\n\t\tif candidate.Name == override {\n\t\t return candidate, nil // Returns the binary only if it matches a registered candidate\n\t\t}\n\t}\n\treturn Binary{}, invalidBinaryOverride(override)\n}\n\n// Patched Code in internal/lsp/detect.go\nfunc (d *Detector) resolve(ctx context.Context, root string, lang Language, override string) (ServerCommand, bool) {\n\tbinaries := lang.Binaries\n\tif override != "" {\n\t\tbinary, err := selectBinaryOverride(override, binaries)\n\t\tif err != nil {\n\t\t return ServerCommand{}, false // Safe rejection on invalid binary name\n\t\t}\n\t\tbinaries = []Binary{binary}\n\t}\n\t// ...\n}\n

An attacker exploits this vulnerability by distributing a repository containing a malicious .knowns/config.json configuration file. The target workspace configuration is set to point the LSP binary to a command interpreter or local script.\n\nTo demonstrate this concept, a workspace is configured with the following content within .knowns/config.json:\n\njson\n{\n "settings": {\n "lsp": {\n "languages": {\n "go": {\n "binary": "/bin/sh"\n }\n }\n }\n }\n}\n\n\nWhen the victim opens the repository containing this file with knowns, the workspace manager reads the configuration. During the language server initialization phase, the workspace engine attempts to run the binary identified as /bin/sh to launch the language server, leading to execution of the shell instead of the language tool. If the attacker also bundles a target execution payload, they can force execution of specific scripts by specifying path parameters.

The vulnerability poses a high risk to environments running knowns on untrusted repositories. Successful exploitation results in arbitrary command execution under the context of the user running the application.\n\nAccording to CVSS v4.0 metrics, this vulnerability has a base score of 8.5. The attack vector is local because the user must interact with and open the directory containing the malicious configuration file. There are no special execution conditions, and no administrative privileges are required to exploit the flaw.\n\nBecause the code runs within the user's active session, the attacker gains full read, write, and execute permissions over all files accessible to that user account. This can lead to credential theft, compromise of sensitive source code, and subsequent privilege escalation on the host system.

The primary remediation strategy is upgrading the application to version 0.30.0 or higher. Version 0.30.0 introduces structural input validation and prevents unauthorized binary overrides by rejecting non-registered executable names.\n\nIn environments where upgrading is not immediately possible, organizations must implement operational controls. Users must refrain from opening directories or repositories from untrusted sources, such as unverified public code repositories.\n\nAdditionally, system administrators should monitor process creation logs. Security tools should flag any instances where the application processes initiate system interpreters or command shells directly upon workspace loading.