Knowledge Sync

• Outcome: Review
• Latest audit: Sep 12, 2026 · 1:58 AM UTC
• Version: 1.0.0

Overview

This skill performs the advertised synchronization work, but it can continuously copy, delete, commit, and upload workspace content with limited guardrails or warnings.

Review carefully before installing or enabling this skill. Only use it on a narrowly scoped workspace with no secrets or private credentials, inspect the Git remote and Nutstore/Obsidian destinations, remove --no-verify, replace git add -A with an allowlist, add dry-run/confirmation steps, and avoid enabling the systemd service or cron jobs until you understand exactly what will be copied, deleted, committed, and uploaded.

A.I.G

Vulnerability Patterns

• 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
• Embedded Malicious Code: Ships malicious scripts inside the skill and executes them locally

Findings (5)

T09 · Insecure Skill Coding Practices

Error

• Location: scripts/git-auto-push.sh:6
• Finding: Unrestricted Workspace Content Is Automatically Committed and Uploaded<![CDATA[ ## Vulnerability Details **File Location**: `scripts/git-auto-push.sh`, lines 6-29 **Vulnerability Type**: Overly broad file collection and external transmission **Risk Level**: High ### Vulnerable Code ```bash cd /home/admin/.openclaw/workspace LOG_FILE="/home/admin/.openclaw/logs/git-auto-push.log" log() { echo "[$(date '+%Y-%m-%d %H:%M:%S')] $1" | tee -a "$LOG_FILE" } # Check whether changes exist if git diff --quiet && git diff --cached --quiet; then exit 0 fi log "Changes detected; starting commit..." # Stage every change git add -A # Commit COMMIT_MSG="auto: $(date '+%Y-%m-%d %H:%M')" git commit -m "$COMMIT_MSG" --no-verify 2>&1 | tee -a "$LOG_FILE" # Upload log "Pushing to Gitee..." git push origin main 2>&1 | tee -a "$LOG_FILE" ``` ### Technical Analysis The script operates on the entire `/home/admin/.openclaw/workspace` repository and invokes `git add -A`, which stages every tracked and untracked change not excluded by Git configuration. It does not restrict collection to the six synchronization directories documented by the Skill. There is no validation of `.gitignore`, no sensitive-file denylist, no secret scanning, no remote URL verification, and no confirmation before transmission. The use of `--no-verify` also bypasses local commit hooks that might otherwise enforce security checks. When combined with the documented five-minute cron schedule, any sensitive file introduced into the repository can be committed and transmitted automatically. ### Attack Path 1. A credential, API key, private note, configuration file, agent memory file, or generated secret is created anywhere in the workspace repository. 2. The file is not excluded by the repository's current Git ignore rules. 3. The scheduled script detects a repository change. 4. `git add -A` stages the sensitive file. 5. `git commit --no-verify` bypasses local commit verification hooks. 6. `git push origin main` uploads the content to the configured remote. 7. Anyone ...[truncated 724 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Replace `git add -A` with an explicit allowlist of approved synchronization paths. 2. Verify that staged paths remain under the intended workspace directories before committing. 3. Run a secret scanner against staged content and abort on credentials, private keys, tokens, or sensitive configuration. 4. Do not use `--no-verify`; preserve repository security and policy hooks. 5. Validate and display the Git remote URL before enabling scheduled uploads. 6. Require explicit user approval during initial setup and clearly disclose which directories will be uploaded. 7. Provide a dry-run mode that lists files that would be staged and transmitted. 8. Document required `.gitignore` rules, but do not rely on ignore rules as the sole security boundary. 9. Use narrowly scoped Git credentials with access only to the intended repository. ]]>

T09 · Insecure Skill Coding Practices

Error

• Location: scripts/sync-realtime.sh:166
• Finding: Initial Cloud Synchronization Bypasses the Declared Exclusion Rules<![CDATA[ ## Vulnerability Details **File Location**: `scripts/sync-realtime.sh`, lines 166-186 **Vulnerability Type**: Sensitive data exposure through inconsistent filtering **Risk Level**: High ### Vulnerable Code The script declares exclusion patterns: ```bash EXCLUDE_PATTERNS=( "*.log" "*.tmp" "*.swp" ".git" "node_modules" "__pycache__" "*.pyc" ".DS_Store" ) ``` However, the initial full synchronization does not apply those patterns: ```bash # Initial full synchronization log "${BLUE}📦 Executing initial full synchronization...${NC}" for dir in "${WATCH_DIRS[@]}"; do if [ -d "$WORKSPACE_DIR/$dir" ]; then rsync -av --delete "$WORKSPACE_DIR/$dir/" "$NUTSTORE_DIR/$dir/" 2>/dev/null || \ cp -r "$WORKSPACE_DIR/$dir/"* "$NUTSTORE_DIR/$dir/" 2>/dev/null || true log "${GREEN}✓ Initial synchronization: $dir${NC}" fi done # Synchronize to the Obsidian directory if [ -d "/home/admin/Nutstore/我的知识" ]; then log "${BLUE}📚 Synchronizing to the Obsidian directory...${NC}" for dir in "articles" "docs" "memory" "learnings"; do if [ -d "$WORKSPACE_DIR/$dir" ]; then rsync -av --delete "$WORKSPACE_DIR/$dir/" "$OBSIDIAN_DIR/$dir/" 2>/dev/null || \ cp -r "$WORKSPACE_DIR/$dir/"* "$OBSIDIAN_DIR/$dir/" 2>/dev/null || true log "${GREEN}✓ Obsidian synchronization: $dir${NC}" fi done fi ``` ### Technical Analysis The `EXCLUDE_PATTERNS` array is consulted by `should_exclude` during event-driven single-file synchronization. It is not passed to either initial `rsync` invocation. Consequently, the initial synchronization copies content that later event handling would attempt to exclude. This can include temporary files, nested `.git` directories, bytecode, hidden files, or other sensitive content under the watched directories. The fallback `cp -r` path also lacks equivalent filtering. The destination directories are located under Nutstore, meaning files ...[truncated 1284 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Apply the same exclusion policy to every `rsync` operation using explicit, consistently maintained `--exclude` rules or a protected exclude file. 2. Ensure the fallback copy operation enforces identical filtering; preferably remove the fallback if equivalent security behavior cannot be guaranteed. 3. Use an allowlist of approved directories and file types rather than relying only on exclusions. 4. Exclude credentials, private keys, environment files, hidden configuration, nested repositories, caches, temporary files, and logs by default. 5. Perform a dry run before the first synchronization and display every file that will be copied. 6. Require explicit user approval before synchronizing memory or configuration content to cloud-backed destinations. 7. Add automated tests verifying that initial and event-driven synchronization enforce identical filters. 8. Clearly document that Nutstore and Obsidian destinations may propagate data to external devices or cloud services. ]]>

T09 · Insecure Skill Coding Practices

Warning

• Location: scripts/sync-realtime.sh:212
• Finding: Predictable Shared PID File Can Cause an Unrelated Process to Be Terminated<![CDATA[ ## Vulnerability Details **File Location**: `scripts/sync-realtime.sh`, lines 212-219 **Vulnerability Type**: Unsafe temporary file and unvalidated process signaling **Risk Level**: Medium ### Vulnerable Code ```bash PID_FILE="/tmp/sync-realtime.pid" ``` ```bash stop() { if [ -f "$PID_FILE" ]; then local pid=$(cat "$PID_FILE") if kill -0 "$pid" 2>/dev/null; then log "${YELLOW}🛑 Stopping real-time synchronization process (PID: $pid)${NC}" kill "$pid" rm -f "$PID_FILE" log "${GREEN}✅ Stopped${NC}" ``` The daemon writes to the same predictable path: ```bash echo $$ > "$PID_FILE" ``` ### Technical Analysis The script stores process state in a fixed path under the shared `/tmp` directory. It neither creates the file securely nor verifies its ownership, permissions, type, or resistance to symbolic-link manipulation. During `stop`, the script trusts the file contents as a PID. `kill -0` only verifies that a process with the supplied PID exists and is signalable; it does not verify that the process is the synchronization daemon. PID reuse or attacker-controlled file contents can therefore direct the subsequent `kill` command at another process. The operating system still enforces signal permissions, so the script generally cannot terminate a process that the invoking user is not allowed to signal. ### Attack Path 1. Another local user creates or replaces `/tmp/sync-realtime.pid`, or a stale PID file remains after an abnormal termination. 2. The file contains the PID of an unrelated process owned by the user who will invoke the script. 3. The user runs `sync-realtime.sh stop` or `restart`. 4. `kill -0` succeeds because the unrelated process exists. 5. The script invokes `kill` without validating the target process identity. 6. The unrelated process receives `SIGTERM` and may terminate, causing denial of service or loss of unsaved work. A symbolic link at the predictable path may al ...[truncated 481 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Store the PID file in a user-private runtime directory such as `$XDG_RUNTIME_DIR`, not shared `/tmp`. 2. Create the runtime directory and PID file with restrictive permissions. 3. Reject symbolic links and files not owned by the current user. 4. Use a locking mechanism such as `flock` to prevent multiple daemon instances. 5. Before signaling, validate that `/proc/$pid/cmdline` or `/proc/$pid/exe` corresponds to this synchronization script. 6. Record additional process identity information, such as the process start time, to mitigate PID reuse. 7. Install cleanup traps for normal exit and termination signals. 8. Prefer systemd's native process supervision and stop behavior when the daemon is run as a user service. ]]>

T09 · Insecure Skill Coding Practices

Warning

• Location: scripts/git-auto-push.sh:29
• Finding: Git Push Failures Are Misreported Because Pipeline Status Is Not Preserved<![CDATA[ ## Vulnerability Details **File Location**: `scripts/git-auto-push.sh`, lines 29-36 **Vulnerability Type**: Incorrect shell pipeline error handling **Risk Level**: Medium ### Vulnerable Code ```bash git push origin main 2>&1 | tee -a "$LOG_FILE" if [ $? -eq 0 ]; then log "✅ Push successful" else log "❌ Push failed; attempting pull and retry..." git pull --rebase origin main 2>&1 | tee -a "$LOG_FILE" git push origin main 2>&1 | tee -a "$LOG_FILE" fi ``` ### Technical Analysis In Bash, the exit status of a pipeline is the exit status of its final command unless `set -o pipefail` is enabled. Here, `$?` normally represents the status of `tee`, not `git push`. If `git push` fails because of authentication errors, network failure, branch protection, repository rejection, or remote conflicts, `tee` may still write the output successfully and return zero. The script then records a successful push and skips its recovery branch. The same error-handling weakness affects the retry commands because their statuses are not validated independently. ### Attack Path 1. The Git remote becomes unreachable or rejects the update. 2. `git push origin main` exits with a nonzero status. 3. `tee` successfully appends the error output to the log and exits with status zero. 4. `$?` evaluates to zero. 5. The script logs that the push succeeded. 6. The pull-and-retry branch is not executed. 7. Scheduled runs may continue to provide misleading success indications while remote backups remain stale. ### Impact Assessment This flaw primarily affects integrity and availability. Users may believe that remote backups and multi-device synchronization are current when the remote repository has not received recent changes. It does not directly grant an attacker additional operating-system privileges. An attacker capable of disrupting or rejecting Git traffic could, however, exploit the misleading status behavior to prolong undetected backup failure. ]]>
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Enable strict pipeline handling near the start of the script: ```bash set -euo pipefail ``` 2. Alternatively, capture Git's pipeline status explicitly with `${PIPESTATUS[0]}` immediately after the pipeline. 3. Check the status of the pull and second push independently. 4. Return a nonzero exit status if all push attempts fail so cron or service monitoring can detect the problem. 5. Emit a distinct alert after repeated failures instead of relying only on a local log. 6. Add tests covering authentication failure, remote rejection, network failure, and merge conflicts. ]]>

T09 · Insecure Skill Coding Practices

Warning

• Location: scripts/sync-realtime.sh:166
• Finding: Destructive Mirroring Uses --delete Without Destination Safety Validation<![CDATA[ ## Vulnerability Details **File Location**: `scripts/sync-realtime.sh`, lines 166-186 **Vulnerability Type**: Unsafe destructive file synchronization **Risk Level**: Medium ### Vulnerable Code ```bash for dir in "${WATCH_DIRS[@]}"; do if [ -d "$WORKSPACE_DIR/$dir" ]; then rsync -av --delete "$WORKSPACE_DIR/$dir/" "$NUTSTORE_DIR/$dir/" 2>/dev/null || \ cp -r "$WORKSPACE_DIR/$dir/"* "$NUTSTORE_DIR/$dir/" 2>/dev/null || true log "${GREEN}✓ Initial synchronization: $dir${NC}" fi done ``` The same destructive option is used for the Obsidian destination: ```bash for dir in "articles" "docs" "memory" "learnings"; do if [ -d "$WORKSPACE_DIR/$dir" ]; then rsync -av --delete "$WORKSPACE_DIR/$dir/" "$OBSIDIAN_DIR/$dir/" 2>/dev/null || \ cp -r "$WORKSPACE_DIR/$dir/"* "$OBSIDIAN_DIR/$dir/" 2>/dev/null || true log "${GREEN}✓ Obsidian synchronization: $dir${NC}" fi done ``` ### Technical Analysis The `--delete` option removes files from the destination when no corresponding source file exists. The script does not canonicalize and validate the destination, verify ownership or mount state, require a destination marker, or perform a dry run before deletion. Although the paths are hard-coded, local filesystem changes, symbolic links, bind mounts, configuration edits, or unexpected destination contents can cause the synchronization target to contain unrelated data. Running the script in that state can remove destination-only files. The per-directory synchronization path in `sync_file` also uses `rsync -av --delete`, so destructive behavior is not limited to initial startup. ### Attack Path 1. A destination directory is replaced, redirected, mounted over, or populated with files that are not present in the workspace source. 2. The daemon starts or receives a directory-change event. 3. The script invokes `rsync -av --delete` against the destination. 4. `rsync` identifies destination-only files. 5. Tho ...[truncated 631 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Disable `--delete` by default and require an explicit user option to enable destructive mirroring. 2. Resolve source and destination paths with `realpath` and verify that they remain under approved roots. 3. Reject symbolic-link destinations and unexpected mount points. 4. Require a uniquely named marker file in each authorized destination before performing deletion. 5. Verify destination ownership and permissions before every destructive synchronization. 6. Perform and display an initial `rsync --dry-run --delete` preview for user approval. 7. Use `--backup` and `--backup-dir` or filesystem snapshots to make deletions recoverable. 8. Set deletion limits or abort when the number or proportion of planned deletions exceeds a safe threshold. 9. Do not suppress all `rsync` errors; log failures and abort rather than silently continuing. ]]>

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Tool Misuse: Tool Parameter Abuse, Chaining Abuse, Unsafe Defaults
• Rogue Agent: Self-Modification, Session Persistence
• Trigger Abuse: Overly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
• MCP Tool Poisoning: Hidden Instructions, Unicode Deception, Parameter Description Injection

Findings (15)

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 94% confidence
• Finding: The description partially matches the code because it does perform real-time file monitoring with inotifywait and synchronizes content into Nutstore-backed directories. However, the declared description overstates and misstates key capabilities. There is no Git integration at all: no git commands, no push/pull, and no repository state handling. The code also introduces a specific Obsidian mirror destination that is not mentioned in the declared purpose. Its actual scope is a host-local sync daemon for a fixed workspace path copying files into fixed Nutstore directories, not a generalized knowledge-base synchronization system across servers and devices. Therefore the description does not accurately represent the actual behavior.

Tool Parameter Abuse

High

• Category: Tool Misuse

Content

# 提交
COMMIT_MSG="🤖 auto: $(date '+%Y-%m-%d %H:%M')"
git commit -m "$COMMIT_MSG" --no-verify 2>&1 | tee -a "$LOG_FILE"

# 推送
log "⬆️  推送到 Gitee..."

• Confidence: 96% confidence
• Finding: Using 'git commit --no-verify' bypasses local Git hooks such as pre-commit and commit-msg checks, which are often used to enforce secret scanning, policy validation, and other security controls. In an automated synchronization workflow, this increases the chance that sensitive data, malformed commits, or otherwise policy-violating content will be committed and then propagated to the remote repository.

Missing User Warnings

Medium

• Confidence: 93% confidence
• Finding: The README promotes continuous synchronization and automated Git push/pull behavior but does not warn users that local file contents may be transmitted to third-party services or overwritten by remote changes. In a knowledge-sync skill, this omission is security-relevant because users may unintentionally expose sensitive notes, credentials, or internal documents and may also trigger unintended repository updates across devices.

Session Persistence

Medium

• Category: Rogue Agent

Content

### 1. 实时同步

```bash
systemctl --user enable sync-realtime.service
systemctl --user start sync-realtime.service
```

• Confidence: 80% confidence
• Finding: The README instructs users to enable a persistent user-level systemd service, which causes the synchronization process to run automatically beyond the current session. In the context of a real-time sync tool, persistence increases risk because data transfer and file monitoring continue unattended, potentially syncing sensitive content or propagating bad changes without ongoing user awareness.

Missing User Warnings

Medium

• Confidence: 94% confidence
• Finding: The skill promotes automatic synchronization, backup, and multi-device consistency but does not warn that files may be continuously copied, transmitted to remote services, or overwritten by incoming changes. In a knowledge-base context, this can expose sensitive notes, credentials, or internal documents through unintended replication to Git remotes or cloud sync providers.

Missing User Warnings

Medium

• Confidence: 95% confidence
• Finding: The quick-start commands immediately enable and start a persistent background service that continuously monitors files, yet no caution is given about ongoing monitoring, persistence across sessions, or unintended synchronization of newly created content. This is dangerous because users may activate it before understanding scope, exclusions, or how to stop the service, causing silent propagation of sensitive data.

Session Persistence

Medium

• Category: Rogue Agent

Content

```bash
# 启用实时同步服务
systemctl --user enable sync-realtime.service
systemctl --user start sync-realtime.service
```

• Confidence: 84% confidence
• Finding: Enabling a user-level systemd service creates persistence so the synchronization behavior continues across logins and restarts. In this context, persistence increases risk because a user may unknowingly leave continuous monitoring and sync active, causing ongoing data transmission or replication beyond the initial session.

Missing User Warnings

Medium

• Confidence: 96% confidence
• Finding: Documenting unattended cron-based git push/pull without warning users means repository contents may be periodically sent to a remote and remote changes may be automatically applied locally. In a knowledge-sync skill, that creates real risk of confidential data leakage, accidental publication, and silent overwrite/conflict propagation across devices.

Vague Triggers

Medium

• Confidence: 85% confidence
• Finding: The manifest advertises continuous file monitoring, automatic Git push/pull, and multi-device synchronization, but it does not describe scope limits, consent requirements, protected paths, or conditions under which syncing is enabled. In an automation skill, this can lead to unintended propagation of sensitive knowledge-base contents, accidental syncing of secrets, or unsafe autonomous network actions if the surrounding implementation follows the broad behavior implied by the metadata.

Missing User Warnings

Medium

• Confidence: 89% confidence
• Finding: This script automatically stages, commits, rebases, and pushes repository changes with no user confirmation, dry-run mode, or guardrails. In a knowledge-sync skill that runs continuously across devices, that behavior can unintentionally publish sensitive files, overwrite local work during rebase, or propagate malicious/accidental changes quickly across systems.

Missing User Warnings

Medium

• Confidence: 95% confidence
• Finding: The initial sync uses rsync --delete to mirror workspace content into backup/sync targets, which will delete files in the destination that are not present in the source. In a real-time knowledge-sync skill, this can cause unintended data loss across synced directories, especially if the destination contains manually added files, stale state, or if the source is temporarily incomplete or misconfigured.

Natural-Language Policy Violations

Low

• Confidence: 88% confidence
• Finding: The primary descriptive text is presented in Chinese, and the rest of the document also relies heavily on Chinese labels and instructions. There is no indication that the skill is region-specific or that users can opt into this locale, which may violate language choice expectations.

Natural-Language Policy Violations

Low

• Confidence: 77% confidence
• Finding: Natural-language policy checks apply to all file types. The user-facing description and feature strings are written in Chinese, but the manifest does not indicate that the skill is intended only for Chinese-speaking users or that language can be selected, which may amount to an implicit language constraint without opt-in.

Natural-Language Policy Violations

Low

• Confidence: 93% confidence
• Finding: Comments and log strings such as the title and status messages are written only in Chinese, which imposes a specific language on users and operators of the skill. The file does not indicate that this is a region-specific tool or provide any opt-in or alternative locale.

Natural-Language Policy Violations

Low

• Confidence: 92% confidence
• Finding: User-facing comments, status messages, and usage text are written exclusively in Chinese, including startup, error, and command help output. This imposes a specific language on users without any opt-in or locale selection mechanism, which matches the language/locale policy violation criteria.

Static analysis

No suspicious patterns detected.