What happened
A Jan agent session writes payload content to an in-workspace symlink, creating the specified file outside the workspace.
2026-10-29
MediumVendor postJan Agent Writes Followed Dangling Symlinks Outside the Approved Workspace
Jan disclosed an agent-session demonstration where a workspace write followed a dangling symlink to an outside file, fixed in version 0.8.8.
Jan agent write and edit toolsTool execution / MCPVendor-disclosed controlled agent-session workspace-write bypassJan desktop agent-tools plugin and Jan CLI; vendor advisory lists versions 0.8.5 through 0.8.7, patched in 0.8.8
Why it matters
The advisory describes creation of an outside-workspace file in the host context. Potential arbitrary code execution is an impact assessment, not a demonstrated downstream compromise.
Missing authorization check
Destination-bound authorization using resolved filesystem identity at the actual write, with race-resistant handling of links.
Would PP block it?
Authority could bind the canonical target, write operation and payload rather than a lexical workspace filename. A gate relying on the same flawed canonicalization would not stop this path. Permission Protocol was not evaluated by the advisory and does not replace the vendor patch.
Incident analysis
Timeline and technical read
Timeline
2026-10-29
Jan publishes GHSA-7j4g-mj5j-p842 describing the agent write/edit workspace guard bypass and version 0.8.8 fix.
Technical breakdown
- The reproduction requires an untrusted workspace containing a dangling symlink to a nonexistent file with an existing parent.
- The agent session has write permission or the user approves the displayed workspace-path write.
- The old canonicalization fallback re-appends remaining path segments lexically without resolving the dangling link.
- The host follows the link during execution and creates the outside file with supplied contents.
- The vendor fix resolves links along the target path and avoids following trailing symlinks to mitigate post-check races.
Authorization boundary
Where the authorization boundary should have been
This incident is categorized as Tool execution / MCP. The relevant Permission Protocol gate is Tool-Call Gate. The read is conditional: the block only applies where the real action boundary is routed through a gate.
- If enforced at
- Filesystem write and edit sink after destination resolution and before mutation
- Still needs
- PP is not a filesystem sandbox or symlink-resolution fix. Lexical checks, post-check races, unmediated host writes and an already compromised host remain outside this mapping. No in-the-wild exploitation or downstream arbitrary code execution is established by the reviewed advisory.
- Receipt required for
- Writing or editing the resolved host file, with explicit authority for any destination outside the delegated workspace
An external gate could constrain writes to the actual approved destination only if the sink resolves paths correctly and completely mediates effects.
Related incidents and controls
Start small
Put the relevant gate at this action boundary.
This incident maps to Tool-Call Gate. Start with the boundary that controls the actual action, then require a signed receipt before execution.