ClawHub
Back to skill

Security audit

Dolphindb Docker

Security checks for vulnerabilities and agentic risk

Overview

This is a functional DolphinDB Docker deployer, but it gives the container broad writable access to host system configuration and performs other under-scoped host and Docker changes.

Review and modify this skill before installing in any real environment: remove the full /etc mount or replace it with minimal read-only license files, pin and verify Docker image digests, restrict the data directory to a dedicated path, bind ports to localhost unless remote access is intentional, and avoid running the script with elevated privileges.

A.I.G

Vulnerability Patterns
  • Unauthorized Access and Privilege EscalationObtains permissions beyond the task's legitimate needs
  • Insecure DependenciesIntroduces malicious components through unsafe dependency sources
  • 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
Findings (5)

T05 · Unauthorized Access and Privilege Escalation

Error
Location
deploy-dolphindb.sh:166
Finding

Writable Host /etc Directory Exposed to the Container

Content
View full analysis

Vulnerability Details

File Location: deploy-dolphindb.sh:166-176
Vulnerability Type: Excessive host filesystem access through a writable Docker bind mount
Risk Level: Critical

Vulnerable Code

bash
docker run -itd \
    --name "$CONTAINER_NAME" \
    --hostname "$HOSTNAME" \
    --platform "linux/$PLATFORM" \
    -m "${MEMORY}g" \
    -p 8848:8848 \
    -p 8849:8849 \
    -v /etc:/dolphindb/etc \
    -v "$DATA_DIR:/data/ddb/server" \
    "${IMAGE}:${VERSION}"

Technical Analysis

The script bind-mounts the host's entire /etc directory into the container. Docker bind mounts are writable unless explicitly marked read-only with :ro.

The documentation states that this mount supports license fingerprint collection, but that purpose does not require writable access to every host configuration file. Under a standard rootful Docker configuration, a process running as root inside the container may write through /dolphindb/etc to security-sensitive files on the host.

This breaks the principle of least privilege and substantially increases the consequences of a compromised, malicious, or vulnerable DolphinDB image.

Attack Path

  1. An attacker compromises the selected container image, replaces a mutable image tag, or exploits the running DolphinDB service.
  2. Attacker-controlled code executes inside the container.
  3. The code accesses the host directory through /dolphindb/etc.
  4. Because the bind mount is writable, the code modifies host configuration files.
  5. The modified configuration may provide unauthorized host access or disrupt host security controls.

Impact Assessment

A successful attacker could potentially modify authentication, networking, service, or security configuration under the host's /etc directory. The exact effect depends on host permissions, Docker user-namespace settings, and the files targeted, but a standard rootful Docker deployment may per ...[truncated 116 chars]

Remediation
View remediation

Remediation Suggestions

  • Do not mount the entire host /etc directory.

  • Identify the exact files required for license fingerprinting and mount only those files.

  • Mark every fingerprint-related mount read-only, for example:

    bash
    -v /etc/machine-id:/dolphindb/etc/machine-id:ro

  • Run the container as a dedicated non-root user where supported.

  • Enable Docker user-namespace remapping or use rootless Docker.

  • Add --read-only, --cap-drop=ALL, and --security-opt=no-new-privileges:true where compatible.

  • Document the specific host information exposed to the container and obtain explicit operator approval before mounting it.

T09 · Insecure Skill Coding Practices

Error
Location
deploy-dolphindb.sh:91
Finding

User-Controlled Directory Subjected to Recursive Permission Changes

Content
View full analysis

Vulnerability Details

File Location: deploy-dolphindb.sh:91-121
Vulnerability Type: Unsafe recursive filesystem permission modification
Risk Level: High

Vulnerable Code

