Back to skill

Security audit

Healthcheck Ready

Security checks for vulnerabilities and agentic risk

Overview

This is a small local health-check skill with some overbroad or imprecise reporting, but no evidence of deception, exfiltration, persistence, or destructive behavior.

Use this as a lightweight local status snapshot only. Do not treat it as proof that OpenClaw is patched or hardened, and avoid sharing its output where process names, usernames, or service presence would be sensitive.

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)

other

Note
Location
checks.sh:37
Finding

Unnecessary Disclosure of Host Process and Service Information

Content
View full analysis

Vulnerability Details

File Location: checks.sh, lines 37–48
Vulnerability Type: Host information exposure through broad process enumeration
Risk Level: Low

Technical Analysis

The script enumerates processes visible across the host and prints usernames, executable names, CPU usage, and memory usage:

bash
echo "=== Top 5 Processes by CPU ==="
ps aux --sort=-%cpu | head -6 | awk '{printf "%-10s %5s%% CPU  %5s%% MEM  %s\n", $1, $3, $4, $11}'
echo ""

echo "=== Key Services ==="
if pgrep -f "sshd" > /dev/null; then
  echo "sshd: ✅ running"
else
  echo "sshd: ❌ not running or not found"
fi

ps aux reports processes from all users visible to the invoking account. The resulting output can expose local account names, active applications, and workload characteristics to the caller or to systems that collect the health-check output.

The use of pgrep -f also searches complete process command lines rather than verifying the identity of a managed service. An unrelated process whose command line contains sshd, cron, or openclaw-gateway can therefore cause a false-positive status.

This behavior does not itself bypass access controls or transmit data externally. The risk arises when untrusted users can invoke the script or access its output.

Attack Path

  1. An untrusted or insufficiently privileged user invokes the health-check script or obtains its captured output.
  2. The script executes ps aux and discloses visible usernames, executable names, and resource usage.
  3. The script reports whether security-relevant service names appear in process command lines.
  4. The user applies the disclosed information to host reconnaissance and identifies accounts, software, or services for subsequent targeting.

No direct privilege escalation or code execution is established by this issue.

Impact Assessment

The issue can disclose host-level operational metadata, including local userna ...[truncated 325 chars]

Remediation
View remediation

Remediation Suggestions

  • Remove the top-process listing from the default health report.
  • If process details are operationally necessary, require explicit authorization and restrict output to approved processes without exposing usernames.
  • Return aggregate CPU and memory metrics instead of process-level data.
  • Replace broad command-line matching with service-manager checks, such as systemctl is-active --quiet sshd, where supported.
  • If pgrep must be used, use exact process-name matching such as pgrep -x and validate the expected executable identity.
  • Restrict access to generated reports and avoid forwarding them to logs or monitoring systems accessible by untrusted users.

T09 · Insecure Skill Coding Practices

Note
Location
checks.sh:10
Finding

Hardcoded Disk Capacity Produces Misleading Health Information

Content
View full analysis

Vulnerability Details

File Location: checks.sh, line 10
Vulnerability Type: Hardcoded and inaccurate system-status data
Risk Level: Low

Technical Analysis

The displayed disk capacity is hardcoded rather than obtained from the host:

bash
echo "Used: ${DISK_USAGE}% / 468G"

Although DISK_USAGE is dynamically read from df, the reported total capacity is always 468G. On systems with a different root-filesystem capacity, the health report is inaccurate. This can undermine monitoring reliability and create false confidence in the reported host posture.

This is a correctness and insecure coding issue rather than a direct code-execution vulnerability.

Attack Path

  1. An operator runs the script on a system whose root filesystem is not 468 GB.
  2. The script correctly calculates the utilization percentage but reports the fixed capacity 468G.
  3. The operator or an automated consumer relies on the inaccurate output when assessing storage posture.
  4. Monitoring, capacity planning, or incident-response decisions may consequently be based on incorrect information.

There is no direct path to privilege escalation or arbitrary code execution.

Impact Assessment

The issue does not grant privileges or unauthorized system access. Its impact is limited to the integrity and reliability of health-check output. Inaccurate capacity information can cause incorrect operational conclusions, particularly if the report is treated as an authoritative readiness check.

Remediation
View remediation

Remediation Suggestions

  • Read both utilization and total capacity from the same df invocation.

  • Use a stable machine-readable format, for example:

    bash
    read -r DISK_TOTAL DISK_USAGE < <(df -P -h / | awk 'NR==2 {gsub(/%/, "", $5); print $2, $5}')
    printf 'Used: %s%% / %s\n' "$DISK_USAGE" "$DISK_TOTAL"
    
  • Validate that parsed values are nonempty and numeric before arithmetic comparison.

  • Fail safely with an explicit “unknown” status if df fails or returns unexpected output.

  • Add tests covering different filesystem capacities and malformed command output.

T09 · Insecure Skill Coding Practices

Note
Location
SKILL.md:5
Finding

Documented Security Assurance Exceeds Implemented Checks

Content
View full analysis

Vulnerability Details

File Location: SKILL.md, lines 5–7
Vulnerability Type: Misleading security posture claim
Risk Level: Low

Technical Analysis

The usage documentation states:

markdown
Usage:
- Run to confirm OpenClaw is up-to-date and hardened.
- Returns: concise health status snapshot.

The implementation does not inspect an OpenClaw version, compare it against an approved release, or validate any hardening configuration. It only performs a substring-based process check:

bash
if pgrep -f "openclaw-gateway" > /dev/null; then
  echo "openclaw: ✅ running"
else
  echo "openclaw: ❌ not running or not found"
fi

Process presence cannot establish that software is current or hardened. Moreover, pgrep -f can match an unrelated command line containing the same text. The documentation can therefore cause users to interpret a limited availability check as a security validation.

Attack Path

  1. OpenClaw is running with an outdated version or insecure configuration.
  2. The operator invokes the Skill based on its claim that it confirms OpenClaw is current and hardened.
  3. A process command line containing openclaw-gateway is found.
  4. The script reports that OpenClaw is running without testing version or security configuration.
  5. The operator treats the result as evidence of patch and hardening status, allowing the actual weakness to remain undetected.

Impact Assessment

No privileges are directly obtained through this issue. The security impact is false assurance: outdated software or insecure configuration may remain unidentified because the documented scope is broader than the implemented validation. The practical scope depends on whether operators use this Skill as an authoritative security-readiness control.

Remediation
View remediation

Remediation Suggestions

  • Revise the documentation to state that the script checks resource utilization and apparent process presence only.
  • Alternatively, implement explicit OpenClaw version detection and compare it against a trusted, locally configured minimum or approved version.
  • Validate hardening controls individually, using documented configuration paths and secure expected values.
  • Report version, configuration, and process status as separate results rather than presenting process presence as evidence of security posture.
  • Replace substring process matching with an exact service or executable identity check.
  • Return an “unknown” or “not assessed” status for controls that the script cannot verify.
Vulnerability Patterns
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep

Static analysis

No suspicious patterns detected.