Jan: a dangling symlink writes outside the agent's workspace
A symlink pointing at a file that does not exist yet let Jan's agent tools write outside the workspace they were meant to guard.
· Jan · Research by Zachariah Mithani (AploSec)
Jan's write and edit tools did not resolve symlinks pointing at files that do not exist yet, so a planted link let an agent write into SSH or shell startup files while the approval prompt showed an in-workspace path.
01What happened
The Jan project published an advisory on 29 October 2026 for a workspace guard bypass in its agent write and edit tools, reported by Zachariah Mithani of AploSec. Versions 0.8.5 through 0.8.7 are affected and 0.8.8 carries the fix.
02How it works
Jan's guard resolved a target path only as far as its deepest existing ancestor, then treated the rest as plain text. A dangling symlink, one whose target does not exist yet, therefore passed the check: a link sitting inside the workspace but pointing outside it looked like an ordinary workspace write. Malicious repository contents or prompt injection supply the instruction, and the write lands wherever the link points, such as an SSH authorized_keys or a shell startup file.
03Who is affected
Jan users on 0.8.5 through 0.8.7 who open an untrusted workspace and then allow write or edit operations, either by approving them or through auto-approval. The approval prompt is part of the problem: Jan showed only the in-workspace file name, not the real destination the link resolved to.
04What to do
Update Jan to 0.8.8, which resolves every link along a target path, including dangling ones, and opens files without following a trailing symlink. Check SSH and shell startup files on any machine where Jan ran against a repository you did not write.
Sources 4 links, all fetched
- 1github.comJan Advisory
- 2vulncheck.comVulnCheck Advisory
- 3github.comFix Pull Request
- 4github.comJan 0.8.8 Release