bash
prepare_data_dir() {
    local DATA_DIR="$1"
    local IMAGE="$2"
    local VERSION="$3"
    
    log_info "准备数据目录：$DATA_DIR"
    
    # 检查目录是否为空
    if [ -z "$(ls -A $DATA_DIR 2>/dev/null)" ]; then
        log_info "数据目录为空，从镜像初始化..."
        
        # 创建临时容器复制文件
        local TEMP_CONTAINER="dolphindb_init_$$"
        
        docker create --name "$TEMP_CONTAINER" "${IMAGE}:${VERSION}" > /dev/null 2>&1
        
        # 复制 server 目录内容
        docker cp "${TEMP_CONTAINER}:/data/ddb/server/." "$DATA_DIR"
        
        # 删除临时容器
        docker rm "$TEMP_CONTAINER" > /dev/null 2>&1
        
        log_success "数据目录初始化完成"
    else
        log_warn "数据目录非空，跳过初始化"
    fi
    
    # 设置权限
    chmod -R 755 "$DATA_DIR"
    
    log_success "数据目录准备完成"
}

The path originates from the third command-line argument:

bash
local DATA_DIR="${3:-/Users/mac/Documents/dolphindb_docker_server}"

Technical Analysis

DATA_DIR is controlled by the caller and is passed to chmod -R 755 without canonicalization, allowlisting, ownership checks, symlink checks, or rejection of sensitive paths.

Quoting prevents shell word splitting but does not make the selected path safe. A caller can provide /, /etc, a home directory, an application directory, or another existing filesystem tree. Recursive mode 755 adds read and execute permissions for group and other users and may remove write bits previously required by legitimate files.

The same unvalidated path is also used as a docker cp destination and later as a container bind mount.

Attack Path

  1. An attacker or mistaken operator invokes the script with a sensitive path as argument three, such as /etc or a user's hom ...[truncated 765 chars]
Remediation
View remediation

Remediation Suggestions

  • Canonicalize the requested path using realpath before performing filesystem operations.
  • Reject /, /etc, /usr, /var, /home, user home roots, and other sensitive or pre-existing system paths.
  • Restrict data storage to an explicitly approved parent directory.
  • Reject symbolic links and verify that every relevant path component has the expected ownership.
  • Create a dedicated DolphinDB data directory with a restrictive mode such as 750 or 700.
  • Do not recursively alter existing files. Apply permissions only to directories and files created by this deployment.
  • Verify that the destination exists and is a directory before calling ls, docker cp, or chmod.
  • Refuse to proceed when the destination contains unrelated data.

T09 · Insecure Skill Coding Practices

Error
Location
deploy-dolphindb.sh:135
Finding

Arbitrary Existing Docker Container Can Be Stopped and Removed

Content
View full analysis

Vulnerability Details

File Location: deploy-dolphindb.sh:135-147
Vulnerability Type: Unvalidated destructive operation on a user-selected container
Risk Level: High

Vulnerable Code

bash
cleanup_container() {
    local CONTAINER_NAME="$1"
    
    log_info "清理旧容器：$CONTAINER_NAME"
    
    # 停止容器
    docker stop "$CONTAINER_NAME" 2>/dev/null || true
    
    # 删除容器
    docker rm "$CONTAINER_NAME" 2>/dev/null || true
    
    log_success "容器清理完成"
}

The target is selected through an undocumented fourth argument:

bash
local CONTAINER_NAME="${4:-dolphindb}"

Technical Analysis

The script unconditionally attempts to stop and delete the container named by CONTAINER_NAME. It does not verify that the target was created by this deployment, runs the expected DolphinDB image, or carries a deployment-specific ownership label.

Because the fourth command-line argument controls this value, any container accessible through the current Docker daemon can be selected. Docker access is commonly equivalent to highly privileged host access, so destructive operations must be narrowly scoped.

Suppressing errors with || true also causes the script to report successful cleanup regardless of whether the operations behaved as expected.

Attack Path

  1. An attacker or operator identifies the name of another workload on the same Docker daemon.
  2. The deployment script is invoked with that name as its fourth argument.
  3. cleanup_container sends a stop request to the unrelated container.
  4. The container is then removed.
  5. The script creates the DolphinDB container using the vacated name.

Impact Assessment

An attacker can terminate and remove unrelated application containers available to the invoking Docker identity. This can cause service interruption and loss of container-local data that was not stored in a volume.

