GHSA-48v2-6jcm-fc99: praktor: Path traversal in Telegram file uploads allows writing outside the agent workspace uploads/ directory (stored instruction injection)
Impact
A remote Telegram user can write files to arbitrary paths inside an agent's persistent workspace volume (praktor-wk-<workspace>, mounted at /workspace/agent), escaping the documented uploads/ directory.
The attacker controls the Telegram document filename, which was concatenated into the destination path without sanitization (internal/telegram/bot.go, at both upload sites) and resolved with path.Join, which collapses ../ sequences. A filename like ../../../CLAUDE.md resolved to the root of the agent workspace volume, outside uploads/.
Because the agent workspace is the persistent working directory the Claude agent reads from and operates on across runs, writing outside uploads/ lets an attacker plant or overwrite files the agent later consumes — e.g. CLAUDE.md, agent instruction/skill/hook files, or other config under /workspace/agent. This turns a file upload into a stored injection into the agent's instruction/execution surface (CWE-22 path traversal escalating to stored instruction injection).
Reachability
By default the bot has no user allowlist (allowfrom: [] means "allow all"), so the only precondition is that a user can message the bot. No authentication or prior privilege is required.
Affected versions
Through v0.9.0 (and HEAD 3902d29).
Patched versions
v0.9.1, containing PR #228.
Workarounds
Restrict telegram.allowfrom to trusted user IDs to limit who can send uploads to the bot. Upgrading to v0.9.1 is the recommended fix.
Fix (defense in depth)
- internal/telegram/bot.go: apply path.Base() to the attacker-controlled filename at both upload sites, stripping directory components and ... - internal/container/manager.go: WriteVolumeBytes now rejects any path that escapes /vol after path.Join, protecting future callers.
Credit
Reported privately by tonghuaroot, who provided a detailed root-cause analysis, a deployed end-to-end proof of concept against the real container.Manager, and fix verification.
Other sources
praktor is a multi-agent Claude Code orchestrator with Telegram input and output, Docker isolation, and a Mission Control UI. Prior to 0.9.1, both Telegram upload sites in internal/telegram/bot.go concatenate the attacker-controlled document filename into a destination path without sanitization, and path.Join collapses parent-directory traversal. A remote Telegram user who can message the bot can therefore write outside uploads/ within the persistent agent workspace mounted at /workspace/agent. Because allowfrom: [] permits all senders by default, no prior authentication or privilege is required in that configuration. The attacker can plant or overwrite CLAUDE.md, instruction, skill, hook, or configuration files that the Claude agent reads and operates on across later runs, turning a document upload into stored instruction injection. The demonstrated arbitrary-write scope is the persistent agent workspace volume, not an unrestricted host-filesystem write. This issue is fixed in version 0.9.1.
— OSV
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
go/github.com/mtzanidakis/praktorto a version that resolves this vulnerability.Fixed in 0.9.1 - Upgrade
Upgrade
praktorto a version that resolves this vulnerability.Fixed in 0.9.1 - Configuration
Restrict telegram.allow_from to trusted user IDs to limit who can send uploads to the bot.
Telegram bot telegram.allow_from = trusted user IDs
Event History
Frequently Asked Questions
Are bots using the default access settings exposed?
Yes. The default configuration has no user allowlist: allow_from: [] means allow all. Any Telegram user who can message the bot meets the stated precondition.
What does an attacker need to exploit this?
The attacker needs to send the bot a Telegram document with a filename containing traversal sequences such as ../../../. No authentication, user interaction, or special configuration is required when the default allow-all setting is in use.
What can be affected after a successful upload?
The attacker can write outside the intended uploads/ directory but within the persistent agent workspace mounted at /workspace/agent. This can include files the agent consumes on later runs, such as CLAUDE.md, instruction, skill, hook, or other configuration files.
How can I identify the vulnerable behavior in a deployment?
The affected upload handling concatenates the Telegram document filename into the destination path and resolves it with path.Join at both Telegram upload sites in internal/telegram/bot.go. A traversal filename can then resolve outside uploads/ and into the workspace root.