jarvis-mission-control

This module contains a critical process-execution sink (execFile(entry.cmd, entry.args)) and returns stdout/stderr in JSON; whether this is exploitable depends on how entry.cmd/entry.args are derived earlier (not shown). It also persists GitHub tokens to a plaintext local config file and allows user-controlled markdown content to be written to agent files. No obvious direct malware/backdoor behavior is visible in the provided fragment, but the execFile path and secret/file handling should be reviewed carefully for attacker control and downstream rendering/usage.

No direct indicators of deliberate malware (e.g., obfuscated payloads, command execution, credential theft, persistence) are present in the provided fragment. However, the component substantially increases privacy and integrity risk: it ingests untrusted local agent session content and forwards extracted user/agent text and derived identifiers to a remote Mission Control backend and a Telegram-task-creation path without visible redaction/allowlisting or integrity checks. Additional review is warranted for input validation of agentName/sessionId used in filesystem paths, and for protecting remote endpoints (MC_SERVER_URL/authorization, payload validation, and limiting task-ID linking based on untrusted message text).

No clear malware/backdoor behavior is present (no eval/Function/child_process, no suspicious third-party loading, network calls are to configured API endpoints). However, the code constructs local filesystem paths using unsanitized identifiers (task.id and task_id suffix inputs) for write operations, which could enable path traversal or unintended file writes if attacker-controlled values can reach those fields. cmdDeliver also allows copying arbitrary local files into deliverables if invoked with attacker-chosen --path. Review/validate task.id and CLI id inputs (allowlist safe filename characters) and ensure the server never returns unsafe task.id values.

SUSPICIOUS. The core functionality broadly matches a self-hosted coordination dashboard, but the skill overstates its safety posture: it is not truly 'no code execution' or strictly 'data local only,' and it sources executable code from a personal GitHub repo under branding that does not clearly match the repo owner. The added transitive skill-install instruction further expands trust scope. This is not confirmed malware, but it carries medium security risk and trust inconsistencies.

This script contains no overt malicious code (no eval/exec of downloaded content, no reverse shells, no explicit data exfiltration beyond the intended API calls, and no hardcoded credentials). However, it is a significant supply-chain deployment primitive: it downloads an update ZIP from a remote API and unconditionally extracts it into the live application directory with overwrite enabled, without any authenticity/integrity verification of the artifact and without explicit path-safety controls in the script. If the update endpoint, network path, or ZIP payload is compromised, the script could deploy attacker-controlled files into the local Mission Control installation.

No clear malicious payload indicators are present (no network calls, no credential access, no obfuscated execution, no obvious persistence). However, the script has meaningful integrity/security risks: it embeds untrusted CLI input (especially $status) directly into shell-constructed jq and sed program strings without robust escaping, and update mode uses a user-supplied task-id to determine which on-disk file to modify under a configurable directory. Overall, this is more consistent with potential sabotage/poisoning of local task records and robustness/validation gaps than confirmed malware.

No direct malicious code is present in this configuration fragment; it is a PM2 launcher file. The primary security issue is severe operational/secrets risk: it hardcodes a plaintext password and multiple high-entropy tokens into environment variables that will be consumed by the application at runtime. This should be replaced with secure secret injection (e.g., runtime environment variables/secret managers) to prevent credential compromise and unauthorized access.