Scope and safety. This is the reporter’s own analysis of a vulnerability coordinated through CERT/CC (VU#944667). It was published on 2026-11-12, the same day CERT/CC published the vulnerability note and the CVE record. The maintainer had already committed a fix by then. This article explains the broken data flow, the fix, and how to detect and mitigate the issue. It deliberately leaves out the proof-of-concept script given to CERT/CC, any payload, and any automated exploitation procedure. At the time of writing, the fix is on main but not in a tagged release, so many installs are still exposed.

Executive summary

CVE-2026-123790 affects ComfyUI-Easy-Use. It is one of the most-installed ComfyUI custom-node packs, with about 2,800 GitHub stars. The vulnerable code is in all tagged releases up to and including v1.4.1.

The extension registers POST /easyuse/save/{name}. Its intended job is to copy a generated image next to a checkpoint or LoRA so the image becomes that model’s preview thumbnail. ComfyUI has no authentication, so any client that can reach the server can call this route. The handler, save_preview() in py/routes.py, has three defects that combine:

1. The containment check covers the folder, not the file. The handler checks subfolder against the base directory. It then joins the request’s filename onto that folder and never checks the result again. os.path.join(base, "/abs/path") throws away base when the second part is absolute, so the attacker controls the copy source completely.
2. The destination category is unrestricted. The text before the first / in {name} is passed straight to folder_paths.get_full_path() as a folder type. custom_nodes is a registered folder type in ComfyUI core. So the copy destination can be any existing file under an installed custom node, including its __init__.py.
3. The destination takes the source file’s extension. The output path is splitext(destination)[0] + splitext(source)[1]. If the source is a .py file, the overwritten file is a .py file too.

Together these let a network client overwrite an installed node’s __init__.py with Python of their choosing. That code runs the next time ComfyUI imports custom nodes. In affected versions, the same extension also exposed an unauthenticated GET /easyuse/reboot that called os.execv on demand, so the attacker did not need to wait for a restart.

The CVE record, published by CERT/CC as CNA, classifies the bug as CWE-22 and gives no CVSS score. My own assessment, as submitted with the report, is CVSS 3.1 9.8 Critical, AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. The real-world condition is network reachability: ComfyUI binds to 127.0.0.1 by default. That covers every instance started with --listen and most hosted, Docker, RunPod, vast.ai and Colab images.

The point worth remembering is that this exact bug had already been fixed once. ComfyUI-Easy-Use’s save_preview() comes from the same handler in pythongosssss/ComfyUI-Custom-Scripts. On 2024-12-15, that project moved the commonpath check from the folder to the joined file path (5aa7f01). The fix never reached the copy.

Evidence labels used below:

• Verified: shown by the published source at a named tag or commit, by the CERT/CC case, or by testing against a local ComfyUI instance I control.
• Inferred: a deployment consequence derived from those facts. It is marked as inferred wherever it appears.

Key facts

Attack surface and trust boundary

ComfyUI is a local-first application, and its defaults show that. There are no users, no sessions and no API keys. Every HTTP route, whether core or registered by a custom node, is reachable by anyone who can open a TCP connection to it. The default bind address is loopback. The only security boundary in the default setup is the network.

In practice, that boundary is often removed on purpose. ComfyUI needs a GPU, and many users rent one, so they run it in a container on a cloud host with --listen 0.0.0.0 and reach it through a public port, a tunnel or a notebook proxy. Most one-click templates for hosted GPU services do this by default. Inferred: a large share of ComfyUI instances on the internet are reachable with no credentials at all, and fingerprinting them is easy.

Every custom node loads into that same unauthenticated process and registers routes on the same PromptServer. So a custom node’s HTTP routes are part of the server’s unauthenticated attack surface, whether or not the author had that in mind. save_preview() was written as a helper for the extension’s own front end. Nothing in the code suggests it expected to receive requests from anyone else.

Root-cause analysis

The vulnerable handler at v1.4.1 (py/routes.py, lines 260–285), with numbered annotations added:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

@PromptServer.instance.routes.post("/easyuse/save/{name}")
async def save_preview(request):
    name = request.match_info["name"]
    pos = name.index("/")
    type = name[0:pos]                     # (A) folder type, from the URL
    name = name[pos+1:]

    body = await request.json()

    dir = folder_paths.get_directory_by_type(body.get("type", "output"))
    subfolder = body.get("subfolder", "")
    full_output_folder = os.path.join(dir, os.path.normpath(subfolder))

    if os.path.commonpath((dir, os.path.abspath(full_output_folder))) != dir:   # (1)
        return web.Response(status=400)

    filepath = os.path.join(full_output_folder, body.get("filename", ""))       # (2)
    image_path = folder_paths.get_full_path(type, name)                          # (3)
    image_path = os.path.splitext(
        image_path)[0] + os.path.splitext(filepath)[1]                           # (4)

    shutil.copyfile(filepath, image_path)                                        # (5)

    return web.json_response({
        "image":  type + "/" + os.path.basename(image_path)
    })

The guard that exists

Line (1) is a real containment check, and it works for what it tests. A subfolder of ../../etc fails it. The problem is what it tests. It runs on full_output_folder, the directory, before the filename is added. Line (2) then joins body["filename"] onto that directory, and nothing checks the result.

os.path.join adds no protection here. Python’s documentation says that if a later part is absolute, all earlier parts are discarded. So a filename of /anything/at/all produces filepath == "/anything/at/all", and the check at (1) has already passed. A relative ../ sequence in filename escapes the same way.

This is the whole difference between Easy-Use and the upstream code it was copied from. The Custom-Scripts fix is three lines: compute filepath first, then run the same commonpath check on it.

1
2
3
4
5
6
7

-    if os.path.commonpath((dir, os.path.abspath(full_output_folder))) != dir:
+    filepath = os.path.join(full_output_folder, body.get("filename", ""))
+
+    if os.path.commonpath((dir, os.path.abspath(filepath))) != dir:
         return web.Response(status=400)

-    filepath = os.path.join(full_output_folder, body.get("filename", ""))

The destination nobody checked

Even with the upstream fix applied, line (3) is a separate problem, and the Custom-Scripts patch does not address it. type comes from the URL path, and get_full_path(type, name) resolves name inside whatever folder ComfyUI has registered under type. The handler expects checkpoints or loras, but it never enforces that.

ComfyUI’s folder_paths.py registers custom_nodes as a folder type, next to the model folders. get_full_path() returns a path only if the file already exists, which makes this an overwrite primitive rather than an arbitrary-create primitive. That limit does not help: every installed node has an __init__.py, and ComfyUI-Easy-Use itself is always installed when this route is present.

Getting a / into a single {name} path segment depends on aiohttp’s routing. The default {name} pattern does not match a literal /, but a percent-encoded %2F matches the segment and is decoded before it reaches match_info. I verified this on aiohttp 3.11.8, ComfyUI’s minimum, and on 3.14.3. In the handler, name then contains a real /, and index("/") splits it into a folder type and a relative file name.

The extension follows the source

Line (4) rebuilds the destination path from the destination’s stem and the source’s extension. For the intended use, this is sensible: a .webp preview next to model.safetensors becomes model.webp. For an attacker, it means the destination’s extension is also under their control. A .py source written over <node>/__init__ produces <node>/__init__.py, which is executable Python that ComfyUI imports by design.

Where the source comes from

The handler copies a file that already exists, so the attacker needs a file on disk containing their code. ComfyUI core supplies one: POST /upload/image is also unauthenticated and writes the uploaded bytes under the original filename into input/, without checking content or extension. I treat that as platform behaviour rather than part of this CVE, because an upload directory existing is not a vulnerability. The defects that turn it into code execution are (1)–(4) above, and they are in the extension.

The data flow, end to end

The server replies 200 with a JSON body naming the “image” it saved.

Turning a write into execution

An overwritten __init__.py does nothing until it is imported. In affected versions, the extension supplied that step too:

1
2
3
4

@PromptServer.instance.routes.get("/easyuse/reboot")
def reboot(request):
    ...
    return os.execv(sys.executable, [sys.executable] + sys.argv)

os.execv replaces the process image with a new ComfyUI. The new process imports every custom node at startup, including the overwritten one. Without this route, the payload still runs on the next ordinary restart. Inferred: hosted instances are restarted often (preemption, crashes, model swaps), so that wait would not be long.

Impact

Verified

• An unauthenticated network client can overwrite any existing file that ComfyUI’s folder registry can resolve, including any installed custom node’s __init__.py.
• The overwritten file runs as Python inside the ComfyUI process, with that process’s privileges, on the next custom-node import, and immediately in affected versions via /easyuse/reboot.
• No user interaction is needed. I confirmed the full chain against a local ComfyUI instance with a marker-file payload.

Deployment-dependent consequences (Inferred)

• Data: read and write access to models, LoRAs, inputs, outputs and saved workflows, plus any API keys in the environment. Hosted images often carry tokens for Civitai, Hugging Face, OpenAI-compatible endpoints or cloud storage.
• Host: many container images run ComfyUI as root, often with the GPU passed through. That makes cryptomining the obvious low-effort abuse, and the host a foothold for anything else.
• Persistence: the payload sits in a custom node’s entry point. It survives restarts and looks like part of an installed extension.

What bounds the severity

• Network reachability is the only real precondition. A ComfyUI instance on loopback with no other exposure is not reachable by this route.
• A drive-by from a browser is blocked. ComfyUI core’s origin_only_middleware returns 403 for requests carrying Sec-Fetch-Site: cross-site, so a malicious web page cannot fire this at localhost. The vector is a direct, non-browser client.
• The write is an overwrite. The target must already exist. Every install has suitable targets, so this limits the technique, not the outcome.

Safe validation and detection

Version and code check (the fast answer)

Look at custom_nodes/ComfyUI-Easy-Use/py/routes.py. If save_preview() contains pos = name.index("/") and runs its commonpath check before filepath is assigned, the install is vulnerable. If it contains model_type not in ("checkpoints", "loras"), it has the fix. A version = "1.4.1" in pyproject.toml does not mean you are fixed, because the fix landed after that tag without a version bump.

Exposure check

Check whether ComfyUI is listening on anything other than loopback (ss -ltnp | grep 8188, the container’s published ports, any tunnel or notebook proxy in front of it). If it is, and the code above is the vulnerable version, assume the instance has been reachable for as long as it has been running.

Telemetry and integrity worth reviewing

• Access logs, at a reverse proxy if one exists, for POST /easyuse/save/ where the path contains custom_nodes, or any path segment other than checkpoints or loras.
• GET /easyuse/reboot requests you did not trigger from the UI, especially shortly after a POST /easyuse/save/.
• POST /upload/image requests uploading files with non-image extensions.
• Integrity of every custom_nodes/*/__init__.py against the upstream repository (git -C custom_nodes/<node> status / git diff). Unexpected changes to an entry point are the clearest sign of compromise.
• .py files in ComfyUI’s input/ directory.

I am deliberately not publishing a scanner or exploit request. The code check above answers the question without sending anything to a live instance.

Remediation and hardening

Required

Update ComfyUI-Easy-Use to a build that includes commit 8a0f2fc412. At the time of writing that means tracking main (for example git -C custom_nodes/ComfyUI-Easy-Use pull, or the “nightly” channel in ComfyUI-Manager). The latest tagged release, v1.4.1, does not contain the fix. Restart ComfyUI afterwards.

VU#944667 says the maintainer could not be reached and recommends removing the extension or limiting network access to trusted users. That guidance is correct for any tagged release. The maintainer did commit a fix to main on 2026-09-29 without responding to the case, so tracking main is a third option.

If you cannot update immediately

• Do not expose ComfyUI to untrusted networks. Remove --listen, or bind to loopback and reach the instance over SSH port forwarding or an authenticated VPN.
• If it must be reachable, put an authenticating reverse proxy in front of it. At minimum, deny /easyuse/save/ and /easyuse/reboot at the proxy.
• If you do not use the extension, uninstall it.

If the instance was exposed

Treat it as potentially compromised, not just as needing a patch. Check custom-node integrity as described above. Rotate any credentials present in the environment or on disk. Rebuild from a clean image rather than cleaning in place: a modified __init__.py is easy to spot, but whatever it installed after it ran may not be.

What the patch does

Commit 8a0f2fc412 (“fix: harden model metadata and preview routes (#1045)”) rewrites save_preview() around what it is actually for:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

model_type, separator, model_name = name.partition("/")
if not separator or model_type not in ("checkpoints", "loras"):
    return web.Response(status=400)
if model_name not in folder_paths.get_filename_list(model_type):
    return web.Response(status=404)
...
if (body.get("type") != "temp" or body.get("subfolder", "") != ""
        or not isinstance(filename, str) or not filename
        or os.path.basename(filename) != filename or filename in (".", "..")):
    return web.Response(status=400)

extension = os.path.splitext(filename)[1].lower()
if extension not in _PREVIEW_FORMATS:
    return web.Response(status=400)

Each of the three defects is closed at its own point:

• Destination: type must be checkpoints or loras, and the model name must appear in ComfyUI’s own file list for that type. custom_nodes is no longer reachable.
• Source: it must come from temp, with no subfolder, as a bare filename (basename(filename) == filename). It is then checked again with realpath-based containment against the temp directory and must be a regular file. The check now runs on the final path, after the join.
• Extension: it must be one of .png, .jpg, .jpeg, .webp, .gif. The file is copied to a temp file next to the target, opened with Pillow, checked to be the format its extension claims, and only then moved into place with os.replace. The handler also refuses symlinked targets and targets outside the model’s own directory.

This is a stronger fix than the upstream Custom-Scripts patch, which only moved the containment check. The commit adds tests/test_routes_security.py.

A note on the reboot route

The same commit changes /easyuse/reboot to POST and requires an X-EasyUse-Reboot-Token header. The token is served by GET /easyuse/reboot-token, and both are gated on a same-origin check. That closes the browser vector described in issue #1045. It does not stop a direct network client: a request without Sec-Fetch-Site and Origin headers passes _same_origin_request(), so a non-browser client can fetch the token and then use it. In this CVE’s threat model, the fix that matters is the save_preview() restriction. Without a write primitive, restarting the server achieves nothing. I don’t consider this a remaining vulnerability, because a client with direct network access to an unauthenticated ComfyUI already controls the server through core features like the queue. It is still worth being precise about which part of the patch does the work.

Timeline

On #1045. Issue #1045 was filed publicly a month after my CERT/CC report and two days before the fix. It reaches the same destination primitive (get_full_path() with an unrestricted custom_nodes type, and the source extension carried to the destination), triggered by script running in the victim’s own ComfyUI tab after a malicious model’s notes are rendered unescaped. As far as I can tell, the two findings were made independently. They are different entry points: #1045 needs a victim to open a model’s info dialog and is scored AV:L/UI:R, while this report is a direct, unauthenticated network request, and it also covers the copy-source ordering bug that #1045 does not depend on. The maintainer’s fix addresses both. Credit for the browser chain belongs to 3em0.

Lessons for builders

When you copy code, check whether its fixes followed

save_preview() was copied from ComfyUI-Custom-Scripts, and the bug was fixed there in December 2024. Easy-Use still shipped the pre-fix version through September 2026. If you vendor or fork a security-relevant function, record where it came from and watch the original for changes. One git log -p on the original file would have caught this. When I find a bug in derived code, I run the same check in reverse: diffing against the parent here took a few minutes and showed the bug was a fix that had never been ported.

Check the final path, after the last join

A containment check that runs before the last path component is added only tells you something about the directory. The rule is mechanical: compute the exact path you will pass to open, copyfile or replace, resolve it, and check that. Do nothing to the path afterwards. os.path.join with an absolute second argument, .., and symlinks are three different ways for anything later to undo the check.

Allowlist the category, not just the path

Even with correct containment, get_full_path(type, ...) with a caller-chosen type lets the caller pick which tree to stay contained in. “Stay inside custom_nodes“ is still a vulnerability. A helper that exists to save model previews should only accept the folder types it serves. The fix’s ("checkpoints", "loras") tuple is the most important line in it.

Don’t let the input decide the output’s type

Taking the destination extension from the source file meant the attacker chose both what was written and what kind of file it became. When an operation produces a specific file type, the code should fix that type and verify the content, as the patch does with Pillow, rather than inherit it from the input.

A plugin’s routes are the host’s attack surface

Every route a custom node registers is served by the same unauthenticated server as ComfyUI’s core API. That doesn’t make every custom node author responsible for ComfyUI’s lack of authentication. It does mean a route that writes files or restarts the process can’t assume the only caller is the extension’s own front end.

Related reading

• CVE-2026-105744: Docling Arbitrary File Read/Write via Untrusted TikZ: a correct guard placed one layer too early
• CVE-2026-86775: knowns Path Traversal via the Document API: containment belongs at the sink
• CVE-2026-57572: Crawl4AI Unauthenticated RCE via Chromium Argument Injection: another AI-tooling server that trusted its network

References

• CVE.org record: CVE-2026-123790
• CERT/CC Vulnerability Note VU#944667
• Fix commit 8a0f2fc412: harden model metadata and preview routes
• Follow-up commit 67afdc8204: make reboot routes awaitable
• ComfyUI-Easy-Use issue #1045
• save_preview() at v1.4.1
• reboot() at v1.4.1
• ComfyUI-Custom-Scripts fix 5aa7f01: Fix filepath validation
• ComfyUI folder_paths.py
• Python documentation: os.path.join

Reported by Nguyễn Huy Hoàng (hoanggxyuuki), PTIT, through CERT/CC. Thanks to my teacher, Nguyễn Huy Trung, for his guidance, and to Michael Bragg and the CERT/CC coordination team for handling a case with no reachable vendor contact. Public vulnerability records are often revised after publication, so recheck the primary sources above before relying on them for remediation.

Scope and safety. This is third-party analysis of a fixed, publicly disclosed vulnerability, written from the vendor’s own advisory, CVE record, patch commit and published source. It describes the defective data flow and the remediation. The upstream advisory publishes a minimal proof of concept; this article deliberately does not reproduce a weaponised document, target path list, or exploitation procedure. The TeX primitives named below are named in the CVE description and in the vendor’s own fix, and are documented features of the TeX language.

Executive summary

CVE-2026-105744 affects Docling — IBM’s document-parsing library, and one of the most widely used ingestion front-ends for RAG and LLM pipelines — in versions from 2.94.0 until 2.132.0, for both the docling and docling-slim distributions.

When a caller opts into TikZ rendering with LatexBackendOptions(tikz_engine="tectonic"), Docling takes the tikzpicture body and the document preamble verbatim out of the input .tex file, wraps them in a standalone document, and compiles that document with the tectonic binary. Nothing restricts what TeX may do with its own file primitives while that compilation runs.

A crafted .tex file can therefore:

• read any file the converter process can read, via \input, \verbatiminput or \openin — and the content can be typeset into the rendered image that lands in the conversion output, which makes this an exfiltration channel, not just a local read;
• create or overwrite any file the process can write, via \immediate\openout and \write. Neither requires shell escape;
• run shell commands through \write18, if the caller additionally set tikz_engine_allow_shell_escape=True.

The weaknesses are CWE-22 (path traversal), CWE-73 (external control of file name or path) and CWE-1188 (insecure default initialization). GitHub, as CNA, scores it CVSS 3.1 7.5 High — CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H.

The detail that makes this worth reading is not the bug class. It is that Docling already had a correct path-traversal guard, and the guard was irrelevant. _resolve_local_dependency() rejects absolute paths, resolves candidates, calls is_relative_to(source_root), and logs "Path traversal attempt blocked". All of that is real, and all of it governs only which files Docling copies into the temporary build directory. It says nothing about what TeX may open once Docling invokes it. The boundary was enforced one layer too early.

Fixed in docling 2.132.0.

Evidence labels used below:

• Verified means stated by the CVE record, the GitHub Security Advisory, the patch commit, or the project’s published source and release material.
• Inferred means a deployment consequence derived from those facts and clearly marked as such.

Key facts

Why this matters for document-ingestion pipelines

Docling’s entire job is to accept documents from somewhere else. That is the product. A parser that only handles files you authored is not a parser, it is a renderer — so for this class of library, “the input is untrusted” is not an edge case, it is the default operating condition.

That matters because of where Docling sits. It is the ingestion stage in front of a vector store, a chunker, an LLM. The files reaching it are uploads, email attachments, arXiv tarballs, scraped corpora, CI artefacts, documents a user dropped into a chat window. The process doing the parsing typically runs with ambient credentials that have nothing to do with the document: API keys in the environment, a cloud metadata endpoint one hop away, a writable model cache, a shared scratch volume.

Three consequences follow, and they are what separates this from a generic file-read bug:

1. The read is an exfiltration channel, not just a read. The advisory is explicit that file content “can be typeset into the rendered picture that ends up in the conversion output.” So the attacker does not need a callback, an egress path, or a second request. They submit a document, and the secret comes back to them inside the rendered figure of the parsed result — through whatever interface normally returns parsed documents to users.

2. An arbitrary write in an ingestion worker is a code-execution primitive. The advisory notes that “writing to startup or configuration files can lead to code execution.” Inferred: in a long-lived worker, a Python path, a shell profile, a sitecustomize.py, a cron fragment or a config file read on next start are all plausible targets. The attacker does not need the write to be immediate — ingestion workers restart.

3. Nothing about this requires authentication to Docling. Docling is a library. PR:N in the vector is accurate because the privilege that matters is “can submit a document to the pipeline,” and that is frequently the least-privileged action a product offers. The UI:R reflects that someone must convert the file — which, in an automated ingestion pipeline, is what the pipeline exists to do.

This is the fourth entry on this site in the same pattern: an AI-infrastructure component treats a configuration-shaped field as data when it is really control. CVE-2026-57572 did it with Chromium launch arguments. CVE-2026-86439 did it with a filesystem path. This one does it with a TeX document — which is worse in kind, because TeX is not a format, it is a programming language.

Attack surface and trust boundary

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

Untrusted .tex document  (upload, attachment, scraped corpus, CI artefact)
        |
        | whole file
        v
LatexDocumentBackend
        |
        +-- preamble  = everything before \begin{document}, verbatim
        +-- tikz_raw  = tikzpicture body, verbatim
        |
        | if options.tikz_engine == "tectonic"
        v
TectonicEngine.render(tikz_raw, preamble, source_root)
        |
        +-- _stage_local_dependencies()   <-- the guard lives here
        |      path checks: absolute rejected, is_relative_to(source_root)
        |      governs: WHICH FILES GET COPIED into the temp dir
        |
        +-- compose standalone document, write diagram.tex
        |
        v
subprocess.run([tectonic, "--print", "diagram.tex"])  ---- language boundary ---->
        |
        v
TeX interpreter: \input  \openin  \openout  \write  \write18
        |
        v
Everything the converter process can read or write

The guard and the sink are separated by a boundary that the guard cannot see across. _stage_local_dependencies operates on Python strings and pathlib objects, before the compile. The TeX interpreter operates on its own file primitives, during the compile, with the full authority of the process. There is no relationship between the two other than the fact that both happen to involve files.

Root-cause analysis

The guard that exists

From docling/backend/latex/engines/tectonic.py at v2.131.0:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

@classmethod
def _resolve_local_dependency(
    cls, source_root: Path, raw_path: str, *, is_tex: bool
) -> Path | None:
    raw_path = raw_path.strip()
    if not raw_path:
        return None

    candidate = Path(raw_path)
    if candidate.is_absolute():
        _log.warning("Absolute TikZ dependency paths are not staged: %s", raw_path)
        return None

    resolved = (source_root / candidate).resolve()
    try:
        if not resolved.is_relative_to(source_root):
            _log.warning(
                "Path traversal attempt blocked for TikZ dependency: %s", raw_path
            )
            return None
    except ValueError:
        _log.warning("Invalid TikZ dependency path: %s", raw_path)
        return None
    ...

Read in isolation, this is good code. It rejects absolute paths. It calls .resolve() before the containment check, so symlinks and .. segments are collapsed first — which is the ordering most path-traversal bugs get wrong. It fails closed. It even logs the attempt.

It is also, for the purposes of this CVE, decoration. Note what it returns: a Path that _stage_local_dependencies will shutil.copy2 into the temporary directory. Its only output is a copy decision. The advisory states the same thing in one sentence: _resolve_local_dependency “only decides which files are staged into the temporary directory. It does not limit what TeX opens at compile time.”

So \input{../../../../etc/passwd} is correctly refused staging. And then the string \input{../../../../etc/passwd} is written into diagram.tex unchanged, and tectonic is asked to compile it. TeX resolves that path itself, relative to its own working directory, using its own file-opening machinery, and never consults Docling about it.

The document that gets compiled

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

latex_doc = (
    "\\documentclass[border=20pt]{standalone}\n"
    + preamble
    + "\n"
    + "\\begin{document}\n"
    + tikz_code
    + "\n"
    + "\\end{document}\n"
)

with tempfile.TemporaryDirectory() as temp_dir:
    temp_path = Path(temp_dir)
    self._stage_local_dependencies(temp_path, preamble, tikz_code, source_root)
    tex_file = temp_path / "diagram.tex"
    tex_file.write_text(latex_doc, encoding="utf-8")

    cmd = [str(self.binary_path)]
    if self.allow_shell_escape:
        cmd.extend(["-Z", "shell-escape"])
    cmd.append("--print")
    cmd.append(str(tex_file))

Two attacker-controlled regions are concatenated into that document, and it is worth being precise about both, because one of them is easy to miss.

tikz_code is the tikzpicture body. That one is obvious.

preamble is everything in the input file before \begin{document}, with only the \documentclass line removed. From docling/backend/latex/backend.py:

1
2
3
4
5
6
7
8

preamble_match = re.search(
    r"^(.*?)\\begin\{document\}", preprocessed_text, re.DOTALL
)
if preamble_match:
    raw_preamble = preamble_match.group(1)
    self.latex_preamble = re.sub(
        r"\\documentclass(?:\[[^\]]*\])?\s*\{[^}]*\}", "", raw_preamble
    )

The only filtering applied to it before compilation is _sanitize_preamble_for_tectonic(), which comments out three pdfTeX assignment primitives (\pdfcompresslevel, \pdfminorversion, \pdfobjcompresslevel) because Tectonic does not implement them. That is a compatibility shim, not a security control, and the code says so in its own docstring: “Drop assignment-only pdfTeX primitives Tectonic/XeTeX does not provide.”

So the attacker controls a full LaTeX preamble — the part of a document where you are supposed to put \usepackage, macro definitions, and \immediate\write calls. The preamble is not a constrained region. It is the configuration section of a programming language.

The sink is an interpreter

This is the part that makes the bug class interesting rather than routine. The sink is not open(). It is not os.path.join. It is:

1
2
3
4
5
6
7

subprocess.run(
    cmd,
    cwd=temp_dir,
    capture_output=True,
    check=True,
    timeout=self.timeout,
)

tectonic is a TeX engine, and TeX is Turing-complete with first-class file I/O. \openin and \openout are not obscure corners; they are the primitives that \include, auxiliary files, .toc generation and every cross-referencing package are built on. Removing them would break LaTeX.

Which means there is no flag you can pass to a TeX engine that says “be a renderer, not a program.” The capability is the language. Once Docling decided to hand attacker-composed source to tectonic, the only remaining question was what the operating system would permit — and cwd=temp_dir sets the working directory, which is not a jail. An absolute path ignores it, and .. walks out of it.

The insecure default

Separately, from the same file at v2.131.0:

1
2
3
4
5

def __init__(
    self,
    timeout: float = 60.0,
    allow_shell_escape: bool = True,
):

The constructor defaulted shell escape on — that is the CWE-1188 component. In practice the LaTeX backend always passes the value explicitly:

1
2
3
4

self._tectonic_engine = TectonicEngine(
    timeout=opts.tikz_engine_timeout,
    allow_shell_escape=opts.tikz_engine_allow_shell_escape,
)

and LatexBackendOptions.tikz_engine_allow_shell_escape defaults to False. So the bad default is only reachable by code that instantiates TectonicEngine directly, which the advisory states plainly. It is still worth flagging, because “the only caller in this repository happens to pass the argument” is a property of today’s call graph, not of the API. Any downstream integration, notebook, or future call site that writes TectonicEngine() gets \write18 with no indication that it opted into anything.

The in-memory case removes even the staging

1
2
3
4

preamble = self.latex_preamble
source_root = None
if isinstance(self.path_or_stream, Path):
    source_root = self.path_or_stream.parent

source_root is set only when the input is a filesystem Path. For a DocumentStream — the normal way to feed Docling bytes from an upload, a queue, or an HTTP handler — it stays None, and _stage_local_dependencies returns immediately:

1
2

if source_root is None:
    return

No staging happens, so none of the path validation runs at all. But tex_file.write_text(latex_doc) and subprocess.run(cmd) happen regardless. The compile proceeds with the attacker’s document and zero path checks.

Inferred: this is the configuration most likely to be in production. A service accepting uploads holds bytes, not paths. So the deployment shape with the least input validation is also the one most exposed to untrusted documents — the staging guard is most active exactly where the input is most likely to be trusted (a local file you pointed the CLI at), and entirely absent where it is least likely to be trusted.

The data flow, end to end

Step 4 is the only step with a security check in it, and it is the only step that does not touch the data that reaches step 6.

Why --untrusted was not the answer on its own

The obvious reading of the fix is “pass Tectonic its hardening flag.” That is part of what the patch does, and it is not sufficient — and the advisory is unusually candid about why:

\immediate\openout / \write create or overwrite files outside the temporary directory. Neither needs shell escape. Tectonic’s --untrusted flag does not block them either.

--untrusted turns off shell escape and extra search paths. It does not turn off TeX’s own write primitives, because those are load-bearing for ordinary documents. So even a correctly hardened invocation leaves the arbitrary-write primitive intact. That is why 2.132.0 needs a source inspection step in addition to the flags — and why the source inspection is the weaker half of the fix.

Impact

Verified

• Arbitrary file read, limited to what the converter process can read, via \input, \verbatiminput and \openin.
• Content disclosure back to the attacker, because read content can be typeset into the rendered picture included in the conversion output.
• Arbitrary file create and overwrite, limited to what the process can write, via \immediate\openout and \write, with no shell escape required.
• Arbitrary command execution when tikz_engine_allow_shell_escape=True, via \write18.
• The advisory states that writing to startup or configuration files can lead to code execution even without shell escape.

Deployment-dependent consequences (Inferred)

• Credential disclosure. An ingestion worker’s environment, cloud credential files, .netrc, Kubernetes service-account token, or SSH keys are all ordinary files to a process that can read them.
• Pivot to cloud metadata. Not directly — TeX’s primitives are file primitives, not network ones. But a read of a credential file on disk achieves the same end result as the metadata SSRF path, without needing a URL fetch.
• Persistence across restarts. A write that lands in an interpreter startup path or a service config file executes on the next worker start. Ingestion workers restart often.
• Poisoning the pipeline’s own output. A write into a shared scratch or output volume can alter what downstream chunking and embedding stages consume, which is a data-integrity problem the pipeline has no reason to check for.
• Multi-tenant blast radius. A shared converter pool processes documents from many tenants with one identity. One tenant’s upload reads and writes as that identity.

What bounds the severity

Honesty about the limits matters as much as the impact list, and the AC:H / UI:R in the vector is doing real work here:

• The default configuration is not affected. tikz_engine defaults to None.
• Docling does not install tectonic. The binary must already be on PATH or in the Docling cache.
• The CLI cannot enable it. Reaching this requires Python code that constructs LatexBackendOptions(tikz_engine="tectonic").
• Shell escape is off by default in the backend path.

That is a genuinely narrow precondition set, and it is the right reason this is 7.5 and not 9-point-something. But “opt-in” describes who is exposed, not how exposed they are. A caller who enabled TikZ rendering did so to render diagrams, and had no way to know the option also handed every submitted document a file-I/O-capable interpreter. The option’s description, before 2.132.0, read: “Set to ‘tectonic’ to enable asynchronous image generation.”

Safe validation and detection

Configuration review — this is the fast answer

The exposure question is almost entirely answerable statically, without touching a running system:

• Search your codebase for tikz_engine. If no call site sets it to "tectonic", you are not affected, regardless of installed version.
• Search for tikz_engine_allow_shell_escape=True. Any hit is a finding on its own merit, at any version, including 2.132.0.
• Search for direct TectonicEngine( instantiation. Those call sites inherited allow_shell_escape=True before 2.132.0.
• Check whether a tectonic binary exists on PATH or at ~/.cache/docling/tectonic in the converter image.
• Pin the installed version: pip show docling docling-slim. Affected range is >= 2.94.0, < 2.132.0.

Telemetry worth reviewing

If tikz_engine="tectonic" was enabled on an affected version and untrusted documents were processed, absence of an alert is not evidence of absence — none of this triggers a security control by default. What is reviewable:

• Docling logs for "Path traversal attempt blocked for TikZ dependency" and "Absolute TikZ dependency paths are not staged". These indicate a document that named an outside path. They do not indicate the compile was prevented — and a document using \openout directly produces no log line at all. Treat a hit as a signal to investigate the document, and absence of hits as uninformative.
• File-integrity monitoring on config, startup and interpreter paths writable by the converter user, over the window the affected version was deployed.
• Process creation under the converter process. Relevant only if shell escape was enabled.
• Unexplained files in scratch or output volumes, correlated with conversion timestamps.
• Rendered figures in stored conversion output that contain text rather than a diagram. That is what a successful read looks like in the artefact.

Review the documents themselves if you retained them. A static scan of stored .tex inputs for \openout, \openin, \write18 and absolute-path \input is cheap and is the most direct evidence available.

Remediation and hardening

Required

Upgrade to docling >= 2.132.0 (or docling-slim >= 2.132.0). There is no configuration change that fully substitutes for it, because the write primitive survives correct flag hardening.

If you cannot upgrade immediately

Both of these come from the advisory’s own workarounds section:

• Set tikz_engine=None (the default) for any pipeline that handles untrusted input. You lose rendered TikZ diagrams; you keep the TikZ source as code metadata, which is the same fallback 2.132.0 uses when it declines to render.
• Never set tikz_engine_allow_shell_escape=True for untrusted input, on any version.

Regardless of version — and the vendor says this too

This is the part not to skip. The 2.132.0 documentation itself states:

The pre-check only reads the source text and does not cover every way TeX can access files. When rendering untrusted LaTeX with Tectonic, run the conversion in an isolated environment, for example a container without host mounts or network access.

So, for any pipeline that renders untrusted LaTeX:

• Run conversion in a container with no host mounts, a read-only root filesystem, and a dedicated writable tmpfs for the build directory only.
• Give it no network, which removes the metadata-endpoint and egress concerns wholesale.
• Give it no credentials. An ingestion worker that parses documents does not need a cloud key in its environment; if it needs one to store results, put that on the other side of a queue.
• Run as a non-root user with no write access to anything outside the scratch directory.
• Enforce the tikz_engine_timeout, and treat a timeout as a signal rather than a retry.

The reason to do all of this even on 2.132.0 is that the fix is explicitly best-effort. The container is the control that actually holds.

What the patch does, and what it admits it cannot do

The fix is commit 38b6fa0 via PR #4419, released in 2.132.0. It has three parts.

1. The default flipped, and hardening flags were added.

1
2
3
4
5
6
7
8
9
10
11
12
13
14

def _build_command(self, tex_file: Path) -> list[str]:
    """Build the Tectonic command line for compiling ``tex_file``."""
    cmd = [str(self.binary_path)]
    if self.allow_shell_escape:
        # --untrusted would disable shell escape, so it is not added here.
        cmd.extend(["-Z", "shell-escape"])
    else:
        # --untrusted disables shell escape and extra search paths;
        # --only-cached prevents network fetches of bundle files.
        cmd.append("--untrusted")
        cmd.append("--only-cached")
    cmd.append("--print")
    cmd.append(str(tex_file))
    return cmd

allow_shell_escape now defaults to False, closing the CWE-1188 gap for direct instantiation. --only-cached is a nice secondary hardening: it stops Tectonic fetching bundle files on demand, removing a network dependency from the compile.

2. A best-effort source pre-check.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

_PATH_ARGUMENT_PATTERN = re.compile(
    r"\\(?P<command>input|include|includegraphics|InputIfFileExists|graphicspath)"
    r"(?![A-Za-z])\*?(?:\s*\[[^\]]*\])?\s*\{*\s*(?P<path>[^{}\s]*)"
)
_FILE_PRIMITIVE_PATTERN = re.compile(
    r"\\(?P<command>openin|openout|XeTeXpicfile|XeTeXpdffile)(?![A-Za-z])"
)

@classmethod
def _find_unsafe_construct(cls, text: str) -> str | None:
    """Return a description of the first outside file reference, if any."""
    primitive = cls._FILE_PRIMITIVE_PATTERN.search(text)
    if primitive is not None:
        return f"\\{primitive.group('command')}"
    for match in cls._PATH_ARGUMENT_PATTERN.finditer(text):
        path = match.group("path")
        if (
            path.startswith(("/", "\\", "~"))
            or re.match(r"[A-Za-z]:", path)
            or ".." in re.split(r"[/\\]", path)
        ):
            return f"\\{match.group('command')} with path {path!r}"
    return None

Two things about this are well judged. It runs over every staged file and the generated diagram.tex itself, not just the TikZ body — so the attacker-controlled preamble is in scope. And when it matches, rendering is skipped and the diagram degrades to TikZ source metadata rather than failing the conversion, so the control is unlikely to be disabled for being disruptive.

3. The option description was rewritten to say what the option now implies, including that the check is best-effort.

The limits, stated by the vendor

The advisory does not oversell the fix:

This check is best-effort. It reads the source text, and TeX can open files in ways a text check cannot see, for example through package commands or names built by macros.

That is the correct characterisation. A regex over TeX source cannot be complete, because TeX constructs control sequences at runtime — \csname, \expandafter, catcode reassignment — and a name assembled during expansion is not present in the source text to be matched. The pre-check raises the cost of exploitation; it does not establish a boundary.

Two further observations, from reading the patch rather than the advisory:

• The pre-check does not run when shell escape is enabled. The call site is if not self.allow_shell_escape and not self._precheck_staged_files(temp_path). This is deliberate and documented — the docs state that enabling shell escape “skips the source pre-check described below” — but the consequence is worth naming: setting tikz_engine_allow_shell_escape=True on 2.132.0 gives you the pre-2.132.0 exposure plus \write18. The option is not a performance toggle.
• An earlier, stricter version of the check was deliberately simplified before merge. The PR’s commit messages record an intermediate implementation that also skipped rendering when the source “builds control sequences indirectly” and when it “uses package commands and options that read or write files.” The final commit, titled “fix(latex): simplify the Tectonic source pre-check,” states that it “replace[s] the broad control-word scan” with the narrower pattern pair shown above. That is a defensible trade — a broad control-word scan over real-world LaTeX will refuse to render a great many legitimate documents — but it means the shipped check knowingly does not cover the \csname class that the advisory then names as a limitation.

This is not a criticism of the patch so much as the reason the patch ships with a documentation note telling you to use a container. The maintainers fixed what is fixable in a text check and were explicit about the residual risk. That is the right way to handle a bug where the sink is an interpreter.

Timeline

The sequencing is worth noting as good practice: the fix was merged, then released, then the advisory was published two hours after the release, and the CVE identifier was attached four days later. Users who track releases had the patch available before the vulnerability was public.

Lessons for builders

A guard belongs at the sink, not at the stage before it

Docling’s path validation was correct, ordered properly, and fail-closed. It also could not possibly have prevented this, because it guarded the copy step while the damage happened in the compile step. When you write a containment check, name the operation it contains. If you cannot name one, you have written a filter, not a boundary.

This is the same lesson as the knowns set from the opposite direction. There, the defect was that filepath.Join composes and cleans but never constrains, and the fix was to move containment down into the storage layer where every caller inherits it. Here the project had containment logic but attached it to the wrong operation. Both failures are about layer placement, not about path parsing.

Handing untrusted input to an interpreter is a sandbox decision

\openout is not a vulnerability in TeX. It is a documented feature that LaTeX’s own cross-referencing depends on. There is no flag that makes TeX safe for untrusted input, which means the decision “compile this attacker-controlled document” is irreversibly a decision about what the surrounding process is allowed to touch.

The practical test: if your mitigation is a pattern list over the input language, ask whether that language can build names at runtime. If it can — TeX, shell, SQL with dynamic identifiers, any template engine with reflection — the pattern list is a cost increase, and the real control is process isolation. Write the pattern list anyway. Just do not let it be the only thing.

“Opt-in” bounds who is affected, not how badly

The narrow precondition set is the honest reason this scored 7.5. It is not a reason to deprioritise it, because the people who opted in are exactly the people processing LaTeX — which overwhelmingly means academic papers, arXiv sources and submitted documents. The population that enabled the feature correlates strongly with the population handling untrusted input.

And they could not have known. The option read “enable asynchronous image generation.” Nothing in that sentence suggests a file-I/O-capable interpreter. If an option changes the trust model, the option’s own description is where it has to say so — which is precisely what 2.132.0 changed it to do.

Check what happens when the optional guard is absent

The most exposed configuration here is the one where source_root is None, because a DocumentStream has no parent directory. The validation silently did not run, and the compile proceeded anyway. Whenever a security check is conditional on a value being present, enumerate the cases where it is not — and make sure the dangerous operation is gated on the same condition the check is. Here, return on a missing source_root skipped the guard; it should have been a decision about whether to render at all.

Read the vendor’s stated limitations as part of the fix

2.132.0’s documentation says the pre-check is best-effort and tells you to use an isolated environment. That note is not boilerplate — it is the maintainers accurately describing where the boundary now is. An upgrade that ignores it leaves you patched against the published proof of concept and exposed to the class. Treat “upgrade” and “the advisory’s hardening guidance” as one remediation, not two.

Related reading

• CVE-2026-57572: Crawl4AI Unauthenticated RCE via Chromium Argument Injection — a configuration field crossing into a process-launch grammar
• CVE-2026-86775: knowns Path Traversal via the Document API — containment belongs at the sink
• CVE-2026-86439: knowns Path Traversal in the MCP Doc and Memory Tools — the same sink reached from a second entry point
• CVE-2026-55533: PraisonAI Recipe Authorization Fail-Open — a check that ran and decided nothing

References

• CVE.org record: CVE-2026-105744
• NIST National Vulnerability Database: CVE-2026-105744
• GitHub Security Advisory: GHSA-x3q2-h9hx-4r4j
• Fix commit 38b6fa0
• PR #4419: run Tectonic without shell escape and skip TikZ that references outside files
• docling v2.132.0 release
• TectonicEngine.__init__ at v2.131.0 — allow_shell_escape=True
• _resolve_local_dependency at v2.131.0 — the guard
• TectonicEngine.render at v2.131.0 — the unguarded compile
• _process_tikzpicture at v2.131.0 — the call site
• _find_unsafe_construct and _precheck_staged_files at v2.132.0
• _build_command at v2.132.0
• docling pipeline options reference — TikZ rendering
• Tectonic typesetting documentation

This is independent analysis of a vulnerability reported by others; the GitHub advisory credits reporters who are not publicly named. Recheck the primary sources above during remediation — public vulnerability records are frequently revised after publication.

Scope and safety. This article analyses a fixed, publicly disclosed vulnerability using the vendor’s own published source references. It describes the defective data flow and the remediation. It does not include working traversal strings, target path lists, or a runnable proof of concept.

Executive summary

CVE-2026-86775 is a path-traversal vulnerability in the HTTP Document API of knowns before 0.30.0. The route layer passes the caller-supplied document path through a helper called cleanDocPath(), which trims a leading slash, a trailing .md, and surrounding separators — and leaves parent-directory segments completely untouched. The storage layer then joins that value onto the documents directory with filepath.Join and never checks that the result stayed inside it.

The result is read, create, overwrite and delete of arbitrary .md files anywhere the process can reach, plus creation of arbitrary directories through os.MkdirAll.

The weakness is CWE-22: Improper Limitation of a Pathname to a Restricted Directory. The vendor scores it CVSS 4.0 8.8 High (CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:H/VA:L/SC:N/SI:N/SA:N) and CVSS 3.1 8.6 High (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:L).

This is the eighth CVE in the knowns 0.30.0 set, and it is the most instructive one, because it is a variant rather than a new bug. CVE-2026-86439 covered the same unsafe join in internal/storage/doc_store.go reached through the MCP doc and memory tools. This CVE covers the same storage layer reached through the unauthenticated HTTP Document API — and where the MCP path was mostly a read primitive, this one carries write, delete, and directory creation with it.

The PR:N in the vector comes from CVE-2026-86543: the management API was unauthenticated and bound to every interface by default.

Fixed in knowns 0.30.0.

Evidence labels used below:

• Verified means stated by the CVE record, the GitHub Security Advisory, or the project’s published source and release material.
• Inferred means a deployment consequence derived from those facts and clearly marked as such.

Key facts

The routes involved

From internal/server/routes/docs.go at v0.29.1:

1
2
3
4
5
6
7
8

func (dr *DocRoutes) Register(r chi.Router) {
r.Get("/docs", dr.list)
r.Post("/docs", dr.create)
// Wildcard routes must come after specific ones.
r.Get("/docs/*", dr.getOrHistory)
r.Post("/docs/*", dr.postDocAction)
r.Put("/docs/*", dr.update)
}

Two independent ways in. POST /api/docs takes the path from the JSON body. The wildcard routes take it from the URL, so a percent-encoded traversal survives routing and is decoded before it reaches the helper. Both funnel into the same place.

Root-cause analysis

The normaliser that normalises nothing dangerous

1
2
3
4
5

func cleanDocPath(raw string) string {
raw = strings.TrimPrefix(raw, "/")
raw = strings.TrimSuffix(raw, ".md")
return strings.Trim(raw, "/")
}

Three operations, none of which constrains anything:

• TrimPrefix(raw, "/") looks like it prevents an absolute path from replacing the base. It does not need to — Go’s filepath.Join already cleans a leading separator on the joined element. So this line changes nothing security-relevant while looking like it does.
• TrimSuffix(raw, ".md") exists so the store can re-append the extension. It is a formatting concern.
• Trim(raw, "/") strips surrounding separators. Cosmetic.

Parent-directory segments pass through completely untouched. The function is named clean, is called on every path the API accepts, and provides no containment whatsoever.

Inferred: this is the most reusable lesson in the whole knowns set. A helper named clean, sanitize, or normalize sitting on the boundary is exactly the thing that stops a reviewer from asking whether containment happens further down. The name did more damage than the missing check.

The sink joins and writes

From internal/storage/doc_store.go at v0.29.1:

1
2
3
4
5
6
7
8
9
10

func (ds *DocStore) Create(doc *models.Doc) error {
if doc.Path == "" {
return fmt.Errorf("doc path is required")
}
absPath := filepath.Join(ds.docsDir(), filepath.FromSlash(doc.Path)+".md")
if err := os.MkdirAll(filepath.Dir(absPath), 0755); err != nil {
return fmt.Errorf("create doc dir: %w", err)
}
return ds.writeFile(absPath, doc)
}

Update is the same shape. Delete is the same shape with a different verb:

1
2
3
4
5
6

// Delete removes a doc file.
func (ds *DocStore) Delete(path string) error {
path = strings.TrimSuffix(path, ".md")
absPath := filepath.Join(ds.docsDir(), filepath.FromSlash(path)+".md")
return os.Remove(absPath)
}

filepath.Join composes and cleans; it never constrains. Nothing here calls filepath.Rel, checks a prefix, or resolves symlinks. The only validation in Create is that the path is non-empty.

Two constraints, and why one of them does not hold

The forced .md suffix is real: every file operation lands on a Markdown file. That is where VC:L comes from — you cannot read /etc/shadow with this.

But os.MkdirAll(filepath.Dir(absPath), 0755) runs before the write and carries no extension constraint at all. The directory portion of the path is arbitrary. So the primitive is:

1
2

files       -> arbitrary .md, read / create / overwrite / delete
directories -> arbitrary, created on demand

Inferred: the asymmetry matters more than it first appears. A write primitive limited to one extension is still dangerous when the attacker also chooses where the parent directory goes, because it lets them construct the target tree rather than find one that already exists.

The auto-path branch

1
2
3
4
5
6
7
8
9

// Auto-generate path from title + folder when not provided.
if doc.Path == "" && doc.Title != "" {
slug := slugifyTitle(doc.Title)
if doc.Folder != "" {
doc.Path = doc.Folder + "/" + slug
} else {
doc.Path = slug
}
}

When path is absent, the handler builds one by concatenating folder with a slugified title. The title goes through slugifyTitle; folder does not. Inferred: a second caller-controlled field reaching the same join, through a branch a reviewer checking the path parameter would not think to look at.

The data flow

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

POST /api/docs            (unauthenticated by default)
PUT  /api/docs/*
GET  /api/docs/*
        |
        | path from JSON body, or percent-decoded from the URL
        v
cleanDocPath()            <-- trims cosmetics, leaves ".." intact
        |
        v
filepath.Join(docsDir, FromSlash(path) + ".md")   <-- lexical, no containment
        |
        +--> os.MkdirAll(Dir(absPath), 0755)      <-- arbitrary directory
        +--> writeFile(absPath, doc)              <-- arbitrary .md write
        +--> os.Remove(absPath)                   <-- arbitrary .md delete
        |
        v
Runs as the developer's own user

Why this got a second CVE

The unsafe join in doc_store.go was already public as CVE-2026-86439. Assigning a second identifier is correct, and the reason is worth stating plainly:

Same defect, different reachability and a different threat model. Inferred: this is textbook variant analysis — once you know a sink is unguarded, the work is enumerating every caller that reaches it, not re-finding the bug. Fixing one entry point would have left the other wide open, which is precisely why the vendor fixed the storage layer instead.

Impact

Verified impact

• A remote unauthenticated attacker could read, create, overwrite and delete arbitrary .md files accessible to the process.
• Arbitrary directories could be created via os.MkdirAll.
• Documentation belonging to other projects on the same host could be exposed.
• Files could be corrupted or destroyed.
• The CVE record explicitly describes the result as an arbitrary-write primitive that may be chained toward code execution.
• Integrity impact is High; confidentiality and availability are Low.

Deployment-dependent consequences

The following are inferred:

• disclosure of specifications, notes and architectural decisions from unrelated projects on the same machine;
• overwriting agent instruction files, project READMEs and decision records — Markdown is exactly the file type an AI assistant treats as authoritative, so the .md constraint bites far less here than it would elsewhere;
• destruction of documentation that may not be under version control;
• chaining toward execution by planting Markdown where another tool will act on it, or by combining the directory-creation primitive with the other write path in CVE-2026-86542;
• persistence that outlives the network exposure, because the payload is a file.

Inferred: for a tool whose entire purpose is feeding documents to a coding assistant, “attacker can write arbitrary Markdown” is much closer to “attacker can influence the code you ship” than the CVSS confidentiality rating suggests.

Safe validation and detection

Inventory and configuration review

1. Identify knowns installations and versions; anything before 0.30.0 is affected.
2. Establish whether the API was reachable beyond loopback and for how long — see CVE-2026-86543 for the bind-address and password checks.
3. Review the docs directory and, more importantly, the directories around it for unexpected .md files or unexplained new folders.
4. Treat the exposure scope as every path the account could write, not the project directory.

Do not validate by sending traversal payloads at a shared or production host. Version and bind-address facts answer the question without touching the vulnerable path.

Telemetry to review

• POST /api/docs, PUT /api/docs/* and GET /api/docs/* where the path is not a plain relative name;
• any path value containing parent-directory segments, in raw or percent-encoded form;
• POST /api/docs bodies carrying a folder field that is not a simple name;
• Markdown files created or modified outside the project tree;
• directories created by the knowns process outside its data directory — this is the highest-signal event, because a documentation tool has no legitimate reason to do it;
• os.Remove activity in host filesystem audit logs attributed to the process.

Remediation and hardening

Required remediation

Upgrade to knowns 0.30.0 or later. The fix introduces a single resolver and routes every document operation through it:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

func resolveDocPath(root, path string) (string, string, error) {
path = strings.TrimSuffix(path, ".md")
if strings.TrimSpace(path) == "" {
return "", "", fmt.Errorf("doc path is required")
}
absPath, err := safepath.Resolve(root, filepath.ToSlash(path)+".md")
if err != nil {
return "", "", fmt.Errorf("invalid doc path %q: %w", path, err)
}
rel, err := filepath.Rel(root, absPath)
if err != nil {
return "", "", fmt.Errorf("resolve doc path: %w", err)
}
canonical := strings.TrimSuffix(filepath.ToSlash(rel), ".md")
return canonical, absPath, nil
}

Create, Update, Delete and Get all call it. safepath.Resolve rejects rather than sanitises — absolute paths, parent traversal, NUL bytes, Windows device and volume prefixes, and symlink escapes all fail closed. That package is covered in more detail in the CVE-2026-86538 writeup.

The detail worth copying is what the patch did not touch. cleanDocPath is byte-for-byte identical in 0.30.0:

1
2
3
4
5

func cleanDocPath(raw string) string {
raw = strings.TrimPrefix(raw, "/")
raw = strings.TrimSuffix(raw, ".md")
return strings.Trim(raw, "/")
}

The maintainers deliberately left the route-layer normaliser alone and put containment at the sink. That is the right call. Hardening cleanDocPath would have fixed the reported routes and left every other caller of DocStore — including the MCP tools from CVE-2026-86439 — still exposed. Guarding the function that touches the filesystem fixes all callers at once, including ones not yet written.

resolveDocPath also returns a canonical path derived from filepath.Rel, so the value stored back on the document is the one that was actually validated. That closes the gap where a record could carry a path different from the file it was written to.

Defense in depth

• Bind to loopback and set a password (both are default in 0.30.0).
• Treat any endpoint that accepts a path as a privileged operation, even a read-only-looking one.
• Run developer context servers with the narrowest practical filesystem view.
• Enable integrity monitoring on agent instruction files and project documentation, not just on code.
• Audit for unexpected writes rather than assuming absence of an alert means absence of a write.

Timeline

Lessons for builders

A helper named clean is a liability if it does not contain

cleanDocPath trimmed three cosmetic things and let traversal through. The name told every subsequent reader that the path had been handled. If a function only formats, call it formatDocPath — and if it is supposed to make the value safe, make it return an error.

Fix the sink, not the route

The patch left the route-layer normaliser untouched and hardened the storage layer. That single decision fixed both this CVE and the MCP-facing variant, and it protects call sites nobody has written yet. Guarding entry points is a maintenance treadmill; guarding the dangerous operation is durable.

Enumerate callers, not bugs

The same unguarded join produced two CVEs with different reachability and different privilege requirements. When you find an unsafe sink, the remaining work is mechanical: list every path that reaches it. Grep for the idiom, not for the reported endpoint.

An extension filter is not a boundary

Restricting writes to .md sounds like containment until you notice os.MkdirAll on the same line has no such restriction — and that for an AI documentation tool, Markdown is the sensitive file type.

Check every field that reaches the path

path was the obvious parameter. folder reached the same join through the auto-generate branch, unslugified. Trace each input to its sink independently, including the ones that only appear on a fallback path.

Related advisories in this set

Eight CVEs were assigned to knowns before 0.30.0 and fixed in the same release:

• CVE-2026-86439 — the MCP-facing variant of this same storage-layer defect
• CVE-2026-86543 — unauthenticated management API exposure
• CVE-2026-86538 — unauthenticated arbitrary file read via templateFile
• CVE-2026-86542 — unauthenticated arbitrary file write via import name
• CVE-2026-86541 — path traversal in the code.replace MCP action
• CVE-2026-86544 — authorisation bypass via misclassified code actions
• CVE-2026-86540 — arbitrary code execution via the LSP binary override

References

• CVE.org record: CVE-2026-86775
• NIST National Vulnerability Database: CVE-2026-86775
• GitHub Security Advisory: GHSA-3h35-4jq7-hv45
• VulnCheck advisory
• cleanDocPath at v0.29.1
• DocStore.Create at v0.29.1
• resolveDocPath at v0.30.0
• knowns v0.30.0 release notes

Reported by uziii2208 and hoanggxyuuki. Recheck the primary sources above during remediation; public vulnerability records are frequently revised after publication.

Scope and safety. This article analyses a fixed, publicly disclosed vulnerability using the vendor’s own published source references. It describes the defective control flow and the remediation. It intentionally omits ready-to-run exploit requests, traversal strings, and weaponised proof-of-concept material.

Executive summary

CVE-2026-86543 is a critical missing-authentication vulnerability in knowns, a Go-based context server that gives AI coding assistants structured access to a project’s tasks, docs, specs, and decisions. In versions before 0.30.0, three independent defaults compounded into a single critical outcome:

1. the HTTP server bound every interface rather than loopback;
2. the authentication middleware degraded to a pass-through whenever no password was configured — the state of every fresh installation; and
3. POST /api/tunnel/start performed no authorisation check of its own, so any client that reached the server could ask it to publish itself on the public internet.

The weakness is classified as CWE-306: Missing Authentication for Critical Function. The vendor scores it CVSS 4.0 9.3 Critical (CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N) and CVSS 3.1 9.8 Critical (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H).

This CVE is the exposure multiplier for the rest of the knowns advisory set. On its own it grants an unauthenticated caller the full management surface. Combined with CVE-2026-86538 (arbitrary file read) and CVE-2026-86542 (arbitrary file write), it turns two path-traversal bugs into remotely reachable, credential-free primitives.

The issue is fixed in knowns 0.30.0 by commit 878a02cb7cc1.

Evidence labels used below:

• Verified means stated by the CVE record, the GitHub Security Advisory, or the project’s own source and release material.
• Inferred means a deployment consequence derived from those facts and clearly marked as such.

Key facts

Why this class matters for AI developer tooling

A context server for AI assistants is an unusually attractive target because of what it is designed to hold. It is deliberately given the project’s specifications, architectural decisions, task history, notes, and — through its MCP surface — read and write access to the source tree itself. It is a single process that concentrates exactly the material an attacker would otherwise have to assemble from many places.

Local developer tools have historically been allowed a relaxed security posture on the theory that “it only listens on my machine”. That assumption has been eroding for years, and it fails outright in the environments where AI coding tooling actually runs today:

• laptops on coffee-shop, coworking, conference, and hotel networks;
• shared office and campus VLANs with no client isolation;
• cloud development environments, dev containers, and Codespaces-style remote workspaces;
• CI runners and ephemeral build agents that keep a tool alive between steps;
• WSL and container bridges where “localhost” is a routable address to other tenants.

Inferred: on any of those networks, a service that binds 0.0.0.0 with authentication disabled is not a local tool. It is an unauthenticated network service that happens to run next to a developer’s source code.

Attack surface and trust boundary

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

Any client on a reachable network
        |
        | HTTP request, no credentials
        v
chi router  --->  AuthManager.Middleware
        |                 |
        |                 +-- HasPassword() == false  -->  pass through, no check
        v
Management API surface
  - /api/templates/*      (see CVE-2026-86538)
  - /api/imports/*        (see CVE-2026-86542)
  - /api/tunnel/start     <-- provisions a public ingress
  - project, docs, memory, task, and code routes
        |
        v
Project files, notes, specs, and the developer's account
        |
        v
cloudflared tunnel  ---->  the public internet

Two trust boundaries fail here, and the second is the interesting one.

The first is the ordinary one: unauthenticated network client → privileged management API. That is a serious but familiar bug.

The second is reachable client → control of the service’s own network exposure. POST /api/tunnel/start is not a data endpoint. It is a topology endpoint. It takes a service whose blast radius was bounded by the local network and re-publishes it at a globally resolvable address. An attacker who reaches the service once, briefly, on a shared network can convert transient local access into durable internet exposure — and then keep using it after leaving the network.

Root-cause analysis

Defect 1 — the authentication middleware opts itself out

From internal/server/auth.go at v0.29.1:

1
2
3
4
5
6
7
8
9

func (am *AuthManager) Middleware(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
if am == nil || !am.HasPassword() {
next.ServeHTTP(w, r)
return
}
...
})
}

The guard is real, well written, and completely inert until somebody sets a password. Fresh installations have no password. The security control is therefore opt-in, and the default state of every new install is “off”.

This is a fail-open design. It is worth being precise about why it is tempting: without it, a first-run user is locked out of their own tool before they can configure it. The mistake is not the goal, it is the scope — the escape hatch was applied to the whole API surface and to every network interface, rather than being narrowed to loopback and to first-run setup.

Defect 2 — the listener binds every interface

From internal/cli/browser.go at v0.29.1:

1

listener, err := net.Listen("tcp", fmt.Sprintf("0.0.0.0:%d", port))

And in internal/server/server.go:

1
2

addr := ":" + strconv.Itoa(s.port)
listener, err := net.Listen("tcp", addr)

Both bind the wildcard address. The CLI then went a step further and printed the LAN address on startup:

1
2
3

if ip := getLocalIP(); ip != "" {
fmt.Printf("  %s  %s\n", StyleInfo.Render("→"), StyleInfo.Render(fmt.Sprintf("http://%s:%d", ip, port)))
}

Inferred: a convenience feature that advertises the reachable LAN URL also documents the exposure to anyone reading over a shoulder, in a screen share, or in a pasted terminal log.

Defect 3 — the tunnel endpoint has no authorisation of its own

From internal/server/routes/tunnel.go at v0.29.1:

1
2
3
4
5
6
7
8
9
10
11
12
13

func SetupTunnelRoutes(r chi.Router, tunnelMgr TunnelManager, broadcaster Broadcaster) {
r.Post("/start", func(w http.ResponseWriter, r *http.Request) {
url, err := tunnelMgr.Start()
if err != nil {
handleTunnelError(w, err)
return
}
status := tunnelMgr.Status()
broadcastTunnelStatus(broadcaster, status)
respondJSON(w, http.StatusOK, map[string]string{"url": url, "status": "running"})
})
...
}

The handler delegates entirely to the shared middleware for protection. Because that middleware is inert on a fresh install, the endpoint that changes the service’s exposure model inherits exactly zero checks. The handler even returns the resulting public URL in its response, so the caller does not have to guess where the service now lives.

The three defects compose

Individually, each is arguable. A local-only tool binding 0.0.0.0 is sloppy. Optional authentication is a product decision. A tunnel endpoint without its own check is a layering choice. Together they form a complete, credential-free chain from “same network” to “internet-published management API with full project access”.

Inferred: this is the ordinary shape of a critical finding in developer tooling. It is rarely one dramatic bug. It is three reasonable-looking defaults whose intersection nobody modelled.

Impact

Verified impact

• The management API was reachable without credentials from any host that could route to the listener.
• No privileges and no user interaction were required (PR:N/UI:N).
• Confidentiality, integrity, and availability impacts on the vulnerable system are all rated High.
• An unauthenticated caller could provision a public tunnel and republish the API at a publicly accessible address.

Deployment-dependent consequences

The following are inferred:

• disclosure of project specifications, architectural decisions, internal notes, and memory entries held by the server;
• read and write access to the project source tree through the exposed code and docs routes;
• persistence of exposure beyond the attacker’s presence on the local network, once a tunnel is running;
• chaining with CVE-2026-86538 to read files outside the project — credentials, SSH keys, cloud configuration — with no authentication;
• chaining with CVE-2026-86542 to write attacker-controlled files outside the imports directory, which in turn can plant a malicious .knowns/config.json and reach code execution through CVE-2026-86540;
• poisoning of the docs, specs, and memory that an AI assistant reads, which is a durable influence channel over code the developer will later accept.

That last point deserves emphasis. Compromising a context server is not only a data-theft event. The whole purpose of the product is that an AI assistant treats its contents as authoritative. Silent modification of a spec or an architectural decision is an attack on every future session.

Safe validation and detection

You can establish exposure without sending a single malicious request.

Inventory and configuration review

1. Locate every installed knowns instance — npm global installs, project dev-dependencies, dev containers, and CI images.

2. Record the version. Anything earlier than 0.30.0 is affected.

3. On each host, check what the process is actually bound to:

   1 2 3

   # Any bind address that is not loopback is the exposed condition. ss -ltnp | grep -i knowns lsof -nP -iTCP -sTCP:LISTEN | grep -i knowns

4. Check whether a password is configured. GET /api/auth/status is a legitimate, non-destructive endpoint the product exposes for exactly this purpose.

5. Check whether a tunnel is or has been running, and treat any unexplained tunnel as an incident rather than a misconfiguration.

Telemetry to review

• inbound connections to the knowns port from any address other than loopback;
• POST /api/tunnel/start in access logs, especially from an unexpected source or at a time when no developer was present;
• cloudflared (or equivalent) child processes spawned by the knowns process;
• outbound connections consistent with tunnel establishment;
• unexplained changes to files under .knowns/, particularly config.json, docs, and memory entries;
• requests to /api/templates/preview and /api/imports with unusual parameters.

Inferred: a knowns process with a live tunnel and no password is best treated as a compromise until proven otherwise, because the exposure window is unbounded and the API grants project read/write.

Remediation and hardening

Required remediation

Upgrade to knowns 0.30.0 or later. The fix in 878a02cb7cc1 closes all three defects rather than patching one of them:

The listener is loopback by default.

1

addr := net.JoinHostPort("127.0.0.1", strconv.Itoa(s.port))

1

listener, err := net.Listen("tcp", fmt.Sprintf("127.0.0.1:%d", port))

A non-loopback listener is refused unless a password exists. This is the important structural change — the invariant is enforced at the point of serving, not at each call site:

1
2
3
4
5
6
7
8
9

func (s *Server) serve(listener net.Listener) error {
if !listenerIsLoopback(listener) && !s.auth.HasPassword() {
return fmt.Errorf("non-loopback listener requires password protection")
}
if s.opts.Tunnel && !s.auth.HasPassword() {
return fmt.Errorf("tunnel requires password protection")
}
...
}

The tunnel endpoint gained its own check rather than trusting shared middleware:

1
2
3
4
5
6
7

r.Post("/start", func(w http.ResponseWriter, r *http.Request) {
if len(protectionReady) > 0 && protectionReady[0] != nil && !protectionReady[0]() {
respondError(w, http.StatusForbidden, "password protection is required before starting a public tunnel")
return
}
...
})

Password removal is blocked while a tunnel is live, closing the obvious downgrade path of “authenticate, remove password, keep the tunnel”:

1
2
3
4

if ar.canRemovePassword != nil && !ar.canRemovePassword() {
respondError(w, http.StatusConflict, "stop the public tunnel before removing password protection")
return
}

The CLI also now refuses --tunnel without --password, drops the LAN-URL advertisement, and the router adds a trustedOriginMiddleware so cross-site requests are rejected before CORS can answer a preflight.

Defense in depth

• Set a password on every instance, even after upgrading, and especially on shared or remote development hosts.
• Do not expose developer context servers to any network you do not control; prefer SSH port forwarding over binding a routable interface.
• Treat “start a public tunnel” as an administrative action requiring explicit, interactive, local confirmation — not an API call.
• Apply host firewall rules to the knowns port rather than relying on the application’s bind address alone.
• In dev containers and cloud workspaces, verify what the platform publishes; some automatically forward listening ports.
• Rotate any credential that was reachable from the project directory if you cannot rule out exposure.
• Review .knowns/ contents for unexpected modification, since poisoned context outlives the network exposure that created it.

Upgrading is the fix. Firewalling is a compensating control — useful, but it does not help against a peer on the same VLAN, and it does nothing once a tunnel has been established from the inside.

Timeline

Consult the live CVE, GHSA, and VulnCheck records during remediation; vulnerability entries are routinely enriched and revised after publication.

Lessons for builders

“Local tool” is a deployment claim, not a property

If a process calls net.Listen on a wildcard address, it is a network service. The correct default is 127.0.0.1, and any widening should be an explicit, argued decision that carries an authentication requirement with it.

Fail-open authentication is not authentication

A middleware that returns early when unconfigured provides confidence without protection. If setup genuinely needs an unauthenticated window, scope it to loopback and to the specific setup endpoints — never to the entire API on every interface. The 0.30.0 fix is instructive precisely because it inverts the default: the server now refuses to serve in the unsafe combination rather than serving with the check disabled.

Endpoints that change exposure deserve their own gate

Middleware is a layer, not a guarantee. Any handler that alters the system’s own reachability — tunnels, port bindings, listener configuration, remote-access toggles — should re-check authorisation locally. That handler’s failure mode is categorically worse than a data endpoint’s, so it should not share a single point of failure with them.

Model the intersection of defaults, not each default alone

Wildcard bind, optional auth, and an unauthenticated topology endpoint each survived review. The combination is a 9.3. Threat modelling that examines settings independently will keep missing this class. Ask instead: what is the worst reachable state a user can arrive at without making a single wrong decision?

Context servers are high-value targets

A tool that holds a project’s specifications and feeds them to an AI assistant is both a data store and an influence channel. Design it with the posture of a secrets store, not the posture of a linter.

Related advisories in this set

Eight CVEs were assigned to knowns before 0.30.0 and fixed in the same release:

• CVE-2026-86538 — unauthenticated arbitrary file read via templateFile
• CVE-2026-86542 — unauthenticated arbitrary file write via import name
• CVE-2026-86439 — path traversal through MCP doc and memory tools
• CVE-2026-86541 — path traversal in the code.replace MCP action
• CVE-2026-86544 — authorisation bypass via misclassified code actions
• CVE-2026-86540 — arbitrary code execution via the LSP binary override
• CVE-2026-86775 — unauthenticated path traversal through the HTTP Document API

References

• CVE.org record: CVE-2026-86543
• NIST National Vulnerability Database: CVE-2026-86543
• GitHub Security Advisory: GHSA-fc85-99vc-9c75
• VulnCheck advisory
• AuthManager.Middleware at v0.29.1
• Browser listener binds 0.0.0.0 at v0.29.1
• POST /api/tunnel/start at v0.29.1
• Fix commit 878a02cb7cc1
• knowns v0.30.0 release notes

Reported by Tong Hoang Gia and Nguyen Huy Hoang. Public vulnerability records change as maintainers and databases add references or revise metadata; recheck the primary sources above during remediation and incident response.

Scope and safety. This article analyses a fixed, publicly disclosed vulnerability using the vendor’s own published source references. It describes the defective authorisation logic and the remediation. It does not include a runnable proof of concept or injection prompts.

Executive summary

CVE-2026-86544 is an incorrect-authorisation vulnerability in knowns before 0.30.0. The MCP permission layer classified each tool action as read, write, generate, delete, or admin, and a guard middleware enforced the session’s policy against that classification. The mechanism was sound. The data it consulted was wrong.

The action registry listed only the four read code actions. Every mutating code action — code.replace, code.rename, code.insert, code.replace_body, code.delete — was missing, and the lookup fell back to a tool-level default that classified the entire code tool as CapRead. A session deliberately restricted to reading therefore passed the capability gate for operations that write and delete files.

The weakness is CWE-863: Incorrect Authorization. The vendor scores it CVSS 4.0 7.2 High (CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N) and CVSS 3.1 8.1 High (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H).

The escalation is what lifts this above a simple gate bypass. Because code.replace can write files, and the permission policy is itself configuration on disk, an attacker in a read-restricted session could rewrite the policy — and then hold genuine elevated permissions on every subsequent call. A bypass becomes a grant.

Fixed in knowns 0.30.0 by commit a2c98fc5c313, the same commit that fixed CVE-2026-86541.

Evidence labels used below:

• Verified means stated by the CVE record, the GitHub Security Advisory, or the project’s published source and release material.
• Inferred means a consequence derived from those facts and clearly marked as such.

Key facts

Root-cause analysis

The registry knew about reads and not writes

From internal/permissions/registry.go at v0.29.1:

1
2
3
4
5

// code
"code.search":  {Capability: CapRead, Target: TargetCode, Risk: RiskLow},
"code.symbols": {Capability: CapRead, Target: TargetCode, Risk: RiskLow},
"code.deps":    {Capability: CapRead, Target: TargetCode, Risk: RiskLow},
"code.graph":   {Capability: CapRead, Target: TargetCode, Risk: RiskLow},

Four entries. The code tool shipped considerably more actions than four — the handler file implements find, definition, references, implementations, diagnostics, rename, replace, replace_body, insert, and delete. None of the mutating ones appear.

The fallbacks are fail-open, twice

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

// toolFallback provides default classification at the tool level when no
// specific tool.action entry exists.
var toolFallback = map[string]ActionMeta{
"tasks":     {Capability: CapRead, Target: TargetTask, Risk: RiskLow},
"docs":      {Capability: CapRead, Target: TargetDoc, Risk: RiskLow},
"time":      {Capability: CapRead, Target: TargetTime, Risk: RiskLow},
"search":    {Capability: CapRead, Target: TargetSearch, Risk: RiskLow},
"code":      {Capability: CapRead, Target: TargetCode, Risk: RiskLow},
"templates": {Capability: CapRead, Target: TargetTemplate, Risk: RiskLow},
"validate":  {Capability: CapRead, Target: TargetRuntime, Risk: RiskLow},
"memory":    {Capability: CapRead, Target: TargetMemory, Risk: RiskLow},
"project":   {Capability: CapAdmin, Target: TargetRuntime, Risk: RiskMedium},
}

// defaultMeta is returned when no classification is found.
var defaultMeta = ActionMeta{Capability: CapRead, Target: TargetRuntime, Risk: RiskLow}

// ClassifyAction returns the ActionMeta for a tool+action combination.
// It checks the full "tool.action" key first, then falls back to tool-level
// defaults, and finally returns a safe read default.
func ClassifyAction(tool, action string) ActionMeta {
key := tool + "." + action
if meta, ok := ActionRegistry[key]; ok {
return meta
}
if meta, ok := toolFallback[tool]; ok {
return meta
}
return defaultMeta
}

The doc comment contains the whole bug in three words: “a safe read default”.

CapRead is the safe default for the caller. It is the dangerous default for the system. When an unknown action is classified as read, the effect is not that the action is treated cautiously — it is that the action is permitted under the most permissive common policy, while the guard reports success. The system fails open and says nothing.

Compare the one entry that got it right: "project": {Capability: CapAdmin, ...}. That fallback assumes the most restrictive capability, so an unrecognised project action is denied rather than allowed. The author clearly understood the principle; it simply was not applied to the tool whose action set had grown the most.

The guard was working correctly

From internal/permissions/guard.go at v0.29.1:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

// Classify the action.
meta := classifyToolAction(toolName, action, args)

// Load effective policy.
cfg := configLoader()
policy := EffectivePolicy(cfg)

// Check dryRun from arguments.
dryRun := isDryRun(args) || lifecyclePreview(action, args)

// Pass 1: capability gate (no IO).
confirmedDelete := meta.Capability == CapDelete && explicitDeleteConfirmation(args)
if denial := CheckCapability(policy, meta, dryRun || confirmedDelete); denial != nil {
return denialResult(denial), nil
}

// Allowed — proceed to handler.
return next(ctx, req)

This is well-built enforcement: classify, load policy, evaluate, deny early without IO, and a separate confirmation requirement for deletes. Every line of it did its job. It received CapRead for a call that was about to run os.WriteFile, and correctly allowed a read.

Inferred: this is the characteristic failure mode of policy-driven authorisation, and it is worth naming. The enforcement code is easy to review — it is small, central, and obviously security-relevant. The classification data is a map literal that reads like configuration, gets extended by whoever adds a feature, and attracts no security review at all. The vulnerability lives in the data, and the data is the part nobody looks at.

Registry drift is the mechanism

Nobody wrote "code.replace": {Capability: CapRead}. That would have been caught. The bug arrived by omission: mutating actions were added to the handler and never added to the registry, and the fallback quietly covered the gap. Every new action shipped pre-authorised for read-restricted sessions, and there was no signal — no error, no log line, no test failure — that this had happened.

The escalation

Once a read-restricted session can invoke code.replace, it can write files. The permission policy is loaded from configuration on disk by configLoader(). Rewriting that configuration changes EffectivePolicy(cfg) for subsequent calls.

Inferred: the attacker’s position after that step is qualitatively different. They no longer need the classification bug — they hold a legitimate grant. Restoring the registry alone would not evict them; the modified policy file would have to be found and reverted too. That is why the fix hardens both the classification and the ability to write policy paths.

Combined with CVE-2026-86541, which let code.replace write outside the project root entirely, the pair yields: read-restricted MCP session → arbitrary file write on the host → durable elevated permissions.

Impact

Verified impact

• Sessions restricted to read-only operations could invoke mutating code actions.
• Attackers could modify permission configuration and escalate privileges on subsequent calls.
• Integrity and availability impacts are High; confidentiality is not directly affected (VC:N).
• Low privileges are required (PR:L); no user interaction is (UI:N).

Deployment-dependent consequences

The following are inferred:

• any deployment relying on read-only MCP sessions as a safety boundary — sandboxed agents, review-only assistants, shared or multi-tenant setups, CI-attached agents — had no such boundary in practice;
• deletion of source files through code.delete, which was likewise classified as read;
• a durable policy grant that survives fixing the classification bug, if the configuration was rewritten;
• silent failure: because the guard returned success, there is no denial record of the bypass in logs — the calls look like ordinary permitted operations;
• amplification of prompt injection, since the read-only posture that made auto-approving code tools feel acceptable was not real.

Inferred: the reliance point matters more than the raw impact. A permission system that is trusted is more dangerous when wrong than one that is absent, because teams make architectural decisions on the strength of it — “the agent is read-only, so we can let it run unattended” is a reasonable decision built on a false premise.

Safe validation and detection

Inventory and configuration review

1. Identify knowns installations and versions; anything before 0.30.0 is affected.
2. Identify every session or integration configured with a restricted policy, and treat that restriction as not having been enforced for code actions.
3. Inspect the current permission configuration for entries nobody set, and compare it against version control or a known-good copy.
4. In your own MCP servers, diff the set of implemented actions against the set of classified actions. Any action present in the first and absent from the second is the same bug.

A useful, non-invasive audit for any registry of this shape:

1
2

# Actions the handlers implement, versus actions the registry classifies.
# Any name in the first list and not the second inherits the fallback.

Inferred: this comparison is worth automating as a test in any project that classifies actions in a lookup table. It is the check that would have caught this at authoring time.

Telemetry to review

• MCP invocations of code.replace, code.rename, code.insert, code.replace_body, or code.delete from sessions that were supposed to be read-only;
• file modifications during sessions whose policy should have forbidden them;
• changes to the knowns permission configuration, at any time;
• absence of denial events in a session that should have produced them — silence is the signature here, not noise;
• source files deleted or altered without a corresponding commit or user request.

Remediation and hardening

Required remediation

Upgrade to knowns 0.30.0 or later. The fix does three things, and the third is the durable one.

Every code action is now classified explicitly, with mutations marked CapWrite or CapDelete and RiskHigh:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

// code
"code.search":          {Capability: CapRead, Target: TargetCode, Risk: RiskLow},
"code.symbols":         {Capability: CapRead, Target: TargetCode, Risk: RiskLow},
"code.deps":            {Capability: CapRead, Target: TargetCode, Risk: RiskLow},
"code.graph":           {Capability: CapRead, Target: TargetCode, Risk: RiskLow},
"code.find":            {Capability: CapRead, Target: TargetCode, Risk: RiskLow},
"code.definition":      {Capability: CapRead, Target: TargetCode, Risk: RiskLow},
"code.references":      {Capability: CapRead, Target: TargetCode, Risk: RiskLow},
"code.implementations": {Capability: CapRead, Target: TargetCode, Risk: RiskLow},
"code.diagnostics":     {Capability: CapRead, Target: TargetCode, Risk: RiskLow},
"code.rename":          {Capability: CapWrite, Target: TargetCode, Risk: RiskHigh},
"code.replace":         {Capability: CapWrite, Target: TargetCode, Risk: RiskHigh},
"code.replace_body":    {Capability: CapWrite, Target: TargetCode, Risk: RiskHigh},
"code.insert":          {Capability: CapWrite, Target: TargetCode, Risk: RiskHigh},
"code.delete":          {Capability: CapDelete, Target: TargetCode, Risk: RiskHigh},

The tool-level fallback is inverted to fail closed, and the maintainers left the reasoning in the code:

1
2
3

// Code has explicit read classifications above. Keep the fallback write
// so a newly added mutation cannot silently inherit read permission.
"code":      {Capability: CapWrite, Target: TargetCode, Risk: RiskHigh},

This is the part to take away. The registry will drift again — that is what registries do. The fallback now makes drift fail in the safe direction: a future action added to the handler without a registry entry is over-restricted rather than under-restricted. Someone will file a bug about the restriction, which is a much better outcome than nobody filing anything.

Mutation of managed policy paths is blocked at the handler, via ensureCodeMutationPath, so even a correctly authorised write cannot be aimed at the permission configuration itself. Combined with the path containment from CVE-2026-86541, the escalation route is closed independently of the classification fix — defence in depth applied to the specific chain rather than in the abstract.

The commit also adds confirmed and reason arguments for action=delete, so destructive operations need explicit acknowledgement.

Defense in depth

• Do not treat an application-level “read-only session” as an isolation boundary. Enforce read-only at the OS level too — a read-only mount, a dedicated user, or a container.
• Add a test that asserts every registered handler action has an explicit classification. This class of bug is mechanically detectable.
• Default unknown actions to the most restrictive capability, everywhere, without exception.
• Make classification part of the definition of an action rather than a parallel table, so the two cannot diverge.
• Log allow decisions for high-risk capabilities, not only denials — otherwise a fail-open bug produces no evidence at all.
• Never let a mutating operation write the policy that authorises it.

Timeline

Lessons for builders

The safe default is the restrictive one

“A safe read default” is safe for the request and unsafe for the system. When classification fails, deny. An over-restricted new feature produces a bug report; an under-restricted one produces a CVE.

Authorisation data deserves the same review as authorisation code

The guard middleware was reviewed and correct. The map literal that fed it was not, because it looks like configuration. In any policy-driven system, the lookup table is security code. Review it as such, and put it in the same file or the same review checklist as the enforcement it drives.

Derive classification, do not maintain it in parallel

Two lists that must stay in sync will not. Where the language allows it, attach the capability to the action’s definition — a struct field, a builder argument, an interface method — so adding an action forces a decision about its capability at the point of authoring.

Test the invariant, not the examples

A test asserting code.replace requires write permission is useful. A test asserting every registered action has an explicit classification is the one that catches the next occurrence. Prefer completeness properties over example cases when guarding against omission.

A permission system you trust must be a permission system you verify

Teams build architecture on top of “the agent is read-only”. If that claim rests on a lookup table nobody audits, the architecture rests on it too. Periodically prove the boundary rather than assuming it.

Related advisories in this set

• CVE-2026-86541 — the containment half of this pair, fixed in the same commit
• CVE-2026-86439 — path traversal through MCP doc and memory tools
• CVE-2026-86543 — unauthenticated management API exposure
• CVE-2026-86538 — unauthenticated arbitrary file read via templateFile
• CVE-2026-86542 — unauthenticated arbitrary file write via import name
• CVE-2026-86540 — arbitrary code execution via the LSP binary override
• CVE-2026-86775 — unauthenticated path traversal through the HTTP Document API

References

• CVE.org record: CVE-2026-86544
• NIST National Vulnerability Database: CVE-2026-86544
• GitHub Security Advisory: GHSA-w323-3wpx-f7g5
• VulnCheck advisory
• ActionRegistry and ClassifyAction at v0.29.1
• Guard middleware at v0.29.1
• Fix commit a2c98fc5c313
• knowns v0.30.0 release notes

Reported by Tong Hoang Gia and Nguyen Huy Hoang. Recheck the primary sources above during remediation; public vulnerability records are frequently revised after publication.

Scope and safety. This article analyses a fixed, publicly disclosed vulnerability using the vendor’s own published source references. It describes the defective data flow and the remediation. It does not include working traversal strings, target path lists, or a runnable proof of concept.

Executive summary

CVE-2026-86542 is a path-traversal vulnerability in the import routes of knowns before 0.30.0. The import feature clones or registers an external source and stores its .knowns/docs and .knowns/templates content under .knowns/imports/{name}/. That {name} came straight from the request body — or was derived from the source URL — and was never validated as a single path segment before being joined onto the imports directory.

The result is an arbitrary file write: the destination escapes the imports directory, and for a git source the content is whatever the attacker put in the repository they asked knowns to clone. Attacker-chosen path, attacker-chosen content.

The weakness is CWE-22: Improper Limitation of a Pathname to a Restricted Directory. The vendor scores it CVSS 4.0 8.8 High (CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N) and CVSS 3.1 9.1 Critical (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H) — the highest CVSS 3.1 score in this advisory set apart from the exposure issue itself.

PR:N again reflects CVE-2026-86543: the management API was unauthenticated on all interfaces by default.

Fixed in knowns 0.30.0 by commit d3989829fb50.

Evidence labels used below:

• Verified means stated by the CVE record, the GitHub Security Advisory, or the project’s published source and release material.
• Inferred means a deployment consequence derived from those facts and clearly marked as such.

Key facts

Why the write side is categorically worse

An arbitrary read is a confidentiality problem with a bounded, if severe, outcome: the attacker learns things. An arbitrary write on a developer workstation is an execution problem, because a developer’s home directory is full of files that something will later read and act on.

Inferred: the general shape of the escalation is that a write primitive plus any auto-executed configuration file equals code execution at the next trigger. Shell startup files, editor and tool configuration, git hooks, and per-project settings all get read by something that will do what they say. The attacker does not need memory corruption or a shell — they need patience and one file.

That is why this CVE matters more than its CVSS 4.0 score suggests. It is the pivot in the chain:

1
2
3
4
5
6
7

CVE-2026-86543           CVE-2026-86542            CVE-2026-86540
no auth, all interfaces  arbitrary file write      config-driven binary execution
        |                        |                          |
        +------------------------+--------------------------+
                                 v
        unauthenticated network caller  ->  persistent code execution
                                            as the developer's user

Writing a crafted .knowns/config.json into a project directory is enough to arm CVE-2026-86540, which executes an unvalidated binary name from that file when the project is opened.

Root-cause analysis

The name is taken and used, never checked

From internal/server/routes/imports.go at v0.29.1:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

// add registers a new import source.
//
// POST /api/imports
func (ir *ImportRoutes) add(w http.ResponseWriter, r *http.Request) {
var req addImportRequest
if err := decodeJSON(r, &req); err != nil {
respondError(w, http.StatusBadRequest, "invalid request body: "+err.Error())
return
}
if req.Source == "" {
respondError(w, http.StatusBadRequest, "source is required")
return
}

name := req.Name
if name == "" {
name = nameFromSource(req.Source)
}

// Git URL: clone and copy .knowns/docs + templates.
if isGitURL(req.Source) {
changes, warnings, _, _, err := ir.gitCloneImport(req.Source, name, req.Ref, "", req.DryRun)
...
}

// Non-git source: create empty import directory.
destDir := filepath.Join(ir.importsDir(), name)
if err := os.MkdirAll(destDir, 0755); err != nil {
respondError(w, http.StatusInternalServerError, "create import dir: "+err.Error())
return
}
...
}

req.Source is checked for emptiness. req.Name is checked for emptiness only as a trigger for the fallback. Neither branch establishes that name is a single path segment before it reaches filepath.Join.

The non-git branch already gives directory creation at an arbitrary location. The git branch gives the full primitive.

The clone path multiplies the problem

From the same file, in gitCloneImport:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

// Collect files from docs/ and templates/ subdirectories.
var changes []importChange
var warnings []string
destBase := filepath.Join(ir.importsDir(), name)

for _, sub := range []string{"docs", "templates"} {
srcDir := filepath.Join(knownsDir, sub)
if _, err := os.Stat(srcDir); os.IsNotExist(err) {
continue
}

err := filepath.Walk(srcDir, func(path string, info os.FileInfo, err error) error {
if err != nil || info.IsDir() {
return nil
}
relPath, _ := filepath.Rel(knownsDir, path)
relPath = filepath.ToSlash(relPath)
if sub == "docs" {
subRel := strings.TrimPrefix(relPath, "docs/")
relPath = "docs/" + name + "/" + subRel
}
destPath := filepath.Join(destBase, relPath)
...
if !dryRun && action != "skip" {
if err := os.MkdirAll(filepath.Dir(destPath), 0755); err != nil {
return err
}
if err := copyFile(path, destPath); err != nil {
return err
}
}
...
})
}

Three properties of this loop are worth drawing out:

1. destBase inherits the unvalidated name. Every destination in the walk is relative to a base that may already sit outside the imports directory.
2. The name is interpolated a second time in relPath = "docs/" + name + "/" + subRel, so it influences the path twice — once through the base and once through the relative portion.
3. os.MkdirAll creates whatever directories the destination needs. The write is not limited to overwriting files that already exist; it can construct the target directory tree first.

Combined with a source repository the attacker controls, the loop copies attacker-authored file content to attacker-chosen destinations. The only structural constraints are that the content lives under .knowns/docs or .knowns/templates in the source repo, and that the target must be writable by the knowns process.

The dryRun flag is not a security control

dryRun suppresses the copy, and is presumably why the feature felt safe to expose — a caller can preview changes. But it is a caller-supplied boolean. It reduces the impact of an accidental import; it does nothing about a deliberate one.

The other handlers shared the flaw

The fix commit adds validation to get, remove, and gitCloneImport as well as add. Inferred: the DELETE /api/imports/{name} route joining an unvalidated URL parameter onto the imports directory before calling os.RemoveAll is the availability half of the VA:H rating — a traversal there removes a directory tree outside the import root.

Impact

Verified impact

• Unauthenticated attackers could write files outside the imports directory.
• Arbitrary files writable by the server process could be overwritten.
• Integrity and availability impacts are rated High; confidentiality is not directly affected (VC:N).

Deployment-dependent consequences

The following are inferred:

• overwriting shell startup files, tool configuration, or git hooks to obtain code execution the next time the developer opens a terminal or runs a repository operation;
• planting a malicious .knowns/config.json to chain into CVE-2026-86540;
• corrupting or replacing source files, build scripts, and CI configuration in any repository the process can write to — a local supply-chain attack that reaches production through the developer’s own commits;
• poisoning the docs, specs, and memory entries that an AI assistant treats as authoritative, which then influences code the developer reviews and accepts;
• destructive impact through the delete path, including loss of project data;
• persistence that survives restarting knowns, because the payload lives in files outside the tool.

Inferred: the AI-specific consequence deserves separate weight. A poisoned architectural decision record is not a defaced file; it is an instruction that a coding assistant will follow, in a document a human is unlikely to re-read. That is a quiet, durable influence channel over future code.

Safe validation and detection

Inventory and configuration review

1. Identify knowns installations and versions; anything before 0.30.0 is affected.
2. Establish whether the API was reachable beyond loopback and for how long — see CVE-2026-86543.
3. List the configured imports and compare them to what the team actually intended to import. An import whose name is not a plain identifier is a finding.
4. Review .knowns/imports/ for unexpected entries, and the directory above it for unexpected siblings.

Telemetry and integrity review

• POST /api/imports and DELETE /api/imports/{name} requests where the name is not a simple single segment;
• imports whose source is a repository nobody on the team recognises;
• file modification times outside the project that cluster around an import request;
• unexpected changes to shell startup files, git hooks, editor configuration, and any .knowns/config.json;
• for repositories under version control, git status and git fsck will surface unexpected working-tree changes, though files outside a repository will not be covered;
• host filesystem audit events showing the knowns process writing outside its data directory.

Inferred: because the payload is a file rather than a process, detection should focus on integrity monitoring rather than on runtime behaviour. The malicious write may execute days later, or never — but it is still there.

Remediation and hardening

Required remediation

Upgrade to knowns 0.30.0 or later. The fix adds an explicit, reusable validator and applies it at every entry point:

1
2
3
4
5
6
7
8
9

func validateImportName(name string) error {
if name == "" || name == "." || name == ".." ||
filepath.IsAbs(name) || filepath.VolumeName(name) != "" ||
strings.ContainsAny(name, `/\`) || strings.ContainsRune(name, '\x00') ||
filepath.Base(name) != name {
return fmt.Errorf("invalid import name %q: must be a single path segment", name)
}
return nil
}

This is a good validator, and it is worth reading closely because each clause closes a distinct bypass:

• name == "." || name == ".." — the degenerate relative names;
• filepath.IsAbs(name) — absolute paths that would ignore the base entirely;
• filepath.VolumeName(name) != "" — Windows drive and UNC prefixes;
• strings.ContainsAny(name, "/\\") — both separators, so a Windows-style separator cannot slip past a Unix-oriented check;
• strings.ContainsRune(name, '\x00') — NUL truncation against the syscall layer;
• filepath.Base(name) != name — the catch-all invariant: if the name is not identical to its own basename, it is not a single segment.

That final clause is the one to steal. It expresses the actual requirement — “this is a name, not a path” — rather than enumerating forbidden characters, so it stays correct as platform quirks change.

The validator is called in add, get, remove, and at the top of gitCloneImport, so the check cannot be bypassed by reaching the clone through a different route:

1
2
3
4
5
6

func (ir *ImportRoutes) gitCloneImport(source, name, ref, cachedHash string, dryRun bool) ([]importChange, []string, string, bool, error) {
if err := validateImportName(name); err != nil {
return nil, nil, "", false, err
}
...
}

Note that the fallback nameFromSource(req.Source) result is validated too, because the check sits after the fallback assignment. Derived values are untrusted values.

Defense in depth

• Set a password and keep the listener on loopback (both are default in 0.30.0).
• Treat “import from a URL” as a privileged operation and require authentication and explicit user confirmation for it.
• Run developer tooling with a filesystem view that does not include the home directory’s dotfiles where practical.
• Enable file integrity monitoring for shell startup files, git hooks, and tool configuration on developer machines.
• If an affected version was exposed, audit for unexpected writes rather than assuming absence of an alert means absence of a write.

Timeline

Lessons for builders

A name is not a path

The single most useful invariant in this patch is filepath.Base(name) != name. If a value is documented as an identifier, enforce that it is one at the boundary. Everything downstream then gets to assume it.

Validate derived values, not just supplied ones

name could come from the request or from nameFromSource(req.Source). Only validating the request field would have left the derived path open. Put the check after the value is finalised, immediately before it is used.

Validate at every entry to the dangerous function

gitCloneImport is reachable from more than one route. The fix validates inside it as well as in the handlers. Guarding call sites is a maintenance burden that eventually fails; guarding the function is durable.

Write primitives are execution primitives on developer machines

Threat-model a file write as “the attacker will pick a file that something else executes”. On a workstation, that set is large and mostly undocumented. Score accordingly, and prioritise write traversals above read traversals when triaging.

dryRun is a UX feature

Any flag the caller controls is part of the attack surface, not part of the defence. If a preview mode exists, ensure the security properties hold identically in both modes.

Related advisories in this set

• CVE-2026-86543 — unauthenticated management API exposure
• CVE-2026-86538 — the read-side counterpart, via templateFile
• CVE-2026-86540 — arbitrary code execution via the LSP binary override
• CVE-2026-86439 — path traversal through MCP doc and memory tools
• CVE-2026-86541 — path traversal in the code.replace MCP action
• CVE-2026-86544 — authorisation bypass via misclassified code actions
• CVE-2026-86775 — unauthenticated path traversal through the HTTP Document API

References

• CVE.org record: CVE-2026-86542
• NIST National Vulnerability Database: CVE-2026-86542
• GitHub Security Advisory: GHSA-wh3c-v55g-qfg8
• VulnCheck advisory
• Import add handler at v0.29.1
• gitCloneImport copy loop at v0.29.1
• Fix commit d3989829fb50
• knowns v0.30.0 release notes

Reported by Tong Hoang Gia and Nguyen Huy Hoang. Recheck the primary sources above during remediation; public vulnerability records are frequently revised after publication.

Scope and safety. This article analyses a fixed, publicly disclosed vulnerability using the vendor’s own published source references. It describes the defective data flow and the remediation. It does not include working traversal strings, target path lists, injection prompts, or a runnable proof of concept.

Executive summary

CVE-2026-86541 is a path-traversal vulnerability in the code.replace MCP action of knowns before 0.30.0. The handler took a caller-supplied path, used it verbatim if it was absolute and joined it to the project root otherwise, read the file, performed a literal or regular-expression substitution, and wrote the result back with os.WriteFile.

No step established that the resolved path was inside the project. An absolute path skipped the project root entirely; a relative path with parent-directory segments walked out of it.

The weakness is CWE-22: Improper Limitation of a Pathname to a Restricted Directory. The vendor scores it CVSS 4.0 7.2 High (CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:L/VI:H/VA:H/SC:N/SI:N/SA:N) and CVSS 3.1 8.3 High (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:H/A:H). The CVE record specifically names shell startup scripts and SSH configuration files as targets.

Like CVE-2026-86439, the caller here is an AI assistant, not a browser. And like that issue, it pairs with CVE-2026-86544: code.replace was also misclassified as a read operation, so a session restricted to reading could invoke it in the first place. Read-only session, arbitrary host file write.

Fixed in knowns 0.30.0 by commit a2c98fc5c313.

Evidence labels used below:

• Verified means stated by the CVE record, the GitHub Security Advisory, or the project’s published source and release material.
• Inferred means a deployment or attack-path consequence derived from those facts and clearly marked as such.

Key facts

Root-cause analysis

From internal/mcp/handlers/code.go at v0.29.1:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

func handleCodeReplace(ctx context.Context, getStore func() *storage.Store, getCodeRuntime func() CodeRuntime, req mcp.CallToolRequest) (*mcp.CallToolResult, error) {
store := getStore()
if store == nil {
return errResult("no project loaded")
}
args := req.GetArguments()
path, ok := stringArg(args, "path")
if !ok || strings.TrimSpace(path) == "" {
return errResult("path is required")
}
needle, ok := textArg(args, "needle")
if !ok || needle == "" {
return errResult("needle is required")
}
repl, ok := textArg(args, "repl")
if !ok {
return errResult("repl is required")
}
mode, _ := stringArg(args, "mode")
if mode == "" {
mode = "literal"
}
allowMultiple := boolArg(args, "allow_multiple_occurrences")
absPath := path
if !filepath.IsAbs(absPath) {
absPath = filepath.Join(projectRoot(store), absPath)
}
data, err := os.ReadFile(absPath)
if err != nil {
return errResult(err.Error())
}
...
if err := os.WriteFile(absPath, []byte(next), 0644); err != nil {
return errResult(err.Error())
}
...
}

Two independent escapes in four lines

1
2
3
4

absPath := path
if !filepath.IsAbs(absPath) {
absPath = filepath.Join(projectRoot(store), absPath)
}

This is a resolution helper, not a containment check, and it fails in both branches:

• Absolute path: the if is skipped and path is used exactly as supplied. The project root is never consulted. This is not really traversal at all — it is an unrestricted write target handed over directly.
• Relative path: filepath.Join cleans the result lexically and resolves parent-directory segments outward, past the project root.

The pattern is deceptively reasonable. “If it is already absolute, we are done; otherwise make it absolute relative to the project” is correct resolution logic. It is only wrong because nothing afterwards asks whether the resolved path is somewhere the caller is allowed to write. Resolution and authorisation got conflated, and only resolution was implemented.

There is also no symlink handling, so even a correctly contained lexical path could point outside the root through a link inside it.

The substitution constraints are weaker than they look

At first glance the write seems bounded: the file must already exist (os.ReadFile must succeed), needle must be present, and by default more than one occurrence is rejected. That is not much of a constraint:

• allow_multiple_occurrences is caller-supplied, so the multiplicity guard is off whenever the attacker wants it off;
• mode: "regex" compiles needle as a Go regular expression, and a pattern that matches broadly turns a targeted substitution into a wholesale rewrite of the file’s contents;
• the file only has to exist, and the most valuable targets on a developer machine — shell startup files, SSH configuration, git configuration — generally do.

Inferred: in practice this is a full-content write against any existing file the process can write, not a surgical patch. The VI:H/VA:H rating reflects that.

The permissions layer did not compensate

In the same release, code.replace had no entry in the action registry and inherited CapRead from the tool-level fallback. That is CVE-2026-86544. The practical consequence for this issue is that the capability gate, which existed and worked, was gating the wrong verb — so a session deliberately restricted to reading could still reach os.WriteFile.

Inferred: this is the more general lesson of the pair. A path-containment bug and a classification bug are each individually recoverable; together they remove both the outer and inner control on the same call.

The neighbouring handlers shared it

The fix also rewrites lspPathRequest, which fed handleCodeRename, handleCodeReplaceBody, handleCodeInsert, and handleCodeDelete with the identical IsAbs-or-Join idiom, and changes applyWorkspaceEdit to take the project root so that LSP-driven multi-file edits are contained too. Inferred: the pattern had been copied across the file, which is the usual reason a single-line bug appears in five handlers at once.

Why user interaction is in the vector, and why it is cheap

The vector carries UI:P (CVSS 4.0 passive) / UI:R (CVSS 3.1 required). That is accurate — somebody must be running an assistant session against the knowns MCP server for the call to happen.

Inferred: in an agentic workflow, this requirement is nearly free for an attacker. The “interaction” is a developer doing their normal job: opening a repository, asking an assistant to make a change, letting it read a README or an issue thread or a dependency’s documentation. If any of that content is attacker-influenced, the tool call can be too. The user does not approve a write to ~/.ssh/config; they approve “help me refactor this module”, and the tool argument is chosen downstream by the model.

The attack path:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

Untrusted content the assistant reads
        |
        v
Model emits code.replace with an attacker-influenced `path`
        |
        | classified CapRead (CVE-2026-86544) -> capability gate passes
        v
handleCodeReplace: absPath := path        (absolute, used verbatim)
        |
        v
os.WriteFile(absPath, ...)  as the developer's user
        |
        v
Shell startup file / SSH config / git hook  ->  execution at next trigger

Impact

Verified impact

• Files outside the project root could be overwritten.
• Both absolute paths and relative paths with traversal sequences were accepted.
• Integrity and availability impacts are High; confidentiality is Low (the read that precedes the write returns nothing to the caller directly, but the substitution result is observable).
• The CVE record names shell startup scripts and SSH configuration files as realistic targets.

Deployment-dependent consequences

The following are inferred:

• code execution at the developer’s next shell start, git operation, or tool invocation, depending on which configuration file was modified;
• redirection of SSH connections or acceptance of attacker key material, converting a local write into remote access;
• modification of source, build scripts, or CI configuration in repositories outside the current project — a supply-chain path that reaches production via the developer’s legitimate commits;
• corruption or truncation of arbitrary files through a broadly matching regular expression, which is the availability impact;
• silent, targeted edits to code the developer is about to review, where a small change in a large assistant-generated diff is easy to miss.

Inferred: that final point is specific to agentic tooling and under-appreciated. Developers reviewing AI-generated changes are already scanning a larger diff than they wrote. A one-line modification introduced by a compromised tool call is competing for attention with dozens of legitimate ones.

Safe validation and detection

Inventory and configuration review

1. Identify knowns installations and versions; anything before 0.30.0 is affected.
2. Identify which assistants had the knowns MCP server configured, and whether code tools were auto-approved.
3. Establish the window during which an affected version was in use with an assistant attached.
4. Review the integrity of files outside the project that the account could write — this is the exposure scope, not the project directory.

Telemetry and integrity review

• MCP tool invocations of code.replace, code.rename, code.insert, code.replace_body, and code.delete where path is absolute or contains parent-directory segments;
• any code.replace call in regex mode with a broadly matching needle, or with allow_multiple_occurrences set;
• modification times on shell startup files, SSH configuration, git hooks, and editor configuration that cluster around assistant activity;
• for repositories under version control, unexplained working-tree changes; note that files outside a repository will not be covered by this check;
• host filesystem audit events showing the knowns process writing outside the project root.

Inferred: assistant session transcripts are again the decisive artefact, because they contain the exact path argument. Retain them.

Remediation and hardening

Required remediation

Upgrade to knowns 0.30.0 or later. The fix replaces the resolution idiom with a containment-enforcing resolver and adds a second, independent check before any mutation:

1
2
3
4
5
6
7
8

absPath, err := safepath.ResolveProject(projectRoot(store), path)
if err != nil {
return errResult(err.Error())
}
if err := ensureCodeMutationPath(projectRoot(store), absPath); err != nil {
return errResult(err.Error())
}
data, err := os.ReadFile(absPath)

safepath.ResolveProject still accepts native absolute paths — the tool legitimately needs to work with them — but only when they resolve inside the root:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

// ResolveProject resolves a project path inside root. Native absolute paths
// are accepted only when they still resolve inside root.
func ResolveProject(root, untrusted string) (string, error) {
return resolve(root, untrusted, true)
}

// ResolveProjectReal is ResolveProject plus canonical symlink resolution. It
// is useful when callers must enforce policy against the final target path.
func ResolveProjectReal(root, untrusted string) (string, error) {
path, err := resolve(root, untrusted, true)
if err != nil {
return "", err
}
return resolveProspectivePath(path)
}

That distinction is the well-designed part of the patch. The requirement was never “reject absolute paths”; it was “the final target must be inside the root”. Expressing it that way keeps the feature working while making the unsafe case impossible.

ensureCodeMutationPath then resolves symlinks with filepath.EvalSymlinks and re-checks containment against the real root, so a link planted inside the project cannot redirect a write outside it. The same commit applies both checks to lspPathRequest and handleCodeRename, and threads the project root into applyWorkspaceEdit(projectRoot(store), changes) so LSP-driven multi-file edits are contained as well.

Separately, the commit adds confirmed and reason arguments to the code tool for action=delete, so destructive operations require explicit acknowledgement rather than inheriting the same path as an edit.

Defense in depth

• Do not auto-approve MCP code-mutation tools; require confirmation that shows the resolved absolute path, not the argument as supplied.
• Run assistants against a filesystem boundary enforced by the OS — container, dedicated user, or sandbox — so an application-level containment bug is not the only control.
• Keep SSH keys, cloud credentials, and shell startup files outside the reach of tooling that edits code, where your workflow allows it.
• Enable file integrity monitoring on the small set of files that grant execution or access: shell rc files, SSH config, git hooks, editor startup configuration.
• Review AI-generated diffs against the set of files touched before reviewing their contents; an unexpected path is faster to spot than an unexpected line.

Timeline

Lessons for builders

Resolving a path is not authorising it

if !filepath.IsAbs(p) { p = filepath.Join(root, p) } answers “where does this point?” and never asks “is the caller allowed to write there?”. Those are two operations. Write them as two, or use one function whose contract covers both.

Accepting absolute paths is fine; trusting them is not

The fix did not remove the capability. ResolveProject accepts absolute input and verifies containment. Prefer that shape over a blanket rejection — it keeps legitimate workflows working and removes the temptation to add an unchecked bypass later.

Resolve symlinks before enforcing policy

Lexical containment is necessary and insufficient. If the write matters, canonicalise with EvalSymlinks and check the real path, as ensureCodeMutationPath does.

Copied idioms copy their bugs

The same four lines appeared across several handlers, so one review miss became five vulnerable entry points. When you find a path bug, grep for the idiom rather than fixing the reported call site.

Two weak layers can fail as one

code.replace was both misclassified and uncontained. Neither the permission gate nor the path check stopped the write. When reviewing a mutating operation, verify each layer independently — a control you assume is upstream may be gating the wrong verb.

Related advisories in this set

• CVE-2026-86544 — the classification half of this pair, fixed in the same commit
• CVE-2026-86439 — path traversal through MCP doc and memory tools
• CVE-2026-86543 — unauthenticated management API exposure
• CVE-2026-86538 — unauthenticated arbitrary file read via templateFile
• CVE-2026-86542 — unauthenticated arbitrary file write via import name
• CVE-2026-86540 — arbitrary code execution via the LSP binary override
• CVE-2026-86775 — unauthenticated path traversal through the HTTP Document API

References

• CVE.org record: CVE-2026-86541
• NIST National Vulnerability Database: CVE-2026-86541
• GitHub Security Advisory: GHSA-f539-xgc6-xw7q
• VulnCheck advisory
• handleCodeReplace at v0.29.1
• Fix commit a2c98fc5c313
• knowns v0.30.0 release notes

Reported by Tong Hoang Gia and Nguyen Huy Hoang. Recheck the primary sources above during remediation; public vulnerability records are frequently revised after publication.

Scope and safety. This article analyses a fixed, publicly disclosed vulnerability using the vendor’s own published source references. It describes the defective control flow and the remediation. It does not include a malicious configuration file, command payloads, or a runnable proof of concept.

Executive summary

CVE-2026-86540 is an arbitrary code execution vulnerability in knowns before 0.30.0. Project configuration files (.knowns/config.json) may specify a language-server binary override through settings.lsp.languages[].binary. That field was never validated. When a repository containing a crafted configuration was opened, the named binary was resolved and executed under the user’s account — twice, once for the capability check and once when the language server was started.

The weakness is classified as CWE-78: Improper Neutralization of Special Elements used in an OS Command. The vendor scores it CVSS 4.0 8.5 High (CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:P/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N) and CVSS 3.1 7.8 High (CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H).

This is the “malicious repository, hostile on open” class — the same shape as workspace-trust bugs in IDEs and editors, where a checked-in configuration file is honoured before the user has read a single line of the project. It is also the payoff step for CVE-2026-86542: an unauthenticated attacker who can write a file can plant a .knowns/config.json and wait.

Fixed in knowns 0.30.0 by commit d3989829fb50.

Evidence labels used below:

• Verified means stated by the CVE record, the GitHub Security Advisory, or the project’s published source and release material.
• Inferred means a consequence derived from those facts and clearly marked as such.

Key facts

Why “opening a project” is a security event

Modern developer tooling reads a great deal of configuration out of the repository itself, and that is a genuinely useful design: the project describes how it wants to be built, linted, formatted, and analysed. The trouble is that a repository is untrusted input until somebody has read it, and cloning is not reading.

Developers clone untrusted repositories constantly and for entirely legitimate reasons: reviewing a pull request from an external contributor, reproducing a bug report, evaluating a dependency, triaging a security report, forking an example. In every one of those cases, the ordinary workflow is clone first, read second. Any tool that acts on repository-supplied configuration before that second step has inverted the trust order.

The editor ecosystem learned this the hard way and responded with workspace trust prompts. Inferred: AI-oriented developer tooling is now re-encountering the same class, and often without the prompt, because these tools are designed to reduce the number of moments where a human is asked to confirm something.

The AI angle sharpens it further. A coding assistant’s value proposition is that it opens a project and immediately starts understanding it. That is precisely the behaviour that turns repository-supplied configuration into an execution trigger, and it happens in the window where the developer is least likely to be looking.

Root-cause analysis

The override is trusted verbatim

From internal/lsp/detect.go at v0.29.1:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

func (d *Detector) resolve(ctx context.Context, root string, lang Language, override string) (ServerCommand, bool) {
binaries := lang.Binaries
if override != "" {
binary := Binary{Name: override}
if len(binaries) > 0 {
binary.CheckArgs = append([]string(nil), binaries[0].CheckArgs...)
}
binaries = []Binary{binary}
}
for _, binary := range binaries {
path, err := d.LookPath(binary.Name)
if err != nil {
continue
}
if d.RunCheck != nil && len(binary.CheckArgs) > 0 {
checkCtx, cancel := context.WithTimeout(ctx, 2*time.Second)
err = d.RunCheck(checkCtx, path, binary.CheckArgs...)
cancel()
if err != nil {
continue
}
}
return ServerCommand{Language: lang.ID, Name: binary.Name, Path: path, Args: append([]string(nil), binary.Args...), LogPath: LanguageLogPath(root, lang.ID)}, true
}
return ServerCommand{}, false
}

The critical line is the first one inside the if:

1

binary := Binary{Name: override}

lang.Binaries is the curated list of language servers the adapter knows about — a natural allowlist that already exists in the code. When an override is present, that list is discarded and replaced with a single entry whose name came from the project’s configuration file. The allowlist is right there and is bypassed rather than consulted.

The override then inherits CheckArgs from the first known binary, which is how the arguments for the check invocation get supplied even though the binary itself is unknown.

Execution happens twice

1
2
3
4

func runVersionCheck(ctx context.Context, path string, args ...string) error {
cmd := knownsprocess.CommandContext(ctx, path, args...)
return cmd.Run()
}

The first execution is the capability check — RunCheck runs the binary with the inherited arguments to confirm it works. The second is the language server start, once resolve returns a ServerCommand and the manager launches it.

Inferred: the check invocation is the more interesting of the two, because it is supposed to be a probe. It carries a two-second timeout, which reads like a safety measure, and against a hostile binary it is not one. Two seconds is ample to spawn a detached child, and a process the caller starts is not bounded by the caller’s context after it detaches. Design intent — “this is only a quick version check” — has no bearing on what the executed program actually does.

Manager.StartLanguage contained the same construction on the runtime path:

1
2
3

if override := m.config.BinaryOverride(langID); override != "" {
binaries = []BinaryCandidate{{Name: override}}
}

There is no shell, and it does not help

knownsprocess.CommandContext executes a program directly; there is no shell interpretation, so classic metacharacter injection does not apply. That is why the interesting field is the program name rather than the arguments.

It is worth being clear that this does not reduce the severity. CWE-78 is assigned because untrusted data determines what program runs. Whether a shell is involved changes the exploitation technique, not the outcome. The attacker does not need to inject a command into a command line when they can simply name the program.

d.LookPath resolves the name. Go’s standard library resolves a bare name against PATH and treats a name containing a path separator as a direct filesystem reference. Inferred: that means the override does not have to name something already installed — a reference to an executable carried inside the repository being opened would resolve, which is what makes the malicious-repository scenario self-contained.

Validation existed, and looked elsewhere

From internal/models/config.go at v0.29.1:

1
2
3
4
5
6
7
8
9
10
11
12
13

// Validate rejects malformed lifecycle durations while permitting zero delay.
func (s ProjectSettings) Validate() error {
settings := s.EffectiveTaskLifecycle()
if _, err := ParseTaskLifecycleDuration(settings.ArchiveAfter); err != nil {
return fmt.Errorf("settings.taskLifecycle.archiveAfter: %w", err)
}
if settings.PurgeAfter != nil {
if _, err := ParseTaskLifecycleDuration(*settings.PurgeAfter); err != nil {
return fmt.Errorf("settings.taskLifecycle.purgeAfter: %w", err)
}
}
return nil
}

ProjectSettings.Validate is the obvious place a reviewer would look to confirm that project settings are checked. It validates duration strings and nothing else. A function named Validate that covers one field creates a false impression of coverage — arguably a worse position than having no validation function at all, because it answers the reviewer’s question with a reassuring “yes”.

The trust boundary

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

Repository from an untrusted source
        |
        | .knowns/config.json
        v
Project settings loader
        |
        | settings.lsp.languages[].binary   <-- ProjectSettings.Validate ignores this field
        v
Detector.resolve
        |
        | binaries = []Binary{{Name: override}}   <-- known-good list discarded
        v
LookPath  ->  RunCheck (execution #1)  ->  server start (execution #2)
        |
        v
Developer's user account, environment, credentials, and network position

Impact

Verified impact

• Arbitrary binaries execute under the user’s account when a repository with a crafted configuration is opened.
• No privileges are required beyond the victim opening the project (PR:N, UI:P/UI:R).
• Confidentiality, integrity, and availability impacts are all rated High.
• Execution occurs twice and without any verification of the named binary.

Deployment-dependent consequences

The following are inferred:

• full compromise of the developer’s account, including SSH keys, cloud credentials, tokens, and browser session material;
• access to whatever the workstation can reach — internal services, VPN-routed networks, artefact registries, production consoles;
• persistence via shell startup files, scheduled tasks, or tool configuration, established in the seconds after the repository is opened;
• commit-signing and repository access abuse, turning workstation compromise into a supply-chain event;
• execution on CI runners and shared development hosts, if automation opens untrusted repositories with knowns attached;
• completion of a remote chain when combined with CVE-2026-86542 — unauthenticated file write plants the configuration, this issue executes it.

Inferred: the review workflow is the highest-risk path in practice. Reviewing an external contribution means deliberately opening code from someone you do not trust; that is the whole point of the review. A tool that executes configuration on open turns the most security-conscious activity in the workflow into the delivery mechanism.

Safe validation and detection

Inventory and configuration review

1. Identify knowns installations and versions; anything before 0.30.0 is affected.
2. Search local repositories for .knowns/config.json files containing an LSP binary override, and compare each against what your team actually configured.
3. Pay particular attention to repositories cloned from external sources, forks, and pull-request checkouts.
4. Inspect any override that names a path rather than a familiar language-server binary.

A non-invasive inventory sweep — this only reads and reports, it does not execute anything:

1
2
3

# Locate LSP binary overrides in project configs for manual review.
find . -name config.json -path '*/.knowns/*' -print0 \
  | xargs -0 grep -l '"binary"' 2>/dev/null

Review each hit by hand. Do not open a suspicious repository with an affected version in order to test the behaviour.

Telemetry to review

• process creation events where the knowns process, or a language-server manager, is the parent of an unexpected child;
• short-lived child processes spawned within seconds of a project being opened;
• executions of binaries located inside a repository working tree;
• outbound network connections immediately following a clone or project-open action;
• new persistence artefacts — shell rc changes, cron or systemd user units, login items — created around the same time;
• language-server logs referencing a binary name that is not a known server for that language.

Inferred: parent-child process telemetry is the strongest signal, because the anomaly is structural rather than content-based. A documentation and context tool spawning an unrecognised executable is unusual regardless of what that executable does, and it does not depend on having captured the configuration file beforehand.

Remediation and hardening

Required remediation

Upgrade to knowns 0.30.0 or later. The fix converts the override from a free-form name into a selection from the adapter’s registered binaries:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

func selectBinaryOverride(override string, candidates []Binary) (Binary, error) {
if strings.TrimSpace(override) != override || override == "" {
return Binary{}, invalidBinaryOverride(override)
}
for _, candidate := range candidates {
if candidate.Name == override {
return candidate, nil
}
}
return Binary{}, invalidBinaryOverride(override)
}

func invalidBinaryOverride(override string) error {
return fmt.Errorf("binary override %q must match a registered language-server binary", override)
}

Detector.resolve now fails closed rather than substituting:

1
2
3
4
5
6
7

if override != "" {
binary, err := selectBinaryOverride(override, binaries)
if err != nil {
return ServerCommand{}, false
}
binaries = []Binary{binary}
}

The manager gained a matching validator with an explicit statement of the rule:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

// ValidateBinaryOverride permits selecting only binaries declared by the
// registered language adapter. Arbitrary executable names and paths are never
// accepted from runtime configuration.
func (m *Manager) ValidateBinaryOverride(langID, override string) error {
if override == "" {
return nil
}
m.mu.Lock()
adapter := m.adapters[langID]
m.mu.Unlock()
if adapter == nil {
return fmt.Errorf("no adapter registered for language %q", langID)
}
_, err := selectBinaryCandidateOverride(override, adapter.Binaries())
return err
}

and StartLanguage resolves through the same allowlist rather than trusting the configured name. The HTTP LSP route validates the override too, so the rule holds whether the value arrives from a file or an API call.

The design change worth naming: the override went from being a value to being an index into a known set. The whole class of “what if the name is malicious” disappears, because a name that is not in the set is not a name the system will act on. Note also that the returned candidate carries the adapter’s own CheckArgs and Args, so the fix removes the odd inheritance from binaries[0] at the same time.

Defense in depth

• Treat repository-supplied configuration as untrusted until a human has reviewed it, and do not open unfamiliar repositories with tooling that acts on their configuration.
• Review external contributions in a disposable environment — a container, a VM, or an ephemeral cloud workspace — rather than on the machine that holds your credentials.
• Prefer tools that require explicit trust before honouring workspace configuration, and enable that prompt where it exists.
• Keep long-lived credentials off the machine that opens untrusted code; use short-lived, brokered credentials.
• Monitor process creation on developer workstations. Parent-child anomalies are the most reliable detection for this entire class.
• In CI, never let an untrusted repository’s configuration influence what the runner executes.

Timeline

Lessons for builders

Configuration from a repository is attacker input

If a file inside a project can influence what your tool executes, the project’s authors can execute code on your users’ machines. Enumerate every field that reaches a process launch, a plugin load, or a script evaluation, and treat each one as hostile.

Select from a set; do not accept a name

The strongest form of this fix is not a better filter — it is a different data model. When the configuration selects among options the application already knows, malicious values have nowhere to go. Reach for that shape before reaching for validation.

You already had the allowlist

lang.Binaries was the list of acceptable language servers, sitting in the same function. The override discarded it. When adding a customisation point, check whether the code already contains the set of valid answers — overrides that bypass an existing allowlist are a recurring and highly detectable pattern.

CWE-78 without a shell is still CWE-78

Executing a program directly avoids shell metacharacter injection and does not make untrusted program names safe. Focus review on what runs, not only on how arguments are quoted.

A Validate method that validates one field is a trap

ProjectSettings.Validate gave reviewers a reason to stop looking. If a validation function does not cover every security-relevant field in a structure, say so in its name or its comment — or, better, make it cover them.

A probe is a full execution

RunCheck was meant to ask “does this binary work?”. Against a hostile binary, running it is the compromise, and a short timeout does not contain a process that detaches. There is no such thing as a partial execution.

Related advisories in this set

• CVE-2026-86542 — unauthenticated file write that can plant the configuration this issue executes
• CVE-2026-86543 — unauthenticated management API exposure
• CVE-2026-86538 — unauthenticated arbitrary file read via templateFile
• CVE-2026-86439 — path traversal through MCP doc and memory tools
• CVE-2026-86541 — path traversal in the code.replace MCP action
• CVE-2026-86544 — authorisation bypass via misclassified code actions
• CVE-2026-86775 — unauthenticated path traversal through the HTTP Document API

References

• CVE.org record: CVE-2026-86540
• NIST National Vulnerability Database: CVE-2026-86540
• GitHub Security Advisory: GHSA-mc52-mwq4-vfx3
• VulnCheck advisory
• Detector.resolve at v0.29.1
• ProjectSettings.Validate at v0.29.1
• Fix commit d3989829fb50
• knowns v0.30.0 release notes

Reported by Tong Hoang Gia and Nguyen Huy Hoang. Recheck the primary sources above during remediation; public vulnerability records are frequently revised after publication.

Scope and safety. This article analyses a fixed, publicly disclosed vulnerability using the vendor’s own published source references. It describes the defective data flow and the remediation. It does not include working traversal strings, target file lists tuned for exploitation, or a runnable proof of concept.

Executive summary

CVE-2026-86538 is a path-traversal vulnerability in knowns before 0.30.0. The POST /api/templates/preview endpoint accepted a caller-supplied templateFile value, joined it onto the resolved template directory with filepath.Join, read the resulting path from disk, and returned the contents in the JSON response.

filepath.Join cleans the path it produces. It does not constrain the result to the base directory. A templateFile containing parent-directory segments therefore resolves outside the template root, and the endpoint happily reads and returns it.

The weakness is CWE-22: Improper Limitation of a Pathname to a Restricted Directory. The vendor scores it CVSS 4.0 8.7 High (CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N) and CVSS 3.1 7.5 High (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N) — confidentiality-only, but complete.

The PR:N in that vector is not an accident. It is the direct consequence of CVE-2026-86543, which left the management API unauthenticated on all interfaces by default. The two together make this a credential-free remote file-read primitive against a developer’s machine.

Fixed in knowns 0.30.0 by commit 09c5a96fd581.

Evidence labels used below:

• Verified means stated by the CVE record, the GitHub Security Advisory, or the project’s published source and release material.
• Inferred means a deployment consequence derived from those facts and clearly marked as such.

Key facts

Why a “preview” endpoint is a file-read primitive

Template preview features share a recognisable shape across products: take a template identifier, take a file name inside that template, render it with some variables, show the result. Each step looks harmless. The composite is a request-controlled read whose output is returned verbatim to the caller.

Three properties make this variant more serious than the average traversal bug:

• The output is the file, not a side effect. Some traversal bugs only leak existence or a boolean. This one returns content in the response body.
• There is no extension constraint. The default is main.hbs, but nothing requires the supplied value to end in .hbs. Any readable path is fair game.
• The process runs as the developer. knowns is a developer tool, so the reading process holds the developer’s own filesystem privileges — not a hardened service account.

Inferred: the interesting targets are therefore not project files, which the caller could often read through legitimate endpoints anyway, but the developer’s ambient secrets: environment files, cloud credential directories, SSH material, shell history, and the tool’s own configuration.

Root-cause analysis

The vulnerable handler in internal/server/routes/templates.go at v0.29.1:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

// POST /api/templates/preview
func (tr *TemplateRoutes) preview(w http.ResponseWriter, r *http.Request) {
var req previewTemplateRequest
if err := decodeJSON(r, &req); err != nil {
respondError(w, http.StatusBadRequest, "invalid request body: "+err.Error())
return
}

tmpl, err := tr.getStore().Templates.Get(req.Name)
if err != nil {
respondError(w, http.StatusNotFound, "template not found: "+err.Error())
return
}

templateFile := req.TemplateFile
if templateFile == "" {
templateFile = "main.hbs"
}

hbsPath := filepath.Join(tmpl.Path, templateFile)
hbsContent, err := os.ReadFile(hbsPath)
if err != nil {
respondError(w, http.StatusNotFound, "template file not found: "+templateFile)
return
}

// Simple variable replacement: {{varName}} → value
rendered := string(hbsContent)
if req.Variables != nil {
for k, v := range req.Variables {
rendered = strings.ReplaceAll(rendered, "{{"+k+"}}", v)
}
}
...
}

The bug is one line, and it is a line that appears in a great deal of Go code:

1

hbsPath := filepath.Join(tmpl.Path, templateFile)

The filepath.Join misconception

filepath.Join joins elements and calls Clean on the result. Developers frequently read “cleans the path” as “makes the path safe”. It does not. Clean resolves .. segments lexically, which means it happily produces a path above the base directory when the untrusted element asks for it. Joining a base with ../../x yields a sibling of the base’s parent, not an error and not a path inside the base.

Nothing in the handler re-checks the result. There is no strings.HasPrefix containment check, no filepath.Rel verification, and no symlink resolution.

The variable substitution runs after the read

1
2

rendered := string(hbsContent)
if req.Variables != nil { ... }

Substitution only replaces {{name}} placeholders that happen to appear in the content. A file with no placeholders passes through unchanged, so the response contains the raw file. Inferred: this makes the primitive clean rather than lossy — the attacker does not have to reconstruct content from partial rendering artefacts.

The data flow

1
2
3
4
5
6
7
8
9
10
11
12
13
14

POST /api/templates/preview   (unauthenticated by default)
        |
        | { "name": <known template>, "templateFile": <untrusted> }
        v
Templates.Get(name)  ->  tmpl.Path   (trusted base)
        |
        v
filepath.Join(tmpl.Path, templateFile)      <-- lexical join, no containment
        |
        v
os.ReadFile(...)                            <-- reads as the developer's user
        |
        v
JSON response body                          <-- content returned to caller

Note that Templates.Get(req.Name) is validated — the template must exist. The developer applied validation to the parameter that felt like an identifier and omitted it on the parameter that felt like a filename. Inferred: that asymmetry is a common and instructive pattern; the field that looks most like a path is the one that most needs a containment check, and it is often the one that gets the least.

Impact

Verified impact

• An unauthenticated network caller could read arbitrary files accessible to the server process.
• Contents are returned directly in the JSON response.
• The CVE record specifically cites credentials and configuration as exposed material.
• Integrity and availability are not affected by this issue in isolation (VI:N/VA:N).

Deployment-dependent consequences

The following are inferred:

• disclosure of .env files, cloud credential files, API tokens, and CI secrets present on the host;
• disclosure of SSH private keys and configuration, and of the knowns configuration itself;
• disclosure of source code, internal specifications, and architectural decisions outside the current project;
• reconnaissance that makes the write-side issues in this set more effective, because an attacker who can read .knowns/config.json and the project layout knows exactly where to aim CVE-2026-86542;
• onward compromise of any service whose credentials were recovered — the blast radius is set by what the developer’s account can reach, not by knowns.

Inferred: for a developer workstation, a reliable arbitrary file read is frequently equivalent to a credential compromise, because development machines are where long-lived tokens accumulate.

Safe validation and detection

Inventory and configuration review

1. Identify knowns installations and record versions; anything before 0.30.0 is affected.
2. Determine whether the management API was reachable beyond loopback — see CVE-2026-86543 for the bind-address and password checks.
3. Confirm the exposure window: how long did an affected version run, on what networks, and was a tunnel ever started?
4. Inventory what was readable by that user account during the window. That set, not the project directory, is the exposure scope.

Do not validate by sending traversal payloads at a production or shared host. Version and bind-address facts answer the question without touching the vulnerable path.

Telemetry to review

• POST /api/templates/preview requests where templateFile is present and is not a plain relative name;
• any templateFile value containing parent-directory segments, absolute path prefixes, or backslashes;
• preview requests from source addresses other than loopback;
• response sizes on the preview endpoint that are far outside the normal distribution for templates;
• bursts of preview requests iterating over similar names, which is the signature of enumeration rather than use;
• reads of sensitive files by the knowns process in host filesystem audit logs (auditd, EDR, or equivalent).

Inferred: the last item is the most reliable signal, because it observes the sink rather than the request. Request logging can be absent or truncated, but a process-level read of a credential file by a documentation tool is anomalous on its face.

Remediation and hardening

Required remediation

Upgrade to knowns 0.30.0 or later. The fix introduces a dedicated internal/safepath package and routes the preview through it:

1
2
3
4
5
6

hbsPath, err := safepath.Resolve(tmpl.Path, templateFile)
if err != nil {
respondError(w, http.StatusBadRequest, "invalid template file path")
return
}
hbsContent, err := os.ReadFile(hbsPath)

safepath.Resolve is the interesting part of the patch, because it treats path validation as a real parsing problem rather than a substring check:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

// Package safepath resolves untrusted filesystem paths inside an explicit root.
func resolve(root, untrusted string, allowContainedAbsolute bool) (string, error) {
if strings.TrimSpace(untrusted) == "" {
return "", fmt.Errorf("path is required")
}
if strings.IndexByte(untrusted, 0) >= 0 {
return "", fmt.Errorf("path contains a NUL byte")
}

normalized := strings.ReplaceAll(untrusted, `\`, "/")
if strings.HasPrefix(normalized, "//?/") || strings.HasPrefix(normalized, "//./") {
return "", fmt.Errorf("path must not use a Windows device prefix")
}
if strings.HasPrefix(normalized, "/") && !allowContainedAbsolute {
return "", fmt.Errorf("path must be relative")
}
...
for i, segment := range strings.Split(normalized, "/") {
if segment == ".." {
return "", fmt.Errorf("path must not contain parent traversal")
}
...
}
...
}