vmware-monitor

• Outcome: Pass
• Latest audit: Sep 12, 2026 · 12:25 AM UTC
• Version: 1.11.3

Overview

This is a coherent read-only VMware monitoring skill, with clearly disclosed credential, local logging, optional daemon, and webhook behavior.

Install only if you are comfortable giving the tool access to VMware inventory, alarms, events, logs, and session data. Use a dedicated least-privilege account, prefer a secret manager over storing passwords in .env, avoid granting Sessions.TerminateSession or Global.Diagnostics unless those specific reads are required, and configure webhooks only to destinations approved to receive infrastructure details.

A.I.G

Vulnerability Patterns

• Unauthorized Access and Privilege Escalation: Obtains permissions beyond the task's legitimate needs
• Insecure Dependencies: Introduces malicious components through unsafe dependency sources
• Insecure Skill Coding Practices: Finds exploitable flaws such as hardcoded secrets or command injection
• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions

Findings (3)

T08 · Insecure Dependencies

Warning

• Location: references/setup-guide.md:3
• Finding: Executable Package Is Installed from External Registries Without Artifact Integrity Verification< (MIT licensed). We recommend reviewing the source code before installing. ```bash # Via PyPI (recommended for version pinning) uv tool install vmware-monitor==1.11.3 # Via Skills.sh (fetches from GitHub) npx skills add vmware-skills/VMware-Monitor#v1.11.3 # Via ClawHub (fetches from ClawHub registry snapshot of GitHub) clawhub install @zw008/vmware-monitor --version 1.11.3 ``` ``` Related installer metadata appears in `SKILL.md`, lines 11–13: ```yaml installer: kind: uv package: vmware-monitor ``` ### Technical Analysis The audited bundle contains documentation and metadata but does not include the executable source of the `vmware-monitor` package or its claimed read-only enforcement test. It directs the agent to obtain and execute package content from PyPI, GitHub through Skills.sh, or a ClawHub registry snapshot. Pinning the version to `1.11.3` prevents ordinary version drift, but it does not establish artifact integrity. The instructions provide no cryptographic hash, signature, signed provenance record, or locked dependency set. Consequently, the claim that all installation methods correspond to the reviewed GitHub source cannot be verified from this bundle. The ClawHub package namespace, `@zw008/vmware-monitor`, also differs from the linked GitHub organization, increasing the need for explicit provenance verification. Because the Skill permits Bash and the installed program processes VMware credentials, compromise of a registry account, build pipeline, published wheel, transitive dependency, or registry snapshot could introduce code that is absent from this review. ### At ...[truncated 1314 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Include the executable package source, dependency manifest, and read-only enforcement tests in the audited bundle. 2. Publish SHA-256 or stronger hashes for all permitted package artifacts and require hash verification during installation. 3. Sign release artifacts and publish verifiable build provenance, such as Sigstore attestations or an equivalent signed supply-chain record. 4. Lock all direct and transitive dependencies to reviewed versions and hashes. 5. Use a single authoritative distribution channel or document how each registry artifact can be cryptographically mapped to the reviewed source commit. 6. Verify ownership and provenance of the differing ClawHub namespace before recommending it. 7. Run the installed package in a constrained environment with minimal filesystem access, restricted environment variables, and network egress limited to approved VMware targets and explicitly configured webhook destinations. ]]>

T05 · Unauthorized Access and Privilege Escalation

Warning

• Location: references/setup-guide.md:184
• Finding: Optional Session Monitoring Requires a Session-Termination Privilege<![CDATA[ ## Vulnerability Details **File Location**: `references/setup-guide.md`, line 184 **Vulnerability Type**: Excessive privilege required for a nominally read-only feature **Risk Level**: Medium ### Vulnerable Code Snippet ```markdown - **Least Privilege**: Give the skill a dedicated vCenter service account holding the built-in **Read-Only** role (propagated from the inventory root), not an administrator. That role has no privilege to change anything, so the read-only claim no longer rests on this code. Two reads need more than it grants: `active_sessions` reads the session list, which vCenter gates on `Sessions.TerminateSession` (a privilege that also allows ending sessions — without it the tool returns a one-row explanation instead); and ESXi host-log reads (`host_log_scan` and the daemon's host-log pass) call `BrowseDiagnosticLog`, gated on `Global.Diagnostics`. Grant those only if you need those reads. ``` The affected capability is listed in `SKILL.md`, line 188: ```markdown | `active_sessions` | Currently authenticated vCenter/ESXi sessions (who is logged in) | ``` ### Technical Analysis The Skill is presented as read-only, but the optional `active_sessions` query requires VMware's `Sessions.TerminateSession` privilege. That permission is not read-only: a credential holding it is authorized to end authenticated sessions. The executable may expose only a session-listing operation, but least privilege must be assessed against the authority granted to the credential, not only the methods currently exposed by the package. If the credential is stolen, reused by another companion tool, or accessed through a compromised dependency, the broader session-termination capability becomes available. The documentation correctly discloses the conflict and advises granting the privilege only when necessary. Nevertheless, enabling the advertised feature exceeds the minimum permissions required for the Skill's core inventory, alarm, event, health, and performa ...[truncated 1193 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Keep `active_sessions` disabled by default and mark it as requiring write-capable authority wherever the tool is listed. 2. Do not grant `Sessions.TerminateSession` to the primary monitoring account used for ordinary inventory and health queries. 3. If session visibility is essential, use a separate account and credential dedicated to that feature, with narrowly controlled availability and auditing. 4. Request or adopt a VMware API or permission model that permits session enumeration without granting termination authority, if available. 5. Prevent companion write-capable tools from automatically reusing the session-monitoring identity. 6. Alert when the configured account holds privileges beyond the built-in Read-Only role. 7. Document that compromise of this optional credential may permit session termination even though the Skill exposes no corresponding write tool. ]]>

T09 · Insecure Skill Coding Practices

Note

• Location: references/setup-guide.md:164
• Finding: VMware Passwords Are Stored Using Reversible Base64 Obfuscation<![CDATA[ ## Vulnerability Details **File Location**: `references/setup-guide.md`, lines 164–177 **Vulnerability Type**: Reversible storage of reusable credentials **Risk Level**: Low ### Vulnerable Code Snippet ```markdown ### Password obfuscation at rest On first load, any plaintext `*_PASSWORD` value in `.env` is automatically rewritten to a grep-safe `b64:<encoded>` form and decoded transparently at runtime, so a casual `grep` of the file no longer reveals the password. Values are read and written through python-dotenv's own parser, so the stored secret never drifts from what you configured (quotes, inline comments, and trailing whitespace are handled correctly). > **This is obfuscation, not encryption.** Anyone who can read the file can > still decode it. For real secrecy at rest, do not store the password in `.env` > at all — inject it from a secret manager (HashiCorp Vault, CyberArk, AWS > Secrets Manager, or a Kubernetes Secret) into the `*_PASSWORD` environment > variable at process start. The code reads the env var either way. ``` Related behavior is summarized in `SKILL.md`, lines 271–275: ```markdown vmware-monitor init # guided: prompts for host/user/password, writes config + .env (chmod 600), then verifies ``` ```markdown `init` stores the password grep-safe (obfuscated `b64:`, never plaintext) and locks `.env` to 0600. ``` ### Technical Analysis Base64 encoding is reversible and provides no cryptographic confidentiality. Any process or user capable of reading `~/.vmware-monitor/.env` can recover the password without a key. File mode `0600` is an important access-control measure, but it protects the file only while the owning account and processes running as that account remain trustworthy. The documentation explicitly and correctly states that this is obfuscation rather than encryption. However, automatically rewriting plaintext credentials into `b64:` form can still create an impression of protection while retaining a reusable secr ...[truncated 1161 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Make secret-manager or operating-system keychain integration the default credential-storage method. 2. Treat `.env` storage as a clearly labeled compatibility fallback rather than the recommended setup. 3. Do not describe Base64 as password protection; consistently label it as display obfuscation with no confidentiality benefit. 4. Enforce file ownership and mode `0600`, fail closed when permissions are broader, and reject symlinked credential files. 5. Avoid unnecessary in-place rewriting of credential files and use atomic replacement with secure temporary-file handling if migration is required. 6. Use separate, minimally privileged service accounts for different optional capabilities. 7. Rotate credentials after any suspected local-user or dependency compromise and audit VMware authentication events for unauthorized use. ]]>

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep
• Tool Misuse: Tool Parameter Abuse, Chaining Abuse, Unsafe Defaults
• Rogue Agent: Self-Modification, Session Persistence

Findings (42)

Credential Access

High

• Category: Privilege Escalation

Content

metadata: {"openclaw":{"requires":{"anyBins":["vmware-monitor","uvx"]},"optional":{"env":["VMWARE_MONITOR_CONFIG","VMWARE_TARGET_PASSWORD","VMWARE_<TARGET>_USERNAME","SLACK_WEBHOOK_URL","DISCORD_WEBHOOK_URL","VMWARE_AUDIT_APPROVED_BY"],"bins":["vmware-policy"]},"homepage":"https://github.com/vmware-skills/VMware-Monitor","emoji":"📊","os":["macos","linux"]}}
compatibility: >
  vmware-policy auto-installed as Python dependency (provides @vmware_tool decorator and audit logging). MCP tool calls audited to ~/.vmware/audit.db, CLI commands to ~/.vmware-monitor/audit.log.
  Credentials: Each vCenter/ESXi target requires a per-target password env var in ~/.vmware-monitor/.env following the pattern VMWARE_<TARGET_NAME_UPPER>_PASSWORD (e.g., target "vcenter-prod" → VMWARE_VCENTER_PROD_PASSWORD). SLACK_WEBHOOK_URL and DISCORD_WEBHOOK_URL are optional — disabled by default, user-configured only, used solely by the opt-in daemon scanner. Daemon: the background scanner (vmware-monitor daemon start) is user-initiated only, never auto-started. Webhook payloads carry issue counts plus every critical issue and every alarm/event warning (host-log warnings and info rows are not sent): entity name and the sanitized, truncated alarm, vCenter event, or ESXi log text, or a connection error — which can include host names, IPs, and user names. No credentials from the skill's config are sent.
---

# VMware Monitor (Read-Only)

• Confidence: 86% confidence
• Finding: The skill explicitly stores VMware credentials in a local ~/.vmware-monitor/.env file and acknowledges optional webhook transmission of operational data. Even though it states credentials are not sent and files are permission-restricted, local plaintext-equivalent secret storage and environment-based handling increase exposure to local compromise, accidental backup leakage, or process/environment disclosure.

Credential Access

High

• Category: Privilege Escalation

Content

```bash
uv tool install vmware-monitor==1.11.3
vmware-monitor init      # guided: prompts for host/user/password, writes config + .env (chmod 600), then verifies
```

`init` stores the password grep-safe (obfuscated `b64:`, never plaintext) and

• Confidence: 83% confidence
• Finding: The setup flow writes configuration and a .env file containing authentication material to disk. The text says passwords are rewritten as b64, which is obfuscation rather than encryption, so compromise of the local account or filesystem would expose usable credentials.

Tool Parameter Abuse

High

• Category: Tool Misuse

Content

## Diagnostics

```bash
vmware-monitor doctor [--skip-auth]
```

Checks config file, connectivity, authentication, and pyVmomi version. Use `--skip-auth` to test config parsing without connecting.

• Confidence: 70% confidence
• Finding: Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).

Tool Parameter Abuse

High

• Category: Tool Misuse

Content

## Diagnostics

```bash
vmware-monitor doctor [--skip-auth]
```

Checks config file, connectivity, authentication, and pyVmomi version. Use `--skip-auth` to test config parsing without connecting.

• Confidence: 70% confidence
• Finding: Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).

Tool Parameter Abuse

High

• Category: Tool Misuse

Content

## Diagnostics

```bash
vmware-monitor doctor [--skip-auth]
```

Checks config file, connectivity, authentication, and pyVmomi version. Use `--skip-auth` to test config parsing without connecting.

• Confidence: 70% confidence
• Finding: Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).

