Back to skill

Security audit

Bud Health Monitor

Security checks for vulnerabilities and agentic risk

Overview

This health monitor needs review because its fix mode can kill processes and alter kernel cache behavior without strong user controls.

Use status or json mode only if you want passive monitoring. Do not enable fix mode or the cron auto-fix example as written, especially as root, unless you first add explicit confirmation, a dry run, allowlisted targets, corrected threshold logic, and clear logging.

Vulnerability Patterns
  • Insecure Skill Coding PracticesFinds exploitable flaws such as hardcoded secrets or command injection
  • Skill Instruction HijackingAlters the agent's session goals or safety constraints when the skill loads
  • Agent Memory PoisoningWrites attacker-controlled rules into memory that affect later sessions
  • Remote Payload Retrieval and ExecutionFetches external code whose behavior can change after review
  • Embedded Malicious CodeShips malicious scripts inside the skill and executes them locally
Findings (3)

T09 · Insecure Skill Coding Practices

Error
Location
health_monitor.py:156
Finding

Unsafe Broad Process Termination in Automatic RAM Remediation

Content
View full analysis
5: # Only kill processes using >5% RAM # Try graceful first os.kill(pid, 15) # SIGTERM time.sleep(1) try: os.kill(pid, 9) # SIGKILL except: pass killed.append(f"{proc['cmd'][:30]} (PID:{pid})") except: pass return killed ``` ### Technical Analysis The remediation function selects processes from the five highest RAM consumers and terminates every selected process using more than 5% of system memory unless its command text contains one of several protected substrings. The protection mechanism is not a reliable process-authorization control: - It relies on substring matching against command text rather than verified process identity. - It does not protect databases, application servers, monitoring agents, user sessions, or other essential services. - It does not verify process ownership, cgroup membership, service role, or parent-child relationships. - It does not require RAM usage to have reached the configured critical threshold. - It sends `SIGKILL` after a fixed one-second delay without first checking whether `SIGTERM` succeeded. - It obtains the PID from a prior process listing without revalidating process identity, creating a potential PID-reuse race. Consequen ...[truncated 1689 chars]
Remediation
View remediation

T09 · Insecure Skill Coding Practices

Error
Location
SKILL.md:88
Finding

Reversed Cron Threshold Causes Automatic Fixes Under Noncritical Memory Conditions

Content
View full analysis
90 else 0)" && python3 ~/.openclaw/health-monitor/health_monitor.py fix ``` ### Technical Analysis Shell `&&` executes the command on its right only when the command on its left exits with status zero. The embedded Python condition does the opposite of the documented intention: - RAM above 90% produces exit status `1`, so the fix is skipped. - RAM at or below 90% produces exit status `0`, so the fix is executed. The documentation therefore recommends an unattended cron job that invokes destructive process termination during normal or warning-level memory conditions while failing to invoke it during the stated critical condition. This defect directly amplifies the unsafe process-selection behavior in `kill_process_by_ram()`. ### Attack Path 1. An administrator copies the documented cron example. 2. Cron executes the pipeline every hour. 3. The monitor reports RAM usage at or below 90%. 4. The embedded Python expression exits with status zero. 5. Shell `&&` invokes `health_monitor.py fix`. 6. The fix operation terminates qualifying high-memory processes, even though the documented critical condition was not met. 7. On subsequent hourly runs, workloads may be terminated repeatedly. 8. If RAM usage exceeds 90%, the condition exits with status one and the intended emergency remediation is skipped. An attacker does not gain privileges through this condition. However, an attacker capable of influencing memory consumption or persuading an administrator to deploy the documented cron entry could increase the likelihood or timing of service disruption. ### Impact Assessment The cron example can conver ...[truncated 460 chars]
Remediation
View remediation
90 else 1)" && python3 ~/.openclaw/health-monitor/health_monitor.py fix ``` Additional hardening should include: - Implement the threshold check inside the `fix` command rather than relying solely on shell composition. - Require multiple consecutive critical readings to avoid acting on transient spikes. - Add a lock to prevent concurrent remediation instances. - Use a dry-run mode before enabling scheduled termination. - Require explicit configuration of processes or services eligible for remediation. - Log the measured threshold, decision, targets, and outcomes. - Test documented shell examples for both branches of every condition. - Avoid recommending root cron execution unless strictly necessary. ]]>

