T09 · Insecure Skill Coding Practices
- Location
scripts/monitor.py:29- Finding
HTTPS Certificate Validation Is Disabled
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This web page monitor mostly matches its stated purpose, but it disables HTTPS verification and can run unrestricted local shell commands when a page changes.
Install only if you are comfortable reviewing and controlling every URL and notification command. Avoid --notify with untrusted or generated input, do not run watch mode with privileged accounts, and treat HTTPS results as unauthenticated unless the TLS verification issue is fixed.
scripts/monitor.py:29HTTPS Certificate Validation Is Disabled
scripts/monitor.py:24Unrestricted URL Fetching Enables Server-Side Request Forgery and Local Resource Access
scripts/monitor.py:101Notification Hooks Execute Arbitrary Commands Through the System Shell
references/examples.md:51Documentation Recommends Installing an Unpinned Third-Party Package
This is a true vulnerability because the documented purpose omits materially risky behavior: arbitrary shell execution via --notify and disabled SSL certificate verification during page fetches. The mismatch increases the chance that a user will run the skill in a more trusted way than warranted, while SSL bypass enables man-in-the-middle tampering and shell execution can turn a content change into code execution in the operator's environment.
Allowing arbitrary shell commands as a notification mechanism exceeds the stated capability of simple web-page monitoring and effectively turns the tool into a command runner. This broadens the attack surface significantly, especially in automation contexts where arguments may be templated, copied from examples, or influenced by untrusted sources.
The script executes the user-supplied --notify value with os.system(), which invokes a shell and permits arbitrary command execution. In a skill whose purpose is web page monitoring, this creates a dangerous command-execution capability unrelated to the core function and can be abused if untrusted input reaches this argument or if users misunderstand the risk.
print(f"Previous: {prev['hash'][:16]}...")
print(f"Current: {current_hash[:16]}...")
if args.notify:
os.system(args.notify)
return 2
else:
print(f"No previous data to compare (file: {args.compare})")
In watch mode, the arbitrary notification command can be triggered repeatedly on each detected change, creating a persistent command-execution path beyond the monitoring purpose. In context, a web-monitor skill polling attacker-controlled content makes this more dangerous because remote content changes can indirectly trigger repeated local actions.
This watch-mode path repeatedly executes the user-provided notification command whenever content changes, again via os.system() and a shell. That increases exposure because an attacker controlling page content or triggering frequent changes can repeatedly cause command execution once a dangerous notify string is configured.
if new_hash != current_hash:
print(f"\n[{datetime.now().isoformat()}] CHANGE DETECTED!")
if args.notify:
os.system(args.notify)
current_hash = new_hash
data['hash'] = new_hash
data['content'] = new_content if not args.hash_only else None
The skill advertises behavior that implies network access, file writes, and shell execution, but it does not declare any tool scope or permissions. This is dangerous because users and policy layers cannot accurately assess or restrict the skill's capabilities, especially given the presence of a notification feature that can invoke shell commands.
The documentation explicitly encourages running an arbitrary command when a page changes but provides no warning that this results in shell execution. In the context of a web-monitoring skill, this is more dangerous because remote web content can influence when the command fires, creating a bridge from untrusted network input to local command execution workflows.
The manifest describes monitoring web pages and notifying on changes, but the examples instruct users to pass free-form shell commands via --notify, such as telegram-send .... Allowing arbitrary command execution is a substantially broader capability than page monitoring itself and is not justified by the stated purpose alone.
The job posting example shows --notify "echo 'New jobs posted!'", again implying that notification handling executes arbitrary shell commands. While notifications are within scope, exposing them as unrestricted command execution is not an obvious requirement of a web monitoring skill.
The watch-mode example uses --notify "telegram-send 'Product is now available!'", reinforcing that the skill's notification path likely executes external commands. This is a broader operational capability than the manifest's monitoring-and-notification description suggests.
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
curl -X POST "https://hooks.slack.com/services/XXX" -d "{\"text\":\"Change detected\"}"
The comment understates the insecurity of the TLS configuration: the code disables both certificate validation and hostname verification. This mismatch can mislead maintainers or reviewers into believing the risk is narrower than it is, increasing the likelihood that insecure transport remains unnoticed in production.
TLS certificate and hostname verification are disabled for all HTTPS fetches, allowing man-in-the-middle attackers to spoof monitored sites and alter the content being hashed or stored. For a web monitoring tool, this directly undermines the integrity of the monitored data and can cause false alerts, missed changes, or trust in attacker-supplied content.
The tool executes a user-provided shell command for notifications without presenting any safety warning, making it easy for users to enable dangerous behavior unintentionally. Because os.system() uses a shell, metacharacters and chained commands are interpreted, which magnifies the risk beyond simply launching a program.
In watch mode, the absence of a warning is more dangerous because the shell command may run repeatedly over long periods, potentially causing persistent unintended actions or amplification of damage. The skill context increases risk because a monitor is expected to run unattended, so unsafe notification behavior can be overlooked after initial setup.
This markdown file shows repeated examples that fetch remote web pages and send notifications via Telegram, Slack webhooks, and email, but it does not include any warning that these actions transmit data to third-party services or generate external network traffic. Under the markdown-specific warning criterion, skills that may affect privacy or system/network behavior should disclose that behavior.