Credential Access

High

• Category: Privilege Escalation

Content

```bash
mkdir -p ~/.vmware-monitor
cp config.example.yaml ~/.vmware-monitor/config.yaml
cp .env.example ~/.vmware-monitor/.env
chmod 600 ~/.vmware-monitor/.env
```

• Confidence: 60% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Credential Access

High

• Category: Privilege Escalation

Content

```bash
mkdir -p ~/.vmware-monitor
cp config.example.yaml ~/.vmware-monitor/config.yaml
cp .env.example ~/.vmware-monitor/.env
chmod 600 ~/.vmware-monitor/.env
```

• Confidence: 60% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Credential Access

High

• Category: Privilege Escalation

Content

# 3. Configure
mkdir -p ~/.vmware-monitor
cp config.example.yaml ~/.vmware-monitor/config.yaml
cp .env.example ~/.vmware-monitor/.env
chmod 600 ~/.vmware-monitor/.env
# Edit ~/.vmware-monitor/config.yaml and .env with your target details
```

• Confidence: 90% confidence
• Finding: The guide instructs users to create and populate a local `.env` file with vCenter passwords. Even though it recommends `chmod 600` and later clarifies that `b64:` is only obfuscation, storing long-lived infrastructure credentials in a local file increases theft risk from local compromise, backups, accidental inclusion, or agent/tool exposure. In a VMware monitoring skill, these credentials grant authenticated access to sensitive infrastructure state, so compromise can expose broad operational data and potentially more if over-privileged accounts are used.

Credential Access

High

• Category: Privilege Escalation

Content

mkdir -p ~/.vmware-monitor
cp config.example.yaml ~/.vmware-monitor/config.yaml
cp .env.example ~/.vmware-monitor/.env
chmod 600 ~/.vmware-monitor/.env
# Edit ~/.vmware-monitor/config.yaml and .env with your target details
```

