Security audit

Claws Temple Bounty 2.0

Security checks for vulnerabilities and agentic risk

Overview

This bounty skill is coherent, but it gives agents high-impact authority through mutable remote skills, persistent dependency replacement, chat-based keystore password collection, and automatic transaction flows.

Review this skill carefully before installing. It is not judged malicious, but it can modify persistent local skill dependencies, load mutable remote instructions for authenticated platform actions, request a keystore password in chat, and perform real token approval/vote operations automatically. Use only in an environment where you trust the publisher, the dependency sources, and the remote Task 4 service, and avoid pasting reusable secrets into the conversation.

A.I.G

Vulnerability Patterns

Skill Instruction HijackingAlters the agent's session goals or safety constraints when the skill loads
Remote Payload Retrieval and ExecutionFetches external code whose behavior can change after review
Insecure DependenciesIntroduces malicious components through unsafe dependency sources
Insecure Skill Coding PracticesFinds exploitable flaws such as hardcoded secrets or command injection
Agent Memory PoisoningWrites attacker-controlled rules into memory that affect later sessions

Findings (4)

T01 · Skill Instruction Hijacking

Error

Location: config/faction-proposals.json:14
Finding: Mandatory Promotional Output and External Traffic Diversion
Content: View full analysis
Remediation: View remediation

T03 · Remote Payload Retrieval and Execution

Error

Location: scripts/task4-live-skill-probe.sh:4
Finding: Mutable Remote Skill Instructions Loaded into an Authenticated Action Flow
Content: View full analysis
/dev/null 2>"/tmp/task4-probe-head.err"; then if remote_body="$(curl --fail --silent --show-error --location \ --connect-timeout "$CONNECT_TIMEOUT" \ --max-time "$MAX_TIME" \ "$REMOTE_SKILL_URL" 2>"/tmp/task4-probe-body.err")"; then if printf '%s' "$remote_body" | rg -qi '(^---)|(^# )|(name:)|(description:)|(skill)'; then echo "[task4-probe] remote live skill healthy" exit 0 fi ``` The Task 4 flow then directs the Agent to trust and use that remote content: ```text Load the live SHIT Skills integration skill only when both remote preflight and the required authenticated native action path are available. Continue with the specific native action the user needs: publish, edit, delete, comment, vote, like, or parse GitHub `SKILL.md`. ``` ### Technical Analysis The remote document is mutable after this bundle has been reviewed. The probe only checks whether its body superficially resembles a Skill document. It does not verify: - A cryptographic digest or digital signature. - A pinned release or immutable commit. - The final URL after redirects. - The semantics or permitted ...[truncated 2106 chars]
Remediation: View remediation

T08 · Insecure Dependencies

Error

Location: scripts/self-heal-local-dependency.sh:64
Finding: Unpinned Dependencies Replace Persistent Agent Skills Without Integrity Verification
Content: View full analysis
/dev/null 2>&1; then echo "[self-heal] git is required for repo-based install or upgrade: $repo_url" >&2 return 1 fi git clone --depth 1 "$repo_url" "$workdir/repo" >/dev/null 2>&1 || { echo "[self-heal] failed to clone dependency source repo: $repo_url" >&2 return 1 } printf '%s\n' "$workdir/repo" } ``` ```bash local target="$SKILLS_HOME/$dep" local source_path="" local source_root="" local temp_dir local env_value="${!env_name:-}" temp_dir="$(mktemp -d)" if [[ -n "$env_value" ]]; then if source_root="$(resolve_local_skill_path "$env_value" "$skill_subdir" 2>/dev/null)"; then source_path="$source_root" else echo "[self-heal] warning: $env_name points to an unusable local source, falling back to $repo_url" >&2 fi fi if [[ -z "$source_path" ]]; then source_root="$(clone_repo_source "$repo_url" "$temp_dir")" || { rm -rf "$temp_dir" return 1 } source_path="$(resolve_local_skill_path "$source_root" "$skill_subdir")" || { echo "[self-heal] could not resolve skill subdir '$skill_subdir' inside $repo_url" >&2 rm -rf "$temp_dir" return 1 } fi mkdir -p "$SKILLS_HOME" local temp_target="$SKILLS_HOME/.${dep}.tmp.$$" rm -rf "$temp_target" mkdir -p "$temp_target" cp -R "$source_path"/. "$temp_target"/ rm -rf "$target" mv "$temp_target" "$target" ``` The installation target is persistent Agent storage: ```bash SKILLS_HOME="${CODEX_HOME:-$HOME/.codex}/skills" ``` ### Technical Analysis The installer clones the current repository default branch with `--depth 1`. It does not pin a commit, release tag, content hash, or signed artifact. Consequently, the ...[truncated 2364 chars]
Remediation: View remediation

