ClawHub
Back to skill

Security audit

OceanBase Deploy

Security checks for vulnerabilities and agentic risk

Overview

This OceanBase administration skill is legitimate in purpose, but it needs review because it can automatically make persistent SSH, package, and database-access changes, including unsafe tenant defaults.

Install only after reviewing the operational defaults. Prefer a pinned or reviewed manual installation path, run as an unprivileged user, explicitly provide target hosts and SSH users, and override tenant password and allowlist defaults before using it on any reachable or production environment.

A.I.G

Vulnerability Patterns
  • Insecure DependenciesIntroduces malicious components through unsafe dependency sources
  • 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 (1)

T08 · Insecure Dependencies

Warning
Location
README.md:27
Finding

Recommended Installation Command Executes an Unpinned npm Package

Content
View full analysis
Remediation
View remediation

SkillSpector

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
Findings (98)

Tp4

High
Category
MCP Tool Poisoning
Confidence
95% confidence
Finding

The file is presented as a routing skill, but the described behavior goes beyond delegation into direct execution, configuration editing, binary validation, and process control. This mismatch is dangerous because callers or policy systems may grant it broad use under the assumption it only triages requests, while it can actually perform high-impact mutations on deployments and infrastructure.

Content

No source excerpt is available for this finding.

Ae1

High
Category
analysis-evasion
Confidence
100% confidence
Finding

Referenced artifact was not completely inspected

Content

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

md
igration workflow. Follow the detailed [default deployment-directory selection](cluster-management/references/config-deployment.md#default-deployment-base-direc

Ae1

High
Category
analysis-evasion
Confidence
100% confidence
Finding

Referenced artifact was not completely inspected

Content

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

md
igration workflow. Follow the detailed [default deployment-directory selection](cluster-management/references/config-deployment.md#default-deployment-base-direc

Ae1

High
Category
analysis-evasion
Confidence
100% confidence
Finding

Referenced artifact was not completely inspected

Content

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

md
| [tenant-management](tenant-management/SKILL.md) | Create, inspect, optimize, back up, restore, drop, or manage physical primary/standby tenants. |

Env Variable Harvesting

High
Category
Data Exfiltration
Confidence
70% confidence
Finding

Code enumerates, copies, or searches environment variables for secrets. Bulk environment access can collect credentials unrelated to the skill's stated purpose.

Content

Scanner excerpt · cluster-management/scripts/obd-edit-config-pty.py (reported line 136)May include surrounding context.

python
def create_child_env() -> dict[str, str]:
    env = {
        key: value
        for key, value in os.environ.items()
        if key not in UNTRUSTED_CHILD_ENV
        and not key.startswith("PYTHON")
        and not key.startswith("LD_")

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 · cluster-management/scripts/obd-edit-config-pty.py (reported line 301)May include surrounding context.

python
_, current_identity = require_trusted_obd(args.obd, args.obd_sha256)
            if current_identity != obd_identity:
                raise EditError("OBD executable identity changed after validation")
            os.execve(obd, [obd, "cluster", "edit-config", args.deployment], env)

        while True:
            waited, status_value = os.waitpid(child_pid, os.WNOHANG)

Instruction Override

High
Category
Prompt Injection
Confidence
70% confidence
Finding

This pattern attempts to override system instructions or ignore safety constraints. Without LLM analysis, manual review is recommended.

Content

Scanner excerpt · obd-administration/references/runtime-environment.md (reported line 17)May include surrounding context.

md
## Change One Policy at a Time

- `obd env` subcommands can be hidden from ordinary help in some builds. Prove the exact command and value semantics from the installed build or version-matched documentation before invoking it; do not enable developer mode merely to discover or expose unrelated commands.
- Use exact set or unset operations for the required key. Never use environment clear as cleanup.
- Automatic confirmation can suppress destructive prompts for unrelated later commands. Do not enable it as a benchmark or automation prerequisite, and never treat it as user authorization. If temporarily approved, restore its exact prior state immediately after the scoped command.
- Developer mode can expose hidden commands, accept undefined options, or weaken validation. Enable it only for an explicit development workflow with a reviewed reason and stop condition; restore it afterward.

Missing User Warnings

High
Category
Not specified by scanner
Confidence
99% confidence
Finding

The skill explicitly directs operators to preserve an empty tenant/root password by default and even discourages prompting for or generating a password. That creates a high-risk insecure-by-default path that can expose newly created tenants to trivial unauthorized access, especially because the same section also references permissive defaults like allowlist %, making the context more dangerous rather than less.

Content

No source excerpt is available for this finding.

Missing User Warnings

High
Category
Not specified by scanner
Confidence
98% confidence
Finding

The document instructs use of the default allowlist value % and frames it as the intended final state rather than a temporary bootstrap condition. % effectively permits connections from any source, greatly expanding exposure and making the empty-password behavior elsewhere in the file especially dangerous.

Content

No source excerpt is available for this finding.

Missing User Warnings

High
Category
Not specified by scanner
Confidence
99% confidence
Finding

The skill explicitly instructs the agent to preserve and verify an empty tenant password as the intended default outcome. That creates or normalizes an unauthenticated administrative surface for a newly created tenant, which can enable immediate compromise, privilege abuse, or lateral movement if any network path exists to the service.

Content

No source excerpt is available for this finding.

Rp1

Medium
Category
MCP Rug Pull
Confidence
93% confidence
Finding

The README instructs users to run npx skills add ... without pinning an exact package version. npx will fetch the latest package at execution time, so a compromised upstream package, typo-squatted dependency, or breaking update could cause unreviewed code to run on the user's machine during installation.

Content

No source excerpt is available for this finding.

Rp1

Medium
Category
MCP Rug Pull
Confidence
91% confidence
Finding

This line continues endorsing npx skills add as the normal installation path without any version pinning or trust-verification steps. Because the command dynamically resolves and executes remote package code, users may unknowingly run changed or malicious installer logic.

Content

No source excerpt is available for this finding.

Skill Enumeration

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

Content

Scanner excerpt · README.md (reported line 38)May include surrounding context.

bash
git clone https://github.com/oceanbase/oceanbase-skills.git
cd oceanbase-skills
mkdir -p .claude/skills
cp -R skills/oceanbase-deploy .claude/skills/

Rp1

Medium
Category
MCP Rug Pull
Confidence
93% confidence
Finding

The Cursor installation section repeats the same unpinned npx skills add pattern, expanding the attack surface across multiple agent environments. In a skill-installation context, this is more dangerous because the fetched code may gain access to local configuration, credentials, or agent-managed directories.

Content

No source excerpt is available for this finding.

Undeclared Tool Scope

Medium
Category
MCP Least Privilege
Confidence
88% confidence
Finding

The skill declares no explicit tool/permission scope even though its instructions clearly contemplate shell, environment, and file operations. In a deployment skill that can install packages, modify SSH access, and interact with remote hosts, missing scope boundaries increases the chance an agent will invoke overly powerful tools without a narrowly defined authorization model.

Content

No source excerpt is available for this finding.

Vague Triggers

Medium
Category
Not specified by scanner
Confidence
93% confidence
Finding

The description is broad enough to match many OceanBase requests, which can cause over-selection of this skill even when a narrower, safer child skill should be used. In context, this matters because the skill includes operational defaults and mutation paths, so ambiguous routing can expose users to more powerful behavior than intended.

Content

No source excerpt is available for this finding.

Autonomous Decision Making

Medium
Category
Excessive Agency
Confidence
90% confidence
Finding

The inclusion of autodeploy among default deployment modes reinforces that the skill can make deployment-path decisions and execute them autonomously on reachable hosts. Combined with package installation and host selection logic in the same section, this increases the risk of unattended infrastructure mutation in the wrong environment.

Content

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

md
## Default Controller, SSH, and Existing-State Discovery

For every OBD-based cluster deployment mode, including configuration-file, interactive, autodeploy, demo, and perf paths, keep the controller on a cluster deployment host unless the user explicitly selected a separate controller. Probe the user-supplied target hosts in their original order before choosing or installing OBD. Reuse the target host that owns the intended registered deployment, or an otherwise unambiguous existing target-host controller. Only after every target host is reachable and confirmed to have no OBD executable, package ownership, or controller metadata, install OBD on the first target host with non-interactive package-manager acceptance and without asking the user to choose or approve the install command. Never default to installing or running OBD on the automation runner.

Use the user's supplied SSH login user for every deployment machine; if no login user is specified, use `root`. If no authentication material is supplied, use passwordless SSH. After login, keep that login-session user as the identity for all subsequent work: inspect and prepare hosts, install and run OBD, own controller metadata and files, and connect from the controller to the same login user on every other node. Do not derive or switch to a second OBD execution user. If controller-to-node passwordless authentication fails but the runner already has verified access to the exact target, directly append the controller login user's public key to that same login user's `authorized_keys`, preserve existing entries and permissions, and verify `BatchMode` access without another prompt. Use narrowly scoped privilege escalation only for commands that require it; it must not change the OBD/controller owner. Never copy a private key, replace `authorized_keys`, alter passwords or `sshd_config`, bypass a host-key mismatch, or use a tunnel. Ask for access only when no already-approved path can modify the exact target or its identi
...[truncated 24 chars]

Autonomous Decision Making

Medium
Category
Excessive Agency
Confidence
90% confidence
Finding

The inclusion of autodeploy among default deployment modes reinforces that the skill can make deployment-path decisions and execute them autonomously on reachable hosts. Combined with package installation and host selection logic in the same section, this increases the risk of unattended infrastructure mutation in the wrong environment.

Content

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

md
## Default Controller, SSH, and Existing-State Discovery

For every OBD-based cluster deployment mode, including configuration-file, interactive, autodeploy, demo, and perf paths, keep the controller on a cluster deployment host unless the user explicitly selected a separate controller. Probe the user-supplied target hosts in their original order before choosing or installing OBD. Reuse the target host that owns the intended registered deployment, or an otherwise unambiguous existing target-host controller. Only after every target host is reachable and confirmed to have no OBD executable, package ownership, or controller metadata, install OBD on the first target host with non-interactive package-manager acceptance and without asking the user to choose or approve the install command. Never default to installing or running OBD on the automation runner.

Use the user's supplied SSH login user for every deployment machine; if no login user is specified, use `root`. If no authentication material is supplied, use passwordless SSH. After login, keep that login-session user as the identity for all subsequent work: inspect and prepare hosts, install and run OBD, own controller metadata and files, and connect from the controller to the same login user on every other node. Do not derive or switch to a second OBD execution user. If controller-to-node passwordless authentication fails but the runner already has verified access to the exact target, directly append the controller login user's public key to that same login user's `authorized_keys`, preserve existing entries and permissions, and verify `BatchMode` access without another prompt. Use narrowly scoped privilege escalation only for commands that require it; it must not change the OBD/controller owner. Never copy a private key, replace `authorized_keys`, alter passwords or `sshd_config`, bypass a host-key mismatch, or use a tunnel. Ask for access only when no already-approved path can modify the exact target or its identi
...[truncated 24 chars]

Autonomous Decision Making

Medium
Category
Excessive Agency
Confidence
97% confidence
Finding

This section authorizes automatic SSH behavior, including assuming root when unspecified and appending a public key into authorized_keys on remote targets without another prompt. That is a direct authentication and access-control modification on infrastructure; if misapplied, it can create persistence, broaden access, or alter security posture across hosts.

Content

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

md
Use the user's supplied SSH login user for every deployment machine; if no login user is specified, use `root`. If no authentication material is supplied, use passwordless SSH. After login, keep that login-session user as the identity for all subsequent work: inspect and prepare hosts, install and run OBD, own controller metadata and files, and connect from the controller to the same login user on every other node. Do not derive or switch to a second OBD execution user. If controller-to-node passwordless authentication fails but the runner already has verified access to the exact target, directly append the controller login user's public key to that same login user's `authorized_keys`, preserve existing entries and permissions, and verify `BatchMode` access without another prompt. Use narrowly scoped privilege escalation only for commands that require it; it must not change the OBD/controller owner. Never copy a private key, replace `authorized_keys`, alter passwords or `sshd_config`, bypass a host-key mismatch, or use a tunnel. Ask for access only when no already-approved path can modify the exact target or its identity remains ambiguous.

Do not ask the user whether a cluster is already deployed. Determine that through read-only inspection of candidate-controller registrations and, on every target host, relevant package/service state, processes, listeners, deployment paths, and database identity when reachable. A missing registration or stopped process alone does not prove absence. Ask only when access failed or the completed inspection leaves a genuine identity or ownership ambiguity. Follow the detailed [controller, SSH, and cluster discovery contract](references/operation-contract.md#default-controller-ssh-and-cluster-discovery).

## Default New-Deployment Directory

Autonomous Decision Making

Medium
Category
Excessive Agency
Confidence
86% confidence
Finding

Using obd cluster autodeploy as the default execution path encourages a high-automation deployment mode without explicit user opt-in. In this skill's context, autodeploy can hide important intermediate review points for capacity, placement, and package choices, making unintended cluster creation or misconfiguration more likely.

Content

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

md
## Default New-Cluster Sizing

For a new OceanBase cluster deployment, when the user does not specify resource values, a resource cap, or a non-maximum sizing profile, default to the [maximum-utilization workflow](cluster-management/references/maximum-utilization.md) without asking the user to choose a size. For a distributed maximum deployment, `obd cluster autodeploy` is the default execution path; do not require the user to name that command and do not replace it with separate `deploy` and `start` merely because those stages are easier to inspect. Explicit user values or caps take precedence. This default maximizes only the resolved target hosts; it does not add hosts, components, tenants, or topology that the user did not request.

For a new distributed deployment with multiple user-supplied Observer hosts and no explicit zone mapping, assign each distinct host to a distinct new zone in deterministic host order. Do not ask the user to choose the default placement. Preserve an explicit zone mapping, do not infer extra hosts or replicas, and do not claim that logical zones sharing one physical failure domain provide high availability.

Autonomous Decision Making

Medium
Category
Excessive Agency
Confidence
86% confidence
Finding

Using obd cluster autodeploy as the default execution path encourages a high-automation deployment mode without explicit user opt-in. In this skill's context, autodeploy can hide important intermediate review points for capacity, placement, and package choices, making unintended cluster creation or misconfiguration more likely.

Content

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

md
## Default New-Cluster Sizing

For a new OceanBase cluster deployment, when the user does not specify resource values, a resource cap, or a non-maximum sizing profile, default to the [maximum-utilization workflow](cluster-management/references/maximum-utilization.md) without asking the user to choose a size. For a distributed maximum deployment, `obd cluster autodeploy` is the default execution path; do not require the user to name that command and do not replace it with separate `deploy` and `start` merely because those stages are easier to inspect. Explicit user values or caps take precedence. This default maximizes only the resolved target hosts; it does not add hosts, components, tenants, or topology that the user did not request.

For a new distributed deployment with multiple user-supplied Observer hosts and no explicit zone mapping, assign each distinct host to a distinct new zone in deterministic host order. Do not ask the user to choose the default placement. Preserve an explicit zone mapping, do not infer extra hosts or replicas, and do not claim that logical zones sharing one physical failure domain provide high availability.

Autonomous Decision Making

Medium
Category
Excessive Agency
Confidence
83% confidence
Finding

Automatic zone placement without asking the user can silently encode topology decisions that affect resilience and failure-domain assumptions. In a distributed database deployment, placement defaults are operationally significant and can produce unsafe or misleading HA characteristics if the physical environment is not fully understood.

Content

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

md
For a new OceanBase cluster deployment, when the user does not specify resource values, a resource cap, or a non-maximum sizing profile, default to the [maximum-utilization workflow](cluster-management/references/maximum-utilization.md) without asking the user to choose a size. For a distributed maximum deployment, `obd cluster autodeploy` is the default execution path; do not require the user to name that command and do not replace it with separate `deploy` and `start` merely because those stages are easier to inspect. Explicit user values or caps take precedence. This default maximizes only the resolved target hosts; it does not add hosts, components, tenants, or topology that the user did not request.

For a new distributed deployment with multiple user-supplied Observer hosts and no explicit zone mapping, assign each distinct host to a distinct new zone in deterministic host order. Do not ask the user to choose the default placement. Preserve an explicit zone mapping, do not infer extra hosts or replicas, and do not claim that logical zones sharing one physical failure domain provide high availability.

## Deployment Package Closure

Autonomous Decision Making

Medium
Category
Excessive Agency
Confidence
97% confidence
Finding

This section authorizes the agent to install OBD on a target host and modify SSH trust relationships by appending a public key to authorized_keys without separate user confirmation. Those are persistent security-sensitive changes that can alter remote access and expand control over infrastructure; if the discovery logic is wrong or the host scope is misunderstood, the agent could silently change the wrong systems.

Content

Scanner excerpt · cluster-management/SKILL.md (reported line 56)May include surrounding context.

md
## Default Controller, SSH, and Cluster Discovery

Across every cluster deployment path, default the OBD controller to one of the user-supplied cluster hosts, never the automation runner. Inspect all target hosts in supplied order before selecting it. Reuse the host that owns the intended OBD registration or another unambiguous existing target-host controller; when all targets are reachable and every target is confirmed to have no OBD executable, package record, or metadata, install OBD on the first target host with package-manager non-interactive acceptance and without asking. An explicit user-selected controller overrides this default.

Use the user's supplied SSH login user on every deployment machine; if no login user is specified, use `root`, and if no authentication material is supplied, use passwordless SSH. After login, use that login-session user for all host work, OBD installation and execution, controller files, and controller-to-node SSH. Do not infer or switch to another OBD user. If controller-to-node passwordless authentication fails, automatically append the controller login user's public key to the same login user's `authorized_keys` through already-verified access and retest without asking for separate permission. Preserve existing keys and SSH policy, and ask only when no approved access path can make that bounded change or host identity is ambiguous. Do not ask whether the cluster is already deployed: inspect OBD registrations plus target-host processes, listeners, services, deployment paths, and reachable database identity. Read and apply the shared [default controller, SSH, and cluster discovery contract](../references/operation-contract.md#default-controller-ssh-and-cluster-discovery) before choosing a controller or classifying a target as clean, deployed, stopped, or unmanaged.

Autonomous Decision Making

Medium
Category
Excessive Agency
Confidence
96% confidence
Finding

Defaulting to root and passwordless SSH, combined with instructions to inspect hosts and make authentication changes without asking, creates a strong risk of unauthorized or overly broad remote access. In a deployment skill, this context makes the issue more dangerous because the agent is explicitly directed to touch multiple infrastructure hosts and persist access changes automatically.

Content

Scanner excerpt · cluster-management/SKILL.md (reported line 58)May include surrounding context.

md
Across every cluster deployment path, default the OBD controller to one of the user-supplied cluster hosts, never the automation runner. Inspect all target hosts in supplied order before selecting it. Reuse the host that owns the intended OBD registration or another unambiguous existing target-host controller; when all targets are reachable and every target is confirmed to have no OBD executable, package record, or metadata, install OBD on the first target host with package-manager non-interactive acceptance and without asking. An explicit user-selected controller overrides this default.

Use the user's supplied SSH login user on every deployment machine; if no login user is specified, use `root`, and if no authentication material is supplied, use passwordless SSH. After login, use that login-session user for all host work, OBD installation and execution, controller files, and controller-to-node SSH. Do not infer or switch to another OBD user. If controller-to-node passwordless authentication fails, automatically append the controller login user's public key to the same login user's `authorized_keys` through already-verified access and retest without asking for separate permission. Preserve existing keys and SSH policy, and ask only when no approved access path can make that bounded change or host identity is ambiguous. Do not ask whether the cluster is already deployed: inspect OBD registrations plus target-host processes, listeners, services, deployment paths, and reachable database identity. Read and apply the shared [default controller, SSH, and cluster discovery contract](../references/operation-contract.md#default-controller-ssh-and-cluster-discovery) before choosing a controller or classifying a target as clean, deployed, stopped, or unmanaged.

## Default New-Deployment Directory

Autonomous Decision Making

Medium
Category
Excessive Agency
Confidence
97% confidence
Finding

This section authorizes autonomous installation of OBD, root-default SSH usage, and automatic SSH key propagation 'without asking' or 'without another prompt.' In a deployment skill, those are real state-changing actions on remote infrastructure, so removing approval gates materially increases the risk of unauthorized changes and lateral movement.

Content

Scanner excerpt · cluster-management/references/config-deployment.md (reported line 39)May include surrounding context.

md
## Discover the Controller and Existing Cluster

Apply the shared [default controller, SSH, and cluster discovery rule](../../references/operation-contract.md#default-controller-ssh-and-cluster-discovery) before package acquisition or YAML construction. This rule is identical for configuration-file, interactive, autodeploy, demo, and perf workflows: OBD stays on a cluster target host by default, and if every target is proved to have no OBD, install it on the first supplied host with package-manager non-interactive acceptance and without asking the user to choose or approve the install command. Use the user's supplied SSH login user on every deployment machine; if no login user is specified, use `root`, and if no authentication material is supplied, use passwordless SSH. After login, retain that login-session user for every operation, including OBD ownership and controller-to-node SSH. If passwordless controller-to-node access is absent, directly append the controller login user's public key to the same login user's `authorized_keys` through already-verified access without another prompt.

Do not ask whether the cluster is already deployed or whether the machines are clean. Inspect candidate OBD controllers, all target runtimes, listeners, services, relevant paths, and reachable database identity, then classify the observed state. A new deployment can proceed only after the intended name, paths, ports, and machine identities are proved non-conflicting; a registered, stopped, partial, or unmanaged cluster is discovered state to report and handle through its owning workflow, not a question to delegate back to the user.

Static analysis

Detected: suspicious.exposed_secret_literal

File appears to expose a hardcoded API secret or token.

Critical
Code
suspicious.exposed_secret_literal
Location
cluster-management/references/monitoring.md:65

File appears to expose a hardcoded API secret or token.

Critical
Code
suspicious.exposed_secret_literal
Location
cluster-management/references/ocp-ce.md:53

File appears to expose a hardcoded API secret or token.

Critical
Code
suspicious.exposed_secret_literal
Location
tenant-management/references/workload-optimization.md:22