black-box

• Outcome: Review
• Latest audit: Sep 10, 2026 · 9:35 PM UTC
• Version: 1.0.0

Overview

This skill is an audit logger, but it sends sensitive agent activity to cloud storage and handles database credentials with weak scoping and security controls.

Review this before installing in any environment where logs may include secrets, prompts, commands, customer data, or compliance evidence. Use only an approved database, avoid logging reasoning chains or sensitive command details, require explicit user or admin opt-in for cloud logging, pin dependencies, enforce verified TLS, and store any DSN with owner-only protections or a secret manager.

A.I.G

Vulnerability Patterns

• 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
• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review

Findings (3)

T09 · Insecure Skill Coding Practices

Error

• Location: run.py:67
• Finding: Database Connections Do Not Enforce Verified TLS## Vulnerability Details **File Location**: `run.py`, lines 67-69 and 94-96 **Vulnerability Type**: Database credentials and audit data transmitted without enforced, authenticated TLS **Risk Level**: High **Vulnerable Code**: ```python host, port, user, password, db = parse_dsn(dsn) # Security Fix: Use standard SSL conn = pymysql.connect(host=host, port=port, user=user, password=password, database=db) ``` The same insecure connection configuration is used when reading logs: ```python host, port, user, password, db = parse_dsn(dsn) # Security Fix: Use standard SSL conn = pymysql.connect(host=host, port=port, user=user, password=password, database=db) ``` ### Technical Analysis The code comments claim that standard SSL is used, but the `pymysql.connect` calls do not provide an SSL configuration, trusted certificate authority, hostname verification policy, or any mechanism requiring an encrypted connection. Consequently, the client does not explicitly enforce authenticated TLS. The connection transports a database username, password, and potentially sensitive audit messages. These messages are intended to record high-risk commands, errors, and agent activity. If the connection is established without verified TLS, an attacker with a suitable network position may intercept credentials or audit records. A connection that encrypts traffic without verifying the server identity would also remain exposed to an active machine-in-the-middle attack. ### Attack Path 1. The skill obtains a TiDB DSN from environment variables, its local cache, or the provisioning API. 2. The skill connects to the remote database using `pymysql.connect` without requiring verified TLS. 3. An attacker obtains a network interception position, such as control of an untrusted network, compromised gateway, or malicious routing/DNS infrastructure. 4. The attacker observes or actively intercepts the database connection. 5. Depending on the server ...[truncated 745 chars]
• Remediation: ## Remediation Suggestions - Require TLS explicitly in both database connection paths. - Configure PyMySQL with a trusted CA certificate and certificate and hostname verification, for example through an appropriate `ssl` configuration supported by the deployed PyMySQL version. - Reject connections when TLS negotiation or certificate validation fails; do not silently fall back to plaintext. - Use the TiDB provider's documented CA bundle and secure connection parameters. - Apply the same connection factory and verified-TLS policy to both `log_event` and `read_logs` to prevent configuration drift. - Use a narrowly privileged database account that can access only the required schema and operations. - Add an integration test that verifies encryption is active and that an untrusted or hostname-mismatched certificate is rejected. - Remove or correct the misleading `Security Fix` comments until verified TLS is actually enforced.

T09 · Insecure Skill Coding Practices

Warning

• Location: run.py:38
• Finding: Credential-Bearing DSN Is Cached Without Restrictive File Protections## Vulnerability Details **File Location**: `run.py`, lines 9 and 38-41 **Vulnerability Type**: Insecure local storage of database credentials **Risk Level**: Medium **Vulnerable Code**: ```python DSN_FILE = os.path.expanduser("~/.openclaw_black_box_dsn") ``` ```python dsn = create_temp_db() if dsn: with open(DSN_FILE, 'w') as f: f.write(dsn) return dsn ``` ### Technical Analysis The automatically provisioned connection string contains database authentication information and is written to `~/.openclaw_black_box_dsn` using ordinary text-file creation. The resulting permissions depend on the process umask; the application does not explicitly require owner-only mode such as `0600`. The code also does not validate the file's owner, type, or permissions before reading it. Normal `open` behavior follows symbolic links, so a local attacker who can manipulate the target path may be able to redirect writes or influence the cached connection data. Exploitability of the symlink case depends on local filesystem permissions and the privileges under which the skill executes. ### Attack Path A credential-disclosure path is: 1. The user invokes the skill without configured `TIDB_*` credentials. 2. The skill provisions a temporary TiDB instance and receives a DSN containing authentication data. 3. The DSN is written to `~/.openclaw_black_box_dsn` without explicit owner-only permissions. 4. Under a permissive umask or unsuitable home-directory permissions, another local user or compromised process reads the file. 5. The attacker extracts the database host, username, and password. 6. The attacker connects to the database and performs any operations allowed to that database account. A filesystem-manipulation path, where local permissions permit it, is: 1. An attacker arranges for the DSN path to be a symbolic link or otherwise replaces the expected file. 2. The skill follows the path during a read or wri ...[truncated 757 chars]
• Remediation: ## Remediation Suggestions - Prefer an operating-system credential store or dedicated secret-management service instead of a plaintext DSN file. - If a file is required, create it atomically with owner-only permissions, such as mode `0600`, without relying on the process umask. - Open the file using protections that prevent symbolic-link traversal where supported, and write through a securely created temporary file followed by an atomic rename. - Before reading an existing cache, verify that it is a regular file, owned by the expected user, not a symbolic link, and inaccessible to group and other users. - Reject cached files with insecure ownership or permissions rather than consuming them. - Store the minimum necessary secret data and rotate provisioned credentials if file exposure is suspected. - Apply least-privilege database permissions and separate read and write credentials where practical. - Avoid including passwords in diagnostic output or exception messages.

