ClawHub
Back to skill

Security audit

monitoring-aiops

Security checks for vulnerabilities and agentic risk

Overview

The skill is transparent about its monitoring purpose, but it needs Review because it can change or delete monitoring state with stored credentials, has no enforced approval/read-only gate for MCP writes, and defaults SSL verification off.

Install only if you are comfortable granting an agent access to monitoring systems. Start with read-only SolarWinds/PRTG/Zabbix credentials, set verify_ssl true or configure a trusted CA for production, and require your own explicit approval process before any MCP write such as remove, unmanage, mute, pause, or maintenance deletion.

A.I.G

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 (2)

T09 · Insecure Skill Coding Practices

Error
Location
SKILL.md:27
Finding

TLS Certificate Verification Is Disabled by Default

Content
View full analysis

Vulnerability Details

File Location: SKILL.md:27
Vulnerability Type: Insecure TLS configuration
Risk Level: High

Vulnerable Snippet:

text
SSL: verify_ssl defaults to false-friendly for self-signed lab certs; enable for production.

Technical Analysis

The Skill documents that TLS certificate verification is disabled by default for connections to SolarWinds, PRTG, and Zabbix targets. These connections carry SolarWinds HTTP Basic credentials or PRTG/Zabbix API tokens and may issue privileged monitoring operations.

When certificate verification is disabled, TLS encryption does not authenticate the remote endpoint. An attacker capable of intercepting or redirecting network traffic can present an arbitrary certificate, impersonate the configured monitoring server, and observe or modify requests and responses.

The vulnerable behavior is triggered when a target does not explicitly enable verify_ssl and its traffic crosses a network an attacker can influence.

Attack Path

  1. The operator configures a monitoring target without explicitly setting verify_ssl: true.
  2. The Skill uses its documented default and accepts an unverified server certificate.
  3. A network-positioned attacker redirects or intercepts the connection and presents an attacker-controlled TLS certificate.
  4. The client accepts the certificate and sends HTTP Basic credentials or an API token to the impersonated endpoint.
  5. The attacker captures the credential, alters monitoring responses, or relays and modifies privileged write requests.

Impact Assessment

A successful attack can expose reusable monitoring credentials and compromise the integrity of monitoring data. Depending on the permissions of the configured account, the attacker may also gain the ability to acknowledge alerts, suppress monitoring, pause sensors, alter maintenance windows, unmanage monitored nodes, or delete monitoring objects.

The affected scop ...[truncated 153 chars]

Remediation
View remediation

Remediation Suggestions

  • Make TLS certificate verification enabled by default for every supported platform.
  • Require an explicit per-target insecure override for self-signed laboratory deployments.
  • Display a prominent warning whenever certificate verification is disabled.
  • Support custom CA certificates or CA bundles so private PKI and self-signed deployments do not require disabling verification.
  • Reject insecure production configurations where feasible.
  • Document certificate provisioning and trust-store configuration as the preferred solution.

T09 · Insecure Skill Coding Practices

Warning
Location
references/agent-guardrails.md:36
Finding

Destructive MCP Operations Lack a Code-Enforced Confirmation Gate

Content
View full analysis

Vulnerability Details

File Location: references/agent-guardrails.md:36 and SKILL.md:125
Vulnerability Type: Missing authorization enforcement for destructive operations
Risk Level: Medium

Vulnerable Snippets:

text
| "Confirm before anything disruptive" | `remove_node`, `unmanage_node`, `mute_alerts` and the maintenance-window writes all take `dry_run=True` for a preview, and `remove_node`, `unmanage_node` and `zabbix_delete_maintenance` are `risk=high`. ⚠️ **The double confirmation is a CLI feature, and of the writes only `alert_acknowledge` and `undo apply` have CLI commands** — every tool named here is reachable only over MCP, where nothing prompts. Keep your own confirmation for them. |
text
> **No authorization gate**: the skill runs the operations you ask for and audits every one; it does not decide whether a write is permitted — that is the agent's judgement or the permissions of the SolarWinds/PRTG/Zabbix account it connects with (a read-only monitoring account makes writes fail at the server). There is no read-only switch, policy file, or approval gate. `MONITORING_AUDIT_APPROVED_BY` / `MONITORING_AUDIT_RATIONALE` are optional audit annotations, recorded when set.

Technical Analysis

The documentation explicitly states that destructive MCP tools do not prompt for confirmation and that the Skill has no authorization gate, enforceable read-only mode, or required approval mechanism. The documented double confirmation applies to CLI behavior, while the relevant node and maintenance operations are exposed through MCP.

A dry_run option and a prompt-level instruction to wait for approval do not enforce authorization at the tool boundary. An agent can invoke the non-dry-run operation directly. Audit logging records the action after invocation but does not prevent it.

