dingtalk-bridge

SUSPICIOUS: the DingTalk integration itself is purpose-aligned and uses official-looking service flows, but the skill’s main function is a 24/7 chat-driven execution bridge. The combination of unattended external-message ingestion, Claude CLI invocation, Bash permission, and automatic replies creates high prompt-injection and autonomous-action risk even without clear evidence of malware or credential theft.

High security risk. The Stream handler turns untrusted DingTalk mention text into input for a locally executed Claude CLI via subprocess.run, including a permissions-bypass style flag, and the child process inherits the full environment (potential exposure of DingTalk secrets). The module also optionally installs macOS LaunchAgent persistence, and it can egress generated content to outbound destinations derived from callback data. Treat as critical risk: require strict allowlists/approval before execution, validate callback provenance and webhook destinations, minimize/whitelist environment passed to subprocess, and disable or tightly control persistence and dangerous CLI flags.

No explicit malware/backdoor code is visible in this module. However, it exhibits a high-risk execution-and-forward pattern: it runs an external Claude-like binary with '--dangerously-skip-permissions' using untrusted user input as the prompt, passes the full environment to that subprocess, and then forwards stdout/stderr to a webhook URL sourced directly from incoming message metadata. Even if the code is intended for chat-ops, this materially increases the risk of data leakage, attacker-controlled outbound reporting, and expanded blast radius if the invoked tool or related helper functions are compromised or unexpectedly permissive. Review/containment should focus on strict validation/allowlisting of webhook destinations, prompt handling, environment sanitization, and removal/justification of the permission-bypass flag.