dsh-pve

The local path comes from the model's tool argument with no allowlist, extension or size restriction; the file is then multipart-uploaded to a storage the model can afterwards enumerate. If the conversation is steered by untrusted PVE content, secrets on the DSH host (e.g. ~/.ssh/id_rsa, shell/DSH config files) can be exfiltrated to the configured PVE server. The mandatory approval prompt mitigates this because it prints the local path, but the path is rendered as one field among many.

Arbitrary commands can be run as root on the Proxmox node, but this is the documented purpose of an admin plugin tied to an existing root-level API token, and every call is intercepted by the tools/pre-execute hook (SPECIAL_WRITE_NAMES) which forces a native approval prompt showing the full argv. No bypass was found; risk is limited to blind approval after prompt injection.

In token mode the PVEAPIToken header (which contains the secret) and in password mode the login password plus the resulting PVEAuthCookie are sent over an unencrypted channel if the user configures an http:// URL. The client card validates and stores such URLs without warning; there is no reason to need http because allowInsecureTls already covers self-signed HTTPS hosts.

basename() removes directory components but keeps quotes and newlines, so a crafted filename can inject additional lines/parts into the multipart body sent to the PVE upload endpoint. Impact is limited (the request still requires approval and can only reach the upload endpoint), but the body structure is model-controlled.