The affected high-risk tools include remove_node, unmanage_node, and zabbix_delete_maintenance. Their effects are e ...[truncated 1343 chars]

Remediation
View remediation

Remediation Suggestions

  • Implement a mandatory two-stage workflow for destructive MCP operations.
  • Require the first call to perform a dry run and return a short-lived, operation-bound confirmation token.
  • Require the execution call to present that token and verify that the target, arguments, user, and expiration match the preview.
  • Add an enforceable read-only mode and enable it by default.
  • Require explicit policy authorization for high-risk operations instead of treating the risk level as an audit-only label.
  • Reject direct non-dry-run calls when no validated approval exists.
  • Preserve audit logging and undo metadata as defense-in-depth, but do not treat either as a substitute for pre-execution authorization.
  • Recommend least-privilege monitoring accounts and separate read-only and administrative credentials.

SkillSpector

Vulnerability Patterns
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
  • Tool MisuseTool Parameter Abuse, Chaining Abuse, Unsafe Defaults
  • Rogue AgentSelf-Modification, Session Persistence
  • MCP Tool PoisoningHidden Instructions, Unicode Deception, Parameter Description Injection
Findings (11)

Tool Parameter Abuse

High
Category
Tool Misuse
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).

Content

Scanner excerpt · references/cli-reference.md (reported line 13)May include surrounding context.

bash
monitoring-aiops init                      # interactive wizard (asks for the platform: solarwinds/prtg/zabbix)
monitoring-aiops doctor [--skip-auth]      # config + secret store + connectivity
                                           #   SolarWinds: a SWQL query · PRTG: /api/status.json
                                           #   Zabbix: apiinfo.version (no auth) + authed host count
monitoring-aiops mcp                       # start the MCP server (stdio transport)

Tool Parameter Abuse

High
Category
Tool Misuse
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).

Content

Scanner excerpt · references/setup-guide.md (reported line 124)May include surrounding context.

bash
monitoring-aiops init                      # interactive wizard (asks for the platform: solarwinds/prtg/zabbix)
monitoring-aiops doctor [--skip-auth]      # config + secret store + connectivity
                                           #   SolarWinds: a SWQL query · PRTG: /api/status.json
                                           #   Zabbix: apiinfo.version (no auth) + authed host count
monitoring-aiops mcp                       # start the MCP server (stdio transport)

Intent-Code Divergence

Medium
Category
Not specified by scanner
Confidence
95% confidence
Finding

The skill markets a 'governance harness' with audit, policy, undo, and risk tiers, which reasonably suggests enforcement controls. Later text clarifies there is no authorization gate and that risk tiers are only descriptive, creating a misleading safety posture that could cause an agent or operator to overtrust the skill and execute high-risk monitoring writes without real preventive controls.

Content

No source excerpt is available for this finding.

Session Persistence

Medium
Category
Rogue Agent
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.

Content

Scanner excerpt · SKILL.md (reported line 23)May include surrounding context.

md
metadata: {"openclaw":{"requires":{"anyBins":["monitoring-aiops","uvx"]},"optional":{"env":["MONITORING_AIOPS_CONFIG","MONITORING_AIOPS_MASTER_PASSWORD"]},"homepage":"https://github.com/AIops-tools/Monitoring-AIops","emoji":"📡","os":["macos","linux"]}}
compatibility: >
  Standalone, self-governed monitoring operations across SolarWinds Orion (SWIS REST + SWQL, port 17774 on Orion 2023.1+ with an automatic one-shot fallback to the legacy 17778, HTTP Basic auth), Paessler PRTG (web API, port 443/8080, API token), and Zabbix 6.x/7.x (JSON-RPC 2.0 at /api_jsonrpc.php, API token as Bearer header on 6.4+/7.x with a legacy auth-field fallback for 6.0). Each target in the config names its own platform, so one config can span all NOCs. The governance harness (audit, policy, token/runaway budget, undo, risk-tiers) is bundled in the package — no external skill-family dependency.
  All write operations are audited to a local SQLite DB under ~/.monitoring-aiops/ (relocatable via MONITORING_AIOPS_HOME).
  Credentials: the Orion account password (SolarWinds), the PRTG API token, or the Zabbix API token is stored ENCRYPTED in ~/.monitoring-aiops/secrets.enc (Fernet/AES-128 + scrypt-derived key) — never plaintext on disk. Run 'monitoring-aiops init' to onboard (it asks for the platform), or 'monitoring-aiops secret set <target>' to add one. The store is unlocked by a master password from MONITORING_AIOPS_MASTER_PASSWORD (non-interactive/MCP/CI) or an interactive prompt (CLI on a TTY). A legacy plaintext env var MONITORING_<TARGET_NAME_UPPER>_SECRET is still honoured as a fallback with a deprecation warning (migrate with 'monitoring-aiops secret migrate'). The secret is used for HTTP Basic auth (SolarWinds) or as the PRTG/Zabbix API token at request time and held only in memory; secrets are never logged or echoed.
  Read-only SWQL passthrough (swql_query) is validated to accept SELECT statements only. State-changing operations pass through the @governed_tool decorator (budget guard 
...[truncated 25 chars]

Intent-Code Divergence

Medium
Category
Not specified by scanner
Confidence
96% confidence
Finding

The compatibility section says state-changing operations pass through a governance decorator and budget guard, but also admits risk levels are not gates. This can mislead users into believing writes are constrained when in fact destructive operations remain executable if the backing account permits them, increasing the chance of accidental or unauthorized changes to monitoring state.

Content

No source excerpt is available for this finding.

Session Persistence

Medium
Category
Rogue Agent
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.

Content

Scanner excerpt · SKILL.md (reported line 125)May include surrounding context.

md
## Common Workflows

> **No authorization gate**: the skill runs the operations you ask for and audits every one; it does not decide whether a write is permitted — that is the agent's judgement or the permissions of the SolarWinds/PRTG/Zabbix account it connects with (a read-only monitoring account makes writes fail at the server). There is no read-only switch, policy file, or approval gate. `MONITORING_AUDIT_APPROVED_BY` / `MONITORING_AUDIT_RATIONALE` are optional audit annotations, recorded when set.

### 1. The 3 a.m. alert storm — collapse it, then acknowledge what matters

Missing User Warnings

Medium
Category
Not specified by scanner
Confidence
93% confidence
Finding

The skill supports impactful write actions across SolarWinds, PRTG, and Zabbix, yet the absence of an approval gate or read-only switch is disclosed only later in workflow text rather than as a prominent upfront warning. In this context, muted alerts, unmanage actions, maintenance creation, or node removal can directly reduce monitoring coverage or hide incidents, so weak disclosure materially increases operational risk.

Content

No source excerpt is available for this finding.

Autonomous Decision Making

Medium
Category
Excessive Agency
Confidence
95% confidence
Finding

The guardrail explicitly states that the tool does not enforce read-only mode or approval prompts, leaving all write authorization to external account permissions or the caller's prompt. In a monitoring/operations skill that includes disruptive write actions such as remove, unmanage, mute, pause, and maintenance changes, this creates a real risk of unauthorized or accidental state-changing actions if the connected account is overprivileged or the model is induced to call write tools.

Content

Scanner excerpt · references/agent-guardrails.md (reported line 15)May include surrounding context.

md
## Authorization is not this tool's job — decide it where it belongs

Whether a write should happen is your decision, or the account's. The tool does
not gate it — there is no read-only switch and no approval prompt to configure.
The two right places to control read vs write:

- **The account you connect with.** Give it a SolarWinds/PRTG/Zabbix login with

Unsafe Defaults

Medium
Category
Tool Misuse
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.

Content

Scanner excerpt · references/cli-reference.md (reported line 13)May include surrounding context.

bash
monitoring-aiops init                      # interactive wizard (asks for the platform: solarwinds/prtg/zabbix)
monitoring-aiops doctor [--skip-auth]      # config + secret store + connectivity
                                           #   SolarWinds: a SWQL query · PRTG: /api/status.json
                                           #   Zabbix: apiinfo.version (no auth) + authed host count
monitoring-aiops mcp                       # start the MCP server (stdio transport)

Unsafe Defaults

Medium
Category
Tool Misuse
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.

Content

Scanner excerpt · references/setup-guide.md (reported line 124)May include surrounding context.

bash
monitoring-aiops init                      # interactive wizard (asks for the platform: solarwinds/prtg/zabbix)
monitoring-aiops doctor [--skip-auth]      # config + secret store + connectivity
                                           #   SolarWinds: a SWQL query · PRTG: /api/status.json
                                           #   Zabbix: apiinfo.version (no auth) + authed host count
monitoring-aiops mcp                       # start the MCP server (stdio transport)

Sudo/Root Execution

Medium
Category
Privilege Escalation
Confidence
80% confidence
Finding

Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.

Content

Scanner excerpt · references/setup-guide.md (reported line 85)May include surrounding context.

md
written to disk in
  plaintext. It lives only in `~/.monitoring-aiops/secrets.enc`, encrypted with
  Fernet (AES-128-CBC + HMAC), the key derived from your master password via
  scrypt. Only a per-store random salt and the ciphertext are on disk (chmod
  600); the master password itself is never stored.
- A legacy plaintext env var `MONITORING_<TARGET_NAME_UPPER>_SECRET` is still
  honoured as a fallback with a deprecation warning — migrate with

Static analysis

No suspicious patterns detected.