The issue does not directly delete named volu ...[truncated 92 chars]

Remediation
View remediation

Remediation Suggestions

  • Use a fixed, deployment-specific container name unless customization is strictly required.

  • Label containers created by the script, for example:

    bash
    --label com.example.dolphindb-deployment=true

  • Before stopping or removing a container, inspect it and verify the expected label, image repository, and deployment identity.

  • Refuse to remove containers that are not owned by this deployment.

  • Require explicit confirmation or a dedicated --replace option before destructive replacement.

  • Validate custom names against Docker's permitted container-name syntax.

  • Do not suppress all cleanup errors; report whether a container existed and whether replacement succeeded.

T08 · Insecure Dependencies

Error
Location
deploy-dolphindb.sh:124
Finding

Remote Container Image Is Executed Without Digest Pinning or Provenance Verification

Content
View full analysis

Vulnerability Details

File Location: deploy-dolphindb.sh:124-135
Vulnerability Type: Mutable and unverified container dependency
Risk Level: High

Vulnerable Code

bash
pull_image() {
    local IMAGE="$1"
    local VERSION="$2"
    local FULL_IMAGE="${IMAGE}:${VERSION}"
    
    log_info "拉取 Docker 镜像：$FULL_IMAGE"
    
    # 检查是否已存在
    if docker image inspect "$FULL_IMAGE" > /dev/null 2>&1; then
        log_warn "镜像已存在，跳过拉取"
    else
        docker pull "$FULL_IMAGE"
    fi

The selected image is subsequently executed by tag:

bash
"${IMAGE}:${VERSION}"

Technical Analysis

The deployment relies on mutable Docker tags rather than immutable content digests. The VERSION tag is supplied through the first command-line argument, and the script performs no allowlist, digest validation, signature verification, or provenance check.

Even version-like tags can be reassigned by a registry publisher or changed following registry compromise. Skipping the pull when a local tag exists also means the effective image depends on unverified local Docker state.

This risk is amplified by the writable host mount and externally published service ports configured for the resulting container.

Attack Path

  1. An approved image tag is replaced upstream, a registry account is compromised, or an untrusted local image is assigned the expected tag.
  2. The script either pulls the altered image or accepts the pre-existing local image.
  3. The image is launched without checking its digest or signature.
  4. Attacker-controlled code executes inside the container.
  5. That code can access mounted host resources and expose network services using the privileges granted by the deployment.

Impact Assessment

A supply-chain compromise can result in arbitrary code execution inside the deployed container. Because the container receives a writable host /etc mount and a persistent data ...[truncated 245 chars]

Remediation
View remediation

Remediation Suggestions

  • Pin every approved image to an immutable digest:

    bash
    dolphindb/dolphindb@sha256:EXPECTED_DIGEST

  • Maintain a version-to-digest allowlist in reviewed source control.

  • Verify image signatures and provenance using an appropriate mechanism such as Sigstore Cosign or Docker Content Trust.

  • Reject arbitrary version values that are not present in the approved allowlist.

  • Inspect and validate locally cached images rather than trusting the presence of a matching tag.

  • Record the resolved digest in deployment logs for auditing and incident response.

  • Combine supply-chain controls with reduced container privileges and narrowly scoped read-only mounts.

T09 · Insecure Skill Coding Practices

Warning
Location
deploy-dolphindb.sh:172
Finding

DolphinDB Ports Are Published on All Host Network Interfaces

Content
View full analysis

Vulnerability Details

File Location: deploy-dolphindb.sh:172-173
Vulnerability Type: Unrestricted network service exposure
Risk Level: Medium

Vulnerable Code

bash
-p 8848:8848 \
-p 8849:8849 \

Technical Analysis

Docker port mappings that omit a host address generally bind on all host interfaces. Consequently, these mappings can expose DolphinDB on 0.0.0.0 and, depending on Docker and host configuration, IPv6 interfaces as well.

The project documentation presents the service as available through localhost, which may lead operators to incorrectly assume that remote access is not possible. Whether the service is reachable externally ultimately depends on host routing, Docker networking, and firewall policy.

Attack Path

  1. The script is run on a host connected to an untrusted network or assigned a public address.
  2. Docker publishes ports 8848 and 8849 on all available host interfaces.
  3. Network firewall rules permit access to one or both ports.
  4. A remote attacker discovers the exposed DolphinDB service.
  5. The attacker attempts unauthorized access, credential attacks, service exploitation, or denial of service.

Impact Assessment

This can expose the DolphinDB web interface and associated database service to remote systems. Depending on DolphinDB authentication and configuration, an attacker may gain access to database functionality or data, exploit a service vulnerability, or disrupt availability.

The exposure scope may include the local network or the Internet.

Remediation
View remediation

Remediation Suggestions

  • Bind ports to the loopback interface by default:

    bash
    -p 127.0.0.1:8848:8848 \
-p 127.0.0.1:8849:8849 \

  • Require an explicit option before allowing non-loopback exposure.

  • Document DolphinDB authentication requirements and ensure strong credentials are configured before remote access is enabled.

  • Restrict permitted source addresses using host or cloud firewall rules.

  • Use TLS or a secured reverse proxy where remote connectivity is required.

  • Clearly document the difference between loopback-only and externally reachable deployments.

SkillSpector

Vulnerability Patterns
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
  • MCP Least PrivilegeUnderdeclared Capability, Wildcard Permission, Missing Permission Declaration
  • MCP Tool PoisoningHidden Instructions, Unicode Deception, Parameter Description Injection
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
Findings (22)

Tp4

High
Category
MCP Tool Poisoning
Confidence
98% confidence
Finding

The skill's declared purpose focuses on architecture detection, memory sizing, and persistence, but it also instructs mounting the host /etc directory into the container. Exposing /etc gives the container access to sensitive host configuration and identity material, and the undeclared nature of that access makes the skill materially more dangerous because users may not realize they are granting broad host filesystem visibility.

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 24)May include surrounding context.

