T05 · Unauthorized Access and Privilege Escalation
- Location
scripts/vaibot-guard-service.mjs:81- Finding
Path Traversal Through Client-Controlled Identifiers
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This is a coherent local guard skill, but it needs Review because its security-sensitive service can fail open, persist as a background service, mishandle local paths and redaction, and upload operational receipts when API settings are enabled.
Install only after reviewing the service configuration. Keep it bound to 127.0.0.1, require a strong VAIBOT_GUARD_TOKEN, avoid HTTP or untrusted VAIBOT_API_URL values, treat logs as sensitive, and prefer foreground/manual operation until the path validation, redaction, and high-risk tool default-allow issues are fixed.
scripts/vaibot-guard-service.mjs:81Path Traversal Through Client-Controlled Identifiers
scripts/vaibot-guard-service.mjs:19Protected Guard Endpoints Fail Open When No Token Is Configured
scripts/vaibot-guard-service.mjs:517High-Risk Execution Tools Can Fall Through to an Allow Decision
scripts/vaibot-guard-service.mjs:992Default Redaction Rules Are Invalid and Sensitive Fields Are Not Recursively Sanitized
scripts/vaibot-guard-service.mjs:685Configurable Receipt Destination Permits Plaintext Transmission of API Credentials and Operational Telemetry
scripts/vaibot-guard.mjs:239Optional Installer Creates a Cross-Session systemd Service
scripts/vaibot-guard-exec.mjs:45Standalone Execution Wrapper Omits Authentication and Sends an Incompatible Request Schema
Referenced artifact was not completely inspected
node scripts/vaibot-guard-service.mjs
Referenced artifact was not completely inspected
node scripts/vaibot-guard.mjs install-local
Skill modifies its own code, configuration, or behavior at runtime. Self-modification enables an agent to escalate privileges, disable safety constraints, or install persistent backdoors.
## Shared environment variables
Retention:
- `VAIBOT_LOG_RETENTION_DAYS` (default 14): remove guard log/state files in `VAIBOT_GUARD_LOG_DIR` older than this many days.
Common env vars (see `SKILL.md` for full list):
- `VAIBOT_GUARD_HOST` (default `127.0.0.1`)
The file downplays the skill as only a distribution and UX surface, but the skill metadata describes operational capabilities including running the guard service, managing approvals, and validating receipts or audit logs. This mismatch can mislead reviewers, operators, or marketplace consumers about the effective trust boundary and authority of the skill, causing under-review of privileged behavior and unsafe deployment decisions.
The skill describes capabilities that require environment-variable access and shell execution, but it does not declare any explicit tool scope such as permissions or allowed-tools. That creates an authorization gap: an agent or runtime may expose more capability than reviewers expect, making it easier for the skill to start services, modify user configuration, or invoke local commands without clear boundary declarations.
The skill explicitly instructs writing tamper-evident audit logs under a persistent local directory and also references sensitive credentials used by the guard service. Persistent logging is not inherently malicious, but in this context it can retain sensitive operational data, approval decisions, command metadata, or tokens if implementations are careless, increasing the blast radius of local compromise or accidental disclosure.
# OpenClaw Guard Skill (VAIBot v2.1)
Provide a **local policy decision service** plus a CLI to gate OpenClaw tool calls and write **tamper-evident audit logs** in `.vaibot-guard/`.
## Sensitive credentials
- `VAIBOT_GUARD_TOKEN` — bearer token for Guard endpoints (recommended)
Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.
Two options are provided:
- **Local workstation mode (recommended):** user service (`systemctl --user`)
- **VPS / production mode:** system service (`sudo systemctl`) — **templates are not shipped in the ClawHub skill artifact**; generate/copy your own unit file (see notes below).
## Shared environment variables
systemctl --user enable --now vaibot-guard creates user-level persistence by both starting the service and enabling it for future sessions. In a skill context, persistence is more sensitive because users may execute setup steps without fully understanding they are installing a background service tied to their account.
systemctl --user daemon-reload
systemctl --user enable --now vaibot-guard
systemctl --user status vaibot-guard
Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.
Notes:
- The installer writes:
- `~/.config/systemd/user/vaibot-guard.service`
- `~/.config/vaibot-guard/vaibot-guard.env` (recommended `chmod 600`)
- Systemd templates are provided under `references/systemd/` for reference; do not assume `.service` files ship in the ClawHub artifact.
### Logs
Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.
Notes:
- The installer writes:
- `~/.config/systemd/user/vaibot-guard.service`
- `~/.config/vaibot-guard/vaibot-guard.env` (recommended `chmod 600`)
- Systemd templates are provided under `references/systemd/` for reference; do not assume `.service` files ship in the ClawHub artifact.
### Logs
Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.
Notes:
- The installer writes:
- `~/.config/systemd/user/vaibot-guard.service`
- `~/.config/vaibot-guard/vaibot-guard.env` (recommended `chmod 600`)
- Systemd templates are provided under `references/systemd/` for reference; do not assume `.service` files ship in the ClawHub artifact.
### Logs
Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.
sudo useradd --system --create-home --home-dir /var/lib/vaibot-guard --shell /usr/sbin/nologin vaibot-guard
/etc/vaibot-guard/vaibot-guard.env and set required env vars (at minimum VAIBOT_GUARD_TOKEN, VAIBOT_POLICY_PATH, VAIBOT_GUARD_LOG_DIR).Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.
sudo useradd --system --create-home --home-dir /var/lib/vaibot-guard --shell /usr/sbin/nologin vaibot-guard
/etc/vaibot-guard/vaibot-guard.env and set required env vars (at minimum VAIBOT_GUARD_TOKEN, VAIBOT_POLICY_PATH, VAIBOT_GUARD_LOG_DIR).Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.
sudo useradd --system --create-home --home-dir /var/lib/vaibot-guard --shell /usr/sbin/nologin vaibot-guard
/etc/vaibot-guard/vaibot-guard.env and set required env vars (at minimum VAIBOT_GUARD_TOKEN, VAIBOT_POLICY_PATH, VAIBOT_GUARD_LOG_DIR).Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.
sudo useradd --system --create-home --home-dir /var/lib/vaibot-guard --shell /usr/sbin/nologin vaibot-guard
/etc/vaibot-guard/vaibot-guard.env and set required env vars (at minimum VAIBOT_GUARD_TOKEN, VAIBOT_POLICY_PATH, VAIBOT_GUARD_LOG_DIR).sudo systemctl enable --now vaibot-guard establishes persistence by starting the service immediately and enabling it on boot. While legitimate for service installation, this creates durable execution, which is security-relevant in a skill artifact because it can outlive the invoking session if the service or its configuration is later compromised.
sudo systemctl daemon-reload
sudo systemctl enable --now vaibot-guard
sudo systemctl status vaibot-guard
This command enables system-wide boot persistence for the guard service, causing it to run automatically across reboots under systemd. In the context of a skill artifact, system-level persistence is materially more dangerous than ordinary documentation because it can institutionalize long-lived execution on a host if the service, policy, or environment file is misconfigured or later abused.
sudo systemctl daemon-reload
sudo systemctl enable --now vaibot-guard
sudo systemctl status vaibot-guard
The service is described as a local guard, but it is explicitly configured to send proof receipts and audit-derived data to remote VAIBot endpoints when VAIBOT_API_URL and VAIBOT_API_KEY are set. Even with some redaction, this can transmit execution intent, commands, paths, results, and session metadata off-host, creating a confidentiality and trust-boundary issue if operators expect strictly local processing.
If ALLOWLISTED_DOMAINS is empty, isDomainAllowlisted returns true for any destination, effectively disabling outbound network restrictions. In a guard service that is supposed to enforce tool decisions and constrain risky actions, this fail-open behavior can allow arbitrary egress, remote fetches, and data exfiltration without the intended approval barrier.
function isDomainAllowlisted(dest) {
// Tight allowlist semantics:
// - If allowlist is empty: allow all (legacy behavior).
// - Exact host match is allowed.
// - Subdomains are ONLY allowed when the allowlist entry is explicitly wildcarded as "*.example.com".
if (ALLOWLISTED_DOMAINS.length === 0) return true;
The proof submission path sends receipt contents, including redacted intent and audit data, to a remote /prove service using a bearer token. Because this occurs automatically and the service is framed as local policy enforcement, it creates a meaningful risk of unintended disclosure of sensitive operational context.
The governance receipt uploader sends structured execution metadata to an external API using a bearer credential, which expands the system from a local guard into a telemetry/reporting component. If enabled without strong operator awareness, it can leak sensitive command summaries, cwd values, policy decisions, and session identifiers to a third party.
This code performs credential-backed network transmission to a remote receipts API using VAIBOT_API_KEY, but there is no user-facing disclosure at the point of use that execution metadata will be uploaded. Silent background exfiltration of operational metadata is risky in a guard service because users may assume decisions and logs remain local.
Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.
if (tok.created) {
console.error(`Generated VAIBOT_GUARD_TOKEN and wrote ${envFile} (chmod 600).`);
// If systemd user unit appears installed, offer to restart it so the running service picks up the new token.
const userUnitPath = path.join(os.homedir(), ".config", "systemd", "user", "vaibot-guard.service");
const hasUnit = fs.existsSync(userUnitPath);
Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.
if (tok.created) {
console.error(`Generated VAIBOT_GUARD_TOKEN and wrote ${envFile} (chmod 600).`);
// If systemd user unit appears installed, offer to restart it so the running service picks up the new token.
const userUnitPath = path.join(os.homedir(), ".config", "systemd", "user", "vaibot-guard.service");
const hasUnit = fs.existsSync(userUnitPath);
This code offers to enable and start a systemd user service, which creates persistence across user sessions. Although it is gated by an interactive prompt and consistent with the skill's stated purpose, persistence mechanisms are security-sensitive because a compromised or misconfigured guard service would continue running automatically and could mediate future tool decisions.
// cmdConfigure exits on success; if it doesn't, continue.
}
const ans3 = (await rl.question("Enable + start vaibot-guard now (systemctl --user enable --now)? [y/N]: ")).trim().toLowerCase();
if (ans3 === "y" || ans3 === "yes") {
const { execSync } = await import("node:child_process");
execSync("systemctl --user daemon-reload", { stdio: "inherit" });
Detected: suspicious.dangerous_exec, suspicious.env_credential_access, suspicious.exposed_secret_literal