• Confidence: 90% confidence
• Finding: This line continues the workflow that creates `~/.vmware-monitor/.env`, explicitly housing secrets on disk. Local plaintext-or-recoverable secret storage is risky because any process or user with file access, backup access, or endpoint compromise can recover the credential. The skill context makes this more sensitive because the secrets unlock vCenter/ESXi visibility across potentially production environments.

Credential Access

High

• Category: Privilege Escalation

Content

cp config.example.yaml ~/.vmware-monitor/config.yaml
cp .env.example ~/.vmware-monitor/.env
chmod 600 ~/.vmware-monitor/.env
# Edit ~/.vmware-monitor/config.yaml and .env with your target details
```

### Declare `environment:` on each target

• Confidence: 89% confidence
• Finding: The instruction to edit `.env` with target details reinforces manual secret handling in a local file. That pattern is operationally common but still creates avoidable credential exposure channels, especially in agent-driven environments where local workspace files may be indexed, summarized, or copied. Because this skill targets VMware infrastructure, exposed credentials can reveal high-value inventory, alarms, host state, and event data.

Self-Modification

High

• Category: Rogue Agent

Content

`environment` is an optional label. This skill has zero write tools, so nothing
it exposes is ever gated by it — reads are never gated under any setting. It
matters for the write skills (`vmware-aiops`, `vmware-storage`, `vmware-nsx`)
pointed at the same vCenter: an environment-scoped `deny` rule in
`~/.vmware/rules.yaml` can match on the label to block their writes (e.g. freeze
`production`). A target with no label is simply not matched by such a rule.

• Confidence: 85% confidence
• Finding: 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.

Self-Modification

High

• Category: Rogue Agent

Content

`environment` is an optional label. This skill has zero write tools, so nothing
it exposes is ever gated by it — reads are never gated under any setting. It
matters for the write skills (`vmware-aiops`, `vmware-storage`, `vmware-nsx`)
pointed at the same vCenter: an environment-scoped `deny` rule in
`~/.vmware/rules.yaml` can match on the label to block their writes (e.g. freeze
`production`). A target with no label is simply not matched by such a rule.

• Confidence: 85% confidence
• Finding: 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.

Agent Config Directory Access

High

• Category: Agent Snooping

Content

## MCP Mode Configuration

For Claude Code / Cursor users who prefer structured tool calls, add to `~/.claude/settings.json`:

```json
{

• Confidence: 90% confidence
• Finding: Skill reads from agent configuration directories (.claude/, .codex/, .gemini/). These directories may contain API keys, personal settings, and other credentials that the skill has no legitimate need to access.

Session Persistence

Medium

• Category: Rogue Agent

Content

Use this skill for safe, read-only queries of VMware infrastructure — no destructive operations exist in the codebase; a test enforces it.
  Directly handles: a one-glance cross-cluster health summary, object-centered VM/host/datastore investigation drill-downs (correlating surrounding infrastructure + recent events), a cross-vCenter "what needs attention now?" rollup, list VMs/hosts/datastores/clusters, active alarms, recent events, VM details.
  Always use vmware-monitor when the user asks to "list VMs", "check vSphere alarms", "show host status", "is anything on fire", "what needs attention now", "what is happening around this VM/host/datastore", "investigate this VM" — or needs read-only VMware info before making changes.
  Do NOT use for any write operations — this skill is read-only and has no code path that creates, modifies, or deletes a vSphere resource.
  For VM modifications use vmware-aiops, for networking use vmware-nsx, for metrics/capacity use vmware-aria. For load balancing/AVI/AKO use vmware-avi.
installer:
  kind: uv

• Confidence: 60% confidence
• Finding: 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.

Session Persistence

Medium

• Category: Rogue Agent

Content

### Should I set `environment:` on a read-only skill?
You can — add `environment: production` (or `staging`, `lab`, your own label)
to each target in `~/.vmware-monitor/config.yaml`. It's an optional label; this
skill has zero write tools, so nothing it exposes is ever gated by it — reads
are never gated. It matters for the write skills (`vmware-aiops`,
`vmware-storage`, `vmware-nsx`) pointed at the same vCenter: an
environment-scoped `deny` rule in `~/.vmware/rules.yaml` can match on the label

• Confidence: 60% confidence
• Finding: 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.

Autonomous Decision Making

Medium

• Category: Excessive Agency

Content

| **L5** | Auto-remediation from learned pattern | *N/A* | — *(remediation is out of scope by design)* |

**Notes**:
- No tool changes vCenter/ESXi state, so agents can call them without confirmation — gated by [`tests/eval/regression/test_read_only_enforcement.py`](https://github.com/vmware-skills/VMware-Monitor/blob/main/tests/eval/regression/test_read_only_enforcement.py) (source repository; a check on the code as written, run by the test suite — there is no CI). Results still carry sensitive inventory, event, log, and session data: scope the account as in `setup-guide.md` → Least Privilege.
- Local files the skill writes (config, `.env`, audit logs, HTML snapshots, daemon state) are listed in `setup-guide.md` → What "read-only" covers.

## 0. Cluster Health Summary (triage)

• Confidence: 75% confidence
• Finding: Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.

Unsafe Defaults

Medium

• Category: Tool Misuse

Content

## Diagnostics

```bash
vmware-monitor doctor [--skip-auth]
```

Checks config file, connectivity, authentication, and pyVmomi version. Use `--skip-auth` to test config parsing without connecting.

• Confidence: 80% confidence
• Finding: Tool defaults are unsafe or overly permissive (e.g. disabled TLS verification, no authentication, world-writable permissions). Unsafe defaults widen the attack surface.

Unsafe Defaults

Medium

• Category: Tool Misuse

Content

## Diagnostics

```bash
vmware-monitor doctor [--skip-auth]
```

Checks config file, connectivity, authentication, and pyVmomi version. Use `--skip-auth` to test config parsing without connecting.

• Confidence: 80% confidence
• Finding: Tool defaults are unsafe or overly permissive (e.g. disabled TLS verification, no authentication, world-writable permissions). Unsafe defaults widen the attack surface.

Unsafe Defaults

Medium

• Category: Tool Misuse

Content

## Diagnostics

```bash
vmware-monitor doctor [--skip-auth]
```

Checks config file, connectivity, authentication, and pyVmomi version. Use `--skip-auth` to test config parsing without connecting.

• Confidence: 80% confidence
• Finding: Tool defaults are unsafe or overly permissive (e.g. disabled TLS verification, no authentication, world-writable permissions). Unsafe defaults widen the attack surface.

Description-Behavior Mismatch

Medium

• Confidence: 89% confidence
• Finding: The CLI reference documents `scan now`, `daemon start/stop/status`, and host-log scanning, which materially expands behavior beyond the stated read-only, direct-query skill description. Even if these actions are not destructive to VMware resources, they introduce persistent background execution and broader data collection that an agent or user may invoke without understanding the extra operational footprint.

Session Persistence

Medium

• Category: Rogue Agent

Content

## Setup

```bash
mkdir -p ~/.vmware-monitor
cp config.example.yaml ~/.vmware-monitor/config.yaml
cp .env.example ~/.vmware-monitor/.env
chmod 600 ~/.vmware-monitor/.env

• Confidence: 60% confidence
• Finding: 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.

Rp1

Medium

• Category: MCP Rug Pull
• Confidence: 70% confidence
• Finding: npx commands without a version suffix (e.g. @1.0.0) create a rug-pull risk if the upstream server is compromised and publishes a malicious update.

Rp1

Medium

• Category: MCP Rug Pull
• Confidence: 70% confidence
• Finding: npx commands without a version suffix (e.g. @1.0.0) create a rug-pull risk if the upstream server is compromised and publishes a malicious update.

Skill Enumeration

Medium

• Category: Agent Snooping

Content

directory. To install it manually from a clone:

```bash
mkdir -p ~/.claude/skills/vmware-monitor
cp -r skills/vmware-monitor/. ~/.claude/skills/vmware-monitor/
```

• Confidence: 85% confidence
• Finding: Skill enumerates or reads other installed skills. Access to other skills' SKILL.md files or the skills directory reveals prompt instructions, capabilities, and secrets that should be invisible to peer skills.

Session Persistence

Medium

• Category: Rogue Agent

Content

directory. To install it manually from a clone:

```bash
mkdir -p ~/.claude/skills/vmware-monitor
cp -r skills/vmware-monitor/. ~/.claude/skills/vmware-monitor/
```

• Confidence: 60% confidence
• Finding: 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.

Static analysis

No suspicious patterns detected.