md
./deploy-dolphindb.sh

Ae1

High
Category
analysis-evasion
Confidence
100% confidence
Finding

Referenced artifact was not completely inspected

Content

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

md
./deploy-dolphindb.sh

Ae1

High
Category
analysis-evasion
Confidence
100% confidence
Finding

Referenced artifact was not completely inspected

Content

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

md
./deploy-dolphindb.sh

Ae1

High
Category
analysis-evasion
Confidence
100% confidence
Finding

Referenced artifact was not completely inspected

Content

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

md
./deploy-dolphindb.sh

Description-Behavior Mismatch

High
Category
Not specified by scanner
Confidence
99% confidence
Finding

The script bind-mounts the host /etc into the container (-v /etc:/dolphindb/etc) even though the stated purpose is Docker deployment and data persistence. This exposes sensitive host configuration, secrets, and network/account metadata to the containerized workload and greatly expands the blast radius if the image is compromised or behaves unexpectedly.

Content

No source excerpt is available for this finding.

Context-Inappropriate Capability

High
Category
Not specified by scanner
Confidence
99% confidence
Finding

Mounting host /etc into a container gives the container visibility into system configuration such as passwd/group data, resolver settings, hostnames, package config, and potentially credentials or trust stores. In the context of a generic deployment helper, this access is unjustified and can aid container escape chains, credential harvesting, reconnaissance, or tampering if combined with other weaknesses.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium
Category
Not specified by scanner
Confidence
95% confidence
Finding

The README explicitly advertises mounting the host /etc directory into the container for license handling, but gives no warning about exposing sensitive host configuration and credentials. A containerized process with access to host /etc may read secrets, system identity material, authentication configuration, or other sensitive files, significantly expanding impact if the container or image is compromised.

Content

No source excerpt is available for this finding.

Rp1

Medium
Category
MCP Rug Pull
Confidence
75% confidence
Finding

Docker image references without a specific tag (:latest is implicit) or digest (@sha256:...) can be silently replaced by a malicious image.