T09 · Insecure Skill Coding Practices

Error

Location: SKILL.md:97
Finding: CA Keystore Password Solicited Through the Conversational Channel
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
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

Findings (57)

Tp4

High

Category: MCP Tool Poisoning
Confidence: 99% confidence
Finding: The skill appears to validate bundle structure, parse manifests, scan text for forbidden references, compute hashes, and fail on packaging issues, none of which are implied by its public description. This kind of hidden validation logic can leak repository structure, create denial-of-service conditions for normal use, and mask broader file-system access behind a harmless-looking workflow description.
Content: No source excerpt is available for this finding.

Tp4

High

Category: MCP Tool Poisoning
Confidence: 99% confidence
Finding: The skill appears to validate bundle structure, parse manifests, scan text for forbidden references, compute hashes, and fail on packaging issues, none of which are implied by its public description. This kind of hidden validation logic can leak repository structure, create denial-of-service conditions for normal use, and mask broader file-system access behind a harmless-looking workflow description.
Content: No source excerpt is available for this finding.

Tp4

High

Category: MCP Tool Poisoning
Confidence: 99% confidence
Finding: The skill appears to validate bundle structure, parse manifests, scan text for forbidden references, compute hashes, and fail on packaging issues, none of which are implied by its public description. This kind of hidden validation logic can leak repository structure, create denial-of-service conditions for normal use, and mask broader file-system access behind a harmless-looking workflow description.
Content: No source excerpt is available for this finding.

Tp4

High

Category: MCP Tool Poisoning
Confidence: 99% confidence
Finding: The skill appears to validate bundle structure, parse manifests, scan text for forbidden references, compute hashes, and fail on packaging issues, none of which are implied by its public description. This kind of hidden validation logic can leak repository structure, create denial-of-service conditions for normal use, and mask broader file-system access behind a harmless-looking workflow description.
Content: No source excerpt is available for this finding.

Tp4

High

Category: MCP Tool Poisoning
Confidence: 98% confidence
Finding: The skill appears to validate bundle structure, parse manifests, scan text for forbidden references, compute hashes, and fail on packaging issues, none of which are implied by its public description. This kind of hidden validation logic can leak repository structure, create denial-of-service conditions for normal use, and mask broader file-system access behind a harmless-looking workflow description.
Content: No source excerpt is available for this finding.

Tp4

High

Category: MCP Tool Poisoning
Confidence: 99% confidence
Finding: The skill appears to validate bundle structure, parse manifests, scan text for forbidden references, compute hashes, and fail on packaging issues, none of which are implied by its public description. This kind of hidden validation logic can leak repository structure, create denial-of-service conditions for normal use, and mask broader file-system access behind a harmless-looking workflow description.
Content: No source excerpt is available for this finding.

Description-Behavior Mismatch

High

Category: Not specified by scanner
Confidence: 97% confidence
Finding: The example content redirects the user from the declared Claws Temple Bounty 2.0 workflow into an unrelated 'SHIT Skills Native Flow'. In an agent skill, this kind of scope and brand mismatch is dangerous because it can cause the agent to route users into unintended third-party actions, collect unrelated data, or perform actions outside the user’s expected workflow.
Content: No source excerpt is available for this finding.

Description-Behavior Mismatch

High

Category: Not specified by scanner
Confidence: 98% confidence
Finding: The example redirects users from the declared Claws Temple Bounty 2.0 workflow into an unrelated 'SHIT Skills' native workflow, creating a scope-confusion and instruction-integrity problem. In an agent skill, this can cause the agent to perform actions under a different brand, collect unrelated credentials or repo data, and violate user expectations about what workflow is being executed.
Content: No source excerpt is available for this finding.

Description-Behavior Mismatch

High

Category: Not specified by scanner
Confidence: 96% confidence
Finding: The flow says it should be used for 'Task 2 or any partner-finding request,' which materially broadens scope beyond the branded Claws Temple Bounty context defined in the manifest. That can cause the agent to invoke this branded workflow in unrelated contexts, leading to inappropriate collection of identity/sign-in state and steering users into a dependency-driven process they did not request.
Content: No source excerpt is available for this finding.

Context-Inappropriate Capability

High

Category: Not specified by scanner
Confidence: 96% confidence
Finding: The script can clone external repositories and install their contents into the user's skills directory, effectively importing executable/agent-controlled skill material from outside the packaged skill. That behavior is broader than the stated Claws Temple workflow purpose and creates a supply-chain trust boundary: a compromised repo, changed upstream content, or typo/misconfiguration could replace local skills with unreviewed content.
Content: No source excerpt is available for this finding.

Undeclared Tool Scope

Medium

Category: MCP Least Privilege
Confidence: 88% confidence
Finding: The skill explicitly directs the host to read files and, when possible, run a shell helper script, but it declares no tool scope such as allowed-tools or permissions. That creates a capability mismatch where a reviewer or runtime cannot reliably constrain file and shell access, increasing the risk of over-privileged execution or accidental command use.
Content: No source excerpt is available for this finding.

Behavior Manipulation

Medium

Category: Prompt Injection
Confidence: 75% confidence
Finding: Subtle instructions detected that may alter agent decision-making or introduce hidden biases.
Content: Scanner excerpt · SKILL.md (reported line 90)May include surrounding context.
md
- for Task 2, once identity-entry onboarding finishes and dependency queue preflight can proceed, continue into the formal queue path; do not suggest skipping Task 2 or replacing queue with social posting - for Task 2, when `resonance-contract` is missing or below `4.0.0`, first try install or upgrade from the dependency source catalog; do not ask the user to provide an install source - for Task 2, if the user provides `email`, `Address`, nickname, or similar non-`user ID` input for targeted match, correct the input and offer either `provide the other user's user ID` or `switch to open partner search` - for Task 2, never tell the user to find a partner through legacy community-brand wording, legacy address-routing wording, or extra platform names outside Telegram and X; keep the visible layer focused on `user ID`, `targeted match`, `open partner search`, Telegram, and X - for Task 2, keep `CA only`, `counterparty_ca_hash`, and `queue` in maintainer-facing details; the default visible layer should call the identifier `user ID` - for Task 3, require the dependency contract from `config/faction-proposals.json`, including the TomorrowDAO minimum dependency version, the Portkey CA write minimum dependency version, token-balance precheck, token-allowance precheck, approve payload fields, vote payload fields, and success Telegram follow-up - for Task 3, treat `vote_payload.proposal_id_field = proposalId` as the dependency-tool input alias for `tomorrowdao_dao_vote`, not as a raw contract ABI field name

Missing User Warnings

Medium

Category: Not specified by scanner
Confidence: 90% confidence
Finding: Task 3 instructs collection of a CA keystore password and automated real write operations, but the visible layer is explicitly told to present the process as automatic and ask for the password only when needed, without a strong user-facing security warning. That combination can socially normalize entering sensitive credentials into the agent and reduce informed consent for actions with financial or governance consequences.
Content: No source excerpt is available for this finding.

Autonomous Decision Making

Medium

Category: Excessive Agency
Confidence: 81% confidence
Finding: The skill instructs automatic retries and automatic continuation of approval and vote submission without asking the user whether to retry or use a manual path. In the context of real write operations, this can lead to repeated transaction attempts, unintended duplicate actions, or reduced user control over sensitive state-changing operations.
Content: Scanner excerpt · SKILL.md (reported line 108)May include surrounding context.
md
- for Task 3, prefer one consistent verified `CA` write transport for both `Approve` and `Vote`; do not mix a successful `CA` approval path with a different direct vote path unless the same transport is unavailable - for Task 3, once `CA` is selected, direct target-contract send and env or private-key fallback are forbidden; if TomorrowDAO direct send returns `SIGNER_CA_DIRECT_SEND_FORBIDDEN`, continue through the explicit Portkey CA forward transport instead of stopping - for Task 3, stop with an unsupported `CA` transport blocker only when the explicit Portkey CA forward transport is unavailable, below minimum version, or cannot continue automatically in the current host - for Task 3, use bounded automatic retries with state reconciliation for both `Approve` and `Vote`; do not ask the user whether they want manual completion or another retry - for Task 3, if a non-preferred vote send path returns `NODEVALIDATIONFAILED` with `Insufficient allowance` after allowance is already sufficient, treat that as a transport mismatch and switch back to the same verified `CA` write transport used by `Approve` - for Task 3, treat `proposal my-info` as an auxiliary reconciliation source only; primary confirmation should come from mined receipts, vote logs, and allowance or balance deltas - for Task 3, keep retry timing, receipt polling, and allowance reconciliation in maintainer-facing details; the visible layer should only describe the current automatic stage naturally

Missing User Warnings

Medium

Category: Not specified by scanner
Confidence: 91% confidence
Finding: This configuration wires the skill to perform real token approval and DAO vote submission on a production environment, including send-mode execution and explicit approve/vote tool bindings, but the file contains no user-facing disclosure, consent checkpoint, or warning text about spending/authorizing tokens. In the context of a branded workflow that nudges users through a fixed multi-step path, this increases the risk that users are steered into on-chain actions without clearly understanding that they are granting allowance and casting a binding vote.
Content: No source excerpt is available for this finding.

Natural-Language Policy Violations

Medium

Category: Not specified by scanner
Confidence: 94% confidence
Finding: The schema requires success_telegram_template to contain exactly zh-CN and en keyed content, which hard-codes supported languages in a way that may force a specific locale policy. Because the file provides no indication of user opt-in, language selection, or region-specific justification, this is a natural-language locale policy concern.
Content: No source excerpt is available for this finding.

Natural-Language Policy Violations

Medium

Category: Not specified by scanner
Confidence: 94% confidence
Finding: The success_bonus_note object mandates zh-CN and en fields, embedding a fixed language policy into the configuration. Without any accompanying statement that this is optional, user-selectable, or required for a specific region, it can violate organizational language/locale expectations.
Content: No source excerpt is available for this finding.

Natural-Language Policy Violations

Medium

Category: Not specified by scanner
Confidence: 93% confidence
Finding: The display_name structure requires only zh-CN and en, which codifies a fixed language set for user-facing content. This creates a locale restriction without evidence of user choice or a documented business/regional justification.
Content: No source excerpt is available for this finding.

Natural-Language Policy Violations

Medium

Category: Not specified by scanner
Confidence: 93% confidence
Finding: The schema requires core_stance text in zh-CN and en only, which is a natural-language locale constraint embedded in configuration. Since no opt-in or rationale is present in this file, the restriction may conflict with policy requiring user language choice or documented justification.
Content: No source excerpt is available for this finding.

Natural-Language Policy Violations

Medium

Category: Not specified by scanner
Confidence: 92% confidence
Finding: The instruction "Use this file when output_language = en" establishes a language-specific output policy. Under the policy criteria, forcing a specific language without user opt-in can be a natural-language policy violation unless the locale constraint is explicitly justified or optional.
Content: No source excerpt is available for this finding.

Natural-Language Policy Violations

Medium

Category: Not specified by scanner
Confidence: 97% confidence
Finding: Line L03 instructs use of this file whenever output_language = zh-CN, which imposes a specific locale behavior. The file does not indicate any user opt-in, fallback, or language-choice mechanism, so it constitutes a natural-language locale policy constraint.
Content: No source excerpt is available for this finding.

Missing User Warnings

Medium

Category: Not specified by scanner
Confidence: 95% confidence
Finding: The example explicitly tells users to post their current step, error, and key context in public channels (Telegram and X) without any warning to avoid sharing sensitive identifiers, account details, screenshots, or other personal data. In this workflow, troubleshooting context may naturally include user IDs, sign-in state, recovery details, or wallet/account-related metadata, creating a realistic privacy and social-engineering exposure risk.
Content: No source excerpt is available for this finding.

Natural-Language Policy Violations

Medium

Category: Not specified by scanner
Confidence: 93% confidence
Finding: The file is entirely presented as a Chinese-only user-facing skill example, and it does not state that language selection is optional or limited to a documented region-specific context. Under the policy rule, forcing a specific language without user opt-in is a natural-language policy violation.
Content: No source excerpt is available for this finding.

Missing User Warnings

Medium

Category: Not specified by scanner
Confidence: 94% confidence
Finding: The skill explicitly instructs the user to provide a CA keystore password so the workflow can continue, but it does not warn against sharing the password in chat or direct the user to a secure credential-entry mechanism. In an agent workflow, this creates a real risk of credential harvesting, accidental plaintext disclosure, or reuse of a highly sensitive secret that could unlock signing capability or broader account access.
Content: No source excerpt is available for this finding.

Missing User Warnings

Medium

Category: Not specified by scanner
Confidence: 95% confidence
Finding: The skill explicitly instructs the agent to request a CA keystore password and then automatically perform authorization, oath submission, and result confirmation. Collecting a keystore password inside a conversational workflow is highly sensitive because it normalizes credential disclosure to the agent and could enable account compromise or unauthorized signing if the password is mishandled, logged, or reused.
Content: No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.