T08 · Insecure Dependencies

Note

• Location: requirements.txt:1
• Finding: Third-Party Dependency Is Not Version-Pinned or Integrity-Locked## Vulnerability Details **File Location**: `requirements.txt`, line 1 **Vulnerability Type**: Non-reproducible and insufficiently constrained dependency installation **Risk Level**: Low **Vulnerable Code**: ```text pymysql ``` ### Technical Analysis The dependency declaration does not specify an exact reviewed version or an integrity hash. Each installation can therefore resolve to whatever version the configured package index considers current at that time. This prevents reproducible dependency review and can introduce unexpected behavior or vulnerabilities through future releases. The available project evidence does not establish that `pymysql` itself is malicious or currently vulnerable. The confirmed issue is the absence of version and artifact integrity controls, which weakens supply-chain assurance. ### Attack Path 1. A user or automated deployment installs dependencies from `requirements.txt`. 2. The package installer resolves `pymysql` without an exact version or expected artifact hash. 3. A future compromised, vulnerable, or behaviorally incompatible release is selected from the configured package source. 4. The package is installed into the skill's Python environment. 5. Its code is imported by `run.py` and executes with the privileges of the skill process. 6. Any resulting impact depends on the contents of the selected dependency release and the permissions of that process. ### Impact Assessment A compromised dependency could execute arbitrary Python code with the same local privileges as the skill process and could access environment variables, the cached TiDB DSN, database traffic, and data available to that process. A merely vulnerable or incompatible release could instead cause denial of service or incorrect database behavior. This finding does not demonstrate an existing malicious package; it identifies a supply-chain control weakness.
• Remediation: ## Remediation Suggestions - Pin `pymysql` to an exact version that has been reviewed and tested. - Generate and enforce cryptographic hashes for approved distribution artifacts, such as with a hash-locked requirements file and `pip --require-hashes`. - Use a controlled, trusted package index or internal artifact mirror. - Add automated dependency vulnerability and provenance scanning to the release process. - Review and deliberately update the lock file rather than accepting new dependency releases automatically. - Preserve a documented process for urgent security upgrades so exact pinning does not prevent timely remediation.

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep
• Rogue Agent: Self-Modification, Session Persistence
• Behavioral AST: exec() Call, eval() Call, Dynamic Import

Findings (14)

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 97% confidence
• Finding: The declared purpose implies an indestructible audit log, but the documented behavior includes reading logs, auto-provisioning an external database, caching a DSN locally, and using a normal mutable SQL table. This mismatch can mislead operators into trusting the skill with sensitive agent data and reasoning traces under false assumptions about immutability, scope, and data handling.

Missing User Warnings

Medium

• Confidence: 95% confidence
• Finding: The protocol instructs the agent to send 'intent and status to the cloud' before high-risk actions or on unrecoverable errors, but provides no warning, consent mechanism, or data-minimization guidance. This can leak sensitive operational context, command intent, or error details off-system, which is especially risky because it is triggered around privileged or destructive actions.

Lp3

Medium

• Category: MCP Least Privilege
• Confidence: 94% confidence
• Finding: The skill advertises shell, environment, file read, and file write capabilities but does not declare any explicit tool scope or permission boundaries. That makes it harder for users and policy systems to understand or constrain what the skill can access, increasing the risk of overprivileged execution and misuse of credentials or local files.

Missing User Warnings

Medium