Content

No source excerpt is available for this finding.

Rp1

Medium
Category
MCP Rug Pull
Confidence
75% confidence
Finding

Docker image references without a specific tag (:latest is implicit) or digest (@sha256:...) can be silently replaced by a malicious image.

Content

No source excerpt is available for this finding.

Rp1

Medium
Category
MCP Rug Pull
Confidence
75% confidence
Finding

Docker image references without a specific tag (:latest is implicit) or digest (@sha256:...) can be silently replaced by a malicious image.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium
Category
Not specified by scanner
Confidence
98% confidence
Finding

The sample docker run command includes -v /etc:/dolphindb/etc, which directly exposes the host's /etc tree to the container without any warning or restriction. In the context of a deployment automation skill, users are likely to copy-paste this command verbatim, making the risky mount especially dangerous because it can enable host information disclosure and facilitate further compromise if the container is malicious or vulnerable.

Content

No source excerpt is available for this finding.

Rp1

Medium
Category
MCP Rug Pull
Confidence
75% confidence
Finding

Docker image references without a specific tag (:latest is implicit) or digest (@sha256:...) can be silently replaced by a malicious image.

Content

No source excerpt is available for this finding.

File System Enumeration

Medium
Category
Data Exfiltration
Confidence
60% confidence
Finding

Code scans file system directories looking for sensitive files. This could be reconnaissance for credential theft.

Content

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

lsof -i:8848

检查数据目录权限

ls -la /Users/mac/Documents/dolphindb_docker_server/

text

### 内存不足

Undeclared Tool Scope

Medium
Category
MCP Least Privilege
Confidence
88% confidence
Finding

The skill documents shell-based deployment behavior but does not declare any tool scope such as permissions or allowed-tools. That omission weakens reviewability and enforcement, because a consumer cannot easily tell that the skill is intended to invoke Docker and perform host-affecting operations before using it.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium
Category
Not specified by scanner
Confidence
97% confidence
Finding

The skill mentions license fingerprint collection but does not prominently warn that it achieves this by mounting the host /etc directory into the container. That lack of explicit warning undermines informed consent and can lead users to expose sensitive host configuration data without understanding the scope of access.

Content

No source excerpt is available for this finding.

Rp1

Medium
Category
MCP Rug Pull
Confidence
75% confidence
Finding

Docker image references without a specific tag (:latest is implicit) or digest (@sha256:...) can be silently replaced by a malicious image.

Content

No source excerpt is available for this finding.

Rp1

Medium
Category
MCP Rug Pull
Confidence
75% confidence
Finding

Docker image references without a specific tag (:latest is implicit) or digest (@sha256:...) can be silently replaced by a malicious image.

Content

No source excerpt is available for this finding.

Rp1

Medium
Category
MCP Rug Pull
Confidence
75% confidence
Finding

Docker image references without a specific tag (:latest is implicit) or digest (@sha256:...) can be silently replaced by a malicious image.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium
Category
Not specified by scanner
Confidence
95% confidence
Finding

The script silently mounts host /etc without warning or consent, so users may unknowingly grant the container access to sensitive host configuration. Even if the mount were operationally needed, the absence of disclosure increases the chance of unsafe deployment and reduces informed decision-making.

Content

No source excerpt is available for this finding.

Natural-Language Policy Violations

Low
Category
Not specified by scanner
Confidence
98% confidence
Finding

The skill documentation forces a specific language/locale for user-facing instructions, which can violate language-choice policy when no opt-in or alternative is provided. There is no indication that the skill is intentionally limited to a Chinese-speaking audience or region-specific context.

Content

No source excerpt is available for this finding.

Natural-Language Policy Violations

Low
Category
Not specified by scanner
Confidence
96% confidence
Finding

Comments, log messages, and user-facing status text are all written in Chinese, with no option for users to select another language. This creates a language policy issue because the skill imposes a locale choice rather than offering user opt-in or documenting a justified region-specific constraint.

Content

No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.