Dangerous exec
- Finding
- Shell command execution detected (child_process).
Security checks across static analysis, malware telemetry, and agentic risk
The skill does what it claims—server monitoring and auto-restart—but it includes unsafe SSH guidance and a watchdog script that can send alerts to a hard-coded Telegram chat if not reconfigured.
Install only if you are comfortable giving the agent/server watchdog SSH and service-restart authority. Before use, remove the hard-coded Telegram chat ID, explicitly configure alert recipients, avoid the password-based SSH example with host-key checking disabled, and test the watchdog’s restart behavior on a non-critical system first.
VirusTotal findings are pending for this skill version.
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
Server outage details, crash reasons, and operational status could be disclosed to the wrong Telegram chat or alerts may silently go to an unexpected destination.
The alert destination falls back to a hard-coded Telegram chat ID. If a user supplies a bot token but does not set TELEGRAM_CHAT_ID, server status and crash details may be sent to an unintended recipient or fail unpredictably.
botToken: process.env.TELEGRAM_BOT_TOKEN || '', chatId: process.env.TELEGRAM_CHAT_ID || '1663667034', enabled: true
Remove the hard-coded chat ID, require the user to explicitly configure the alert recipient, and declare TELEGRAM_BOT_TOKEN and TELEGRAM_CHAT_ID in the skill metadata or setup instructions.
A server password could be exposed or used against the wrong host if this example is copied without safeguards.
The password-based SSH example disables host-key verification and places the password in an inline automation script, increasing the risk of credential exposure or connection to a spoofed host.
spawn ssh -o StrictHostKeyChecking=no user@host "COMMAND"
expect {
"password:" { send "PASSWORD\r"; exp_continue }Prefer SSH keys, keep host-key checking enabled, verify host fingerprints, and use a secure secret mechanism rather than embedding passwords in command snippets.
If deployed to the wrong host or configured incorrectly, the watchdog could restart an important service unexpectedly.
The script can execute shell commands to stop and start the MongoDB Windows service. This matches the watchdog purpose and is bounded to a configured service name, but it can affect production availability.
exec(cmd, { timeout: 30000 }, ...)
await execCmd(`net stop "${CONFIG.service.name}"`);
await execCmd(`net start "${CONFIG.service.name}"`);Deploy only on the intended server, review the configured service name and restart limits, and test in a non-production environment before enabling auto-restart.
The watchdog may keep monitoring and restarting MongoDB until the user explicitly stops or removes the PM2 process.
The skill explicitly instructs users to run a persistent PM2-managed watchdog. This is disclosed and purpose-aligned, but it means the automation continues operating after setup.
For persistent monitoring, deploy the included watchdog script: 1. Copy `scripts/mongodb-watchdog.js` to target server 3. Start: `pm2 start mongodb-watchdog.js --name mongodb-watchdog` 4. Save: `pm2 save`
Document and verify stop/rollback steps, such as `pm2 stop mongodb-watchdog` and `pm2 delete mongodb-watchdog`, before deployment.