Path traversal in Praktor lets Telegram users plant agent orders
A flaw disclosed on 3 November 2026 allowed anyone who could message a Praktor bot to overwrite the files its Claude agent reads.
By The Agentic Times ·

A path traversal flaw in Praktor, an open-source agent workflow tool published by the GitHub user mtzanidakis, allowed a remote Telegram user to write files anywhere inside an agent's persistent workspace, according to a GitHub security advisory published on 3 November 2026. The issue is tracked as CVE-2026-62331 and GHSA-48v2-6jcm-fc99. It affects all versions through v0.9.0, including the HEAD commit 3902d29, and is fixed in v0.9.1.
Praktor connects a Telegram bot to a Claude agent running in a container. Uploaded documents are meant to land in an uploads/ directory inside the agent's workspace volume, which the advisory describes as praktor-wk-<workspace> mounted at /workspace/agent. The advisory says the filename supplied by the Telegram user was concatenated into the destination path without sanitisation at both upload sites in internal/telegram/bot.go, then resolved with Go's path.Join, which collapses ../ sequences. A document named ../../../CLAUDE.md therefore resolved to the root of the workspace volume, outside the intended uploads folder.
That escape matters because the workspace is the persistent working directory the Claude agent reads from and operates on across runs. The advisory says writing outside uploads/ lets an attacker plant or overwrite files the agent later consumes, naming CLAUDE.md, agent instruction, skill and hook files, and other configuration under /workspace/agent as examples. The result, it says, is that a file upload becomes a stored injection into the agent's instruction and execution surface, with a path traversal weakness (CWE-22) escalating into stored instruction injection.
The advisory rates the problem as easy to reach. By default the bot ships with no user allowlist, because the allow_from: [] setting means "allow all". The only precondition is that a user can message the bot. No authentication and no prior privilege are required, according to the advisory.
The fix in v0.9.1, delivered in pull request #228, applies path.Base() to the attacker-controlled filename at both upload sites, stripping directory components and .. sequences. As defence in depth, the advisory says WriteVolumeBytes in internal/container/manager.go now rejects any path that escapes /vol after path.Join, which protects future callers that build paths the same way.
For operators who cannot upgrade immediately, the advisory suggests restricting telegram.allow_from to trusted user IDs, which limits who can send uploads to the bot. It describes upgrading to v0.9.1 as the recommended fix.
The flaw was reported privately by the GitHub user tonghuaroot, who the advisory credits with a detailed root-cause analysis, a deployed end-to-end proof of concept against the real container.Manager, and verification of the fix. The advisory does not say whether the issue was exploited in the wild, and gives no figures on how many deployments were affected.
The pattern is a familiar one for agent tooling. A conventional web-era bug, unsanitised filenames in an upload handler, gains extra weight when the directory it writes into is also the place an autonomous agent looks for its own instructions. In that setting, the ability to drop a file is close to the ability to issue commands.
Sources
- github.comhttps://github.com/advisories/GHSA-48v2-6jcm-fc99