T09 · Insecure Skill Coding Practices

Warning
Location
health_monitor.py:274
Finding

Privilege Tool Check Does Not Mediate Destructive Operations

Content
View full analysis
Remediation
View remediation
Vulnerability Patterns
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
  • Trigger AbuseOverly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
  • Behavioral ASTexec() Call, eval() Call, Dynamic Import
  • MCP Least PrivilegeUnderdeclared Capability, Wildcard Permission, Missing Permission Declaration
  • MCP Tool PoisoningHidden Instructions, Unicode Deception, Parameter Description Injection
Findings (17)

Tp4

High
Category
MCP Tool Poisoning
Confidence
94% confidence
Finding

The skill markets itself as a health monitor, but the documented behavior includes destructive and system-modifying actions such as killing processes and writing to /proc/sys/vm/drop_caches. That mismatch is dangerous because users or calling agents may invoke it under the assumption of passive monitoring, when it can instead disrupt workloads or modify system state.

Content

No source excerpt is available for this finding.

Missing User Warnings

High
Category
Not specified by scanner
Confidence
96% confidence
Finding

The documentation describes terminating processes and dropping caches without an explicit warning about service interruption, data loss, workload corruption, or performance side effects. In the context of a Raspberry Pi or home server, these actions can break long-running services or kill user workloads unexpectedly.

Content

No source excerpt is available for this finding.

Missing User Warnings

High
Category
Not specified by scanner
Confidence
97% confidence
Finding

The skill explicitly recommends unattended scheduled execution of a destructive fix command, which can repeatedly kill processes or modify kernel memory behavior without human review. That is especially risky in an automation environment because transient spikes, parser errors, or misclassification of memory pressure could trigger harmful remediation loops.

Content

No source excerpt is available for this finding.

Missing User Warnings

High
Category
Not specified by scanner
Confidence
97% confidence
Finding

The skill description advertises auto-fixing system issues without disclosing that it may kill processes and alter kernel cache behavior. In the context of an agent skill, incomplete disclosure is dangerous because operators may invoke it expecting safe diagnostics while it performs disruptive actions that can interrupt services or lose data.

Content

No source excerpt is available for this finding.

Missing User Warnings

High
Category
Not specified by scanner
Confidence
99% confidence
Finding

The process-killing logic executes automatically once fix is invoked, using simplistic exclusions and a memory threshold to terminate processes without user review. This creates a high risk of self-inflicted denial of service, killing important applications, and data corruption from abrupt termination, especially on a system where the tool may run with elevated privileges.

Content

No source excerpt is available for this finding.

os.system() or os exec-family call

High
Category
Dangerous Code Execution
Confidence
85% confidence
Finding

os.system() and os exec-family calls run shell commands with the process's full privileges, enabling arbitrary command execution.

Content

Scanner excerpt · health_monitor.py (reported line 314)May include surrounding context.

python
elif cmd == "watch":
        print("👁️  Watching system health (Ctrl+C to stop)...")
        while True:
            os.system('clear')
            status = print_health_report()
            if status['alerts']:
                print("\n🔔 ALERT: Issues detected!")

Undeclared Tool Scope

Medium
Category
MCP Least Privilege
Confidence
70% confidence
Finding

Without declared permissions the skill's intent is opaque and cannot be validated.

Content

No source excerpt is available for this finding.

Vague Triggers

Medium
Category
Not specified by scanner
Confidence
93% confidence
Finding

Broad claims like auto-detect issues and attempt fixes lack clear boundaries on when remediation occurs and what actions are permitted. In an agent setting, ambiguous language increases the chance that higher-privileged orchestration will invoke the skill too freely or without informed user consent.

Content

No source excerpt is available for this finding.

subprocess module call

Medium
Category
Dangerous Code Execution
Confidence
70% confidence
Finding

subprocess module calls execute external commands. Without careful input validation, this enables command injection.

Content

Scanner excerpt · health_monitor.py (reported line 80)May include surrounding context.

python
def get_disk_usage(path='/'):
    """Get disk usage for path"""
    try:
        result = subprocess.run(['df', '-h', path], capture_output=True, text=True)
        lines = result.stdout.strip().split('\n')
        if len(lines) >= 2:
            parts = lines[1].split()

subprocess module call

Medium
Category
Dangerous Code Execution
Confidence
70% confidence
Finding

subprocess module calls execute external commands. Without careful input validation, this enables command injection.

Content

Scanner excerpt · health_monitor.py (reported line 98)May include surrounding context.

python
def get_cpu_usage():
    """Get CPU usage percentage"""
    try:
        result = subprocess.run(['top', '-bn1'], capture_output=True, text=True, timeout=5)
        for line in result.stdout.split('\n'):
            if '%Cpu(s):' in line or 'Cpu(s):' in line:
                parts = line.split()

subprocess module call

Medium
Category
Dangerous Code Execution
Confidence
70% confidence
Finding

subprocess module calls execute external commands. Without careful input validation, this enables command injection.

Content

Scanner excerpt · health_monitor.py (reported line 116)May include surrounding context.

python
def get_top_ram_processes():
    """Get top 5 processes by RAM usage"""
    try:
        result = subprocess.run(
            ['ps', 'aux', '--sort=-%mem'],
            capture_output=True, text=True, timeout=5
        )

Description-Behavior Mismatch

Medium
Category
Not specified by scanner
Confidence
98% confidence
Finding

The skill presents itself as a health monitor with auto-fix behavior, but its fix path includes terminating user processes based on crude heuristics and then force-killing them. In context, this is dangerous because a monitoring utility may be trusted and run with elevated privileges, causing denial of service, data loss, or termination of important workloads without informed consent.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium
Category
Not specified by scanner
Confidence
95% confidence
Finding

Writing to /proc/sys/vm/drop_caches changes kernel memory behavior and typically requires elevated privileges, yet the code does so silently as part of auto-fix. In this skill context, undisclosed privileged side effects are dangerous because they can degrade performance, surprise operators, and normalize running a monitoring tool with excessive privileges.

Content

No source excerpt is available for this finding.

subprocess module call

Medium
Category
Dangerous Code Execution
Confidence
70% confidence
Finding

subprocess module calls execute external commands. Without careful input validation, this enables command injection.

Content

Scanner excerpt · health_monitor.py (reported line 288)May include surrounding context.

python
# Clear cached memory
    try:
        subprocess.run(['sync'], capture_output=True)
        with open('/proc/sys/vm/drop_caches', 'w') as f:
            f.write('3\n')
        log_event("Dropped caches to free RAM")

Vague Triggers

Low
Category
Not specified by scanner
Confidence
84% confidence
Finding

The entry 'Any heavy workload — automated health management' is a vague scope statement that implies the skill may apply in many generic situations without clear boundaries. This increases the chance of unintended activation because it does not define when the skill should or should not be used.

Content

No source excerpt is available for this finding.

Description-Behavior Mismatch

Low
Category
Not specified by scanner
Confidence
98% confidence
Finding

The module docstring states that the skill monitors services and temperature, while the actual code only gathers RAM, disk, CPU, load, uptime, and process information. This creates a semantic mismatch between claimed monitoring coverage and implemented behavior.

Content

No source excerpt is available for this finding.

Intent-Code Divergence

Low
Category
Not specified by scanner
Confidence
97% confidence
Finding

The top-level docstring explicitly says the monitor covers services and temperature, but no code queries service managers, inspects service state, or reads thermal sensors. This is an active documentation-to-code contradiction rather than a minor omission.

Content

No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.