dsh-qq-notify

runQqPs derives the script path from dirname(cfg.napcatDir) and executes it with policy bypass; cfg.napcatDir is writable without any path validation by the qq_config_set tool (VALID_KEYS includes 'napcatDir') and by the /dsh-qq-notify/config route. A prompt-injected agent can therefore point napcatDir at any directory that contains a qq.ps1 (e.g. a downloaded or dropped file) and have arbitrary PowerShell execute with the user's privileges; the fixed action enum only restricts the argument, not the script body.

deployNapcat fetches the 'latest' GitHub release asset (node.exe bundle), extracts it with Expand-Archive, copies it into a model-chosen directory, silently rewrites napcat/napcat.mjs, and the resulting qq.ps1 is later executed through runQqPs. There is no hash/signature check and downloadFile follows redirects to arbitrary schemes/hosts, so a compromised release, a hijacked asset redirect or a network attacker can place executable code that this plugin will then run.

The optional 'to' argument makes every readable conversation/workspace content sendable to an attacker-chosen QQ number through the user's logged-in bot account, forming a low-friction outbound channel during a prompt-injection scenario. Impact is limited because the direction (local bot to QQ) carries no inbound secrets and the capability is documented in the tool schema.

qq_find and the /dsh-qq-notify/find route recursively readdir/stat the user's home directory (depth up to 6-8), which discloses directory structure through timing/errors and, in practice, shows the agent the paths of any stray qq.ps1 or napcat-named folder on disk. Returned data is limited to matching candidates, so the leak is narrow.