• Confidence: 96% confidence
• Finding: The skill explicitly says it can stream critical actions, errors, and reasoning chains to a persistent cloud database, but it does not provide a prominent warning that highly sensitive data may leave the local environment. In an agent context, logs often contain secrets, internal prompts, credentials, and proprietary data, so omission of this warning creates a meaningful exfiltration and privacy risk.

Session Persistence

Medium

• Category: Rogue Agent

Content

## Security & Provisioning
1.  **Bring Your Own Database (Recommended):** Set `TIDB_*` environment variables.
2.  **Auto-Provisioning (Fallback):** If no credentials are found, this skill uses the TiDB Zero API to create a temporary database for logging. The connection string is cached in `~/.openclaw_black_box_dsn`.

## Why use this?
*   **Crash Survival:** Local logs vanish when containers crash. Cloud logs persist.

• Confidence: 88% confidence
• Finding: Caching the database connection string in a persistent home-directory file creates session persistence and leaves sensitive access material on disk beyond the current run. If the host is shared, compromised, or reused, later processes or users could recover the DSN and access or tamper with stored logs.

Context-Inappropriate Capability

Medium

• Confidence: 90% confidence
• Finding: This logging skill performs undisclosed remote resource provisioning by creating database instances over the network, which exceeds the narrow function implied by an audit-log tool. In a security-sensitive agent context, hidden infrastructure creation can incur cost, expand exfiltration paths, and create persistence outside the user’s expected control plane.

Missing User Warnings

Medium

• Confidence: 91% confidence
• Finding: The skill makes an external network call to provision infrastructure without any user-facing warning, despite presenting itself as an audit-log utility. In context, this is more dangerous because users may not expect a logging helper to contact a third-party API, create resources, or send metadata off-host, which breaks informed consent and complicates trust boundaries.

subprocess module call

Medium

• Category: Dangerous Code Execution

Content

for i in range(3):
        try:
            cmd = ["curl", "-sS", "-X", "POST", api_url, "-H", "content-type: application/json", "-d", "{}"]
            result = subprocess.run(cmd, capture_output=True, text=True, timeout=30)
            if result.returncode == 0:
                data = json.loads(result.stdout)
                dsn = data.get("instance", {}).get("connectionString")

• Confidence: 70% confidence
• Finding: subprocess module calls execute external commands. Without careful input validation, this enables command injection.

Description-Behavior Mismatch

Medium

• Confidence: 94% confidence
• Finding: The skill advertises indestructible audit logging in TiDB Zero, but it silently redirects storage to any database specified through environment variables. In an agent environment, this can reroute sensitive audit data to attacker-controlled infrastructure or an untrusted internal endpoint, undermining integrity, confidentiality, and user expectations about where logs are stored.

Missing User Warnings

Medium

• Confidence: 92% confidence
• Finding: The skill persists a sensitive DSN, likely containing database credentials, to a predictable file in the user home directory without disclosure or permission hardening. Other local users, processes, or later agent actions may read that file and gain unauthorized access to the audit database, compromising log confidentiality and integrity.

Unpinned Dependencies

Low

• Category: Supply Chain

Content

pymysql

• Confidence: 97% confidence
• Finding: The dependency is unpinned, so installs are not reproducible and may pull in newer releases with breaking changes or newly introduced security issues. In a security-sensitive skill that handles audit logs, supply-chain uncertainty is undesirable because behavior and exposure can change over time without review.

Unverifiable Dependency: pymysql has 2 known advisory(ies) (CVE-2024-36039 (PyMySQL SQL Injection vulnerability); CVE-2024-36039 (PyMySQL SQL Injection vulnerability)), but the manifest does not pin a version, so it is unknown whether the installed release is affected

Low

• Category: Supply Chain
• Confidence: 94% confidence
• Finding: PyMySQL has known advisories, and because the manifest does not pin a version, there is no assurance that deployment will avoid affected releases. Given this skill's database-oriented purpose ('stored in TiDB Zero'), use of a potentially vulnerable SQL client library raises the risk of database compromise or unsafe query handling if an affected version is installed.

Intent-Code Divergence

Low

• Confidence: 97% confidence
• Finding: The code claims to use SSL but does not actually configure TLS or certificate verification on the database connection. That mismatch can cause credentials and log contents to traverse the network without authenticated transport guarantees, enabling interception or man-in-the-middle attacks if the connection is not protected by secure defaults.

Intent-Code Divergence

Low

• Confidence: 97% confidence
• Finding: The read path repeats the same unsafe assumption by connecting without explicit TLS settings while claiming a security fix. Because this path retrieves stored logs, it can leak potentially sensitive audit records and credentials over an unauthenticated network channel.

Static analysis

No suspicious patterns detected.