Back to skill

Security audit

ThreadClaw FastAPI (Queue + Publish)

Security checks for vulnerabilities and agentic risk

Overview

This skill is coherent and not malicious, but it can send content, identity metadata, and a queue secret to a backend that may publish Threads posts without clear confirmation safeguards.

Review this before installing if the backend can publish publicly. Configure only a trusted HTTPS backend for non-local use, keep the queue secret scoped and revocable, and require the agent or workflow to ask for explicit approval before queueing, scheduling, or publishing. Avoid sending Telegram identifiers unless your backend truly needs them.

Vulnerability Patterns
  • 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
  • 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 (2)

T09 · Insecure Skill Coding Practices

Warning
Location
SKILL.md:16
Finding
Queue Secret May Be Transmitted over Plaintext HTTP<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 16-18, 48-51, and 106-108 **Vulnerability Type**: Plaintext transmission of authentication credentials **Risk Level**: Medium ### Vulnerable Code ```markdown - `THREADS_FASTAPI_BASE_URL` (example: `http://127.0.0.1:8000`) - `THREADS_QUEUE_SECRET` (the value to send as `X-Queue-Secret`, only for `/threads/publish`) - Optional: `THREADS_TENANT_ID` (default: `agency_paris`) ``` ```markdown - URL: `{BASE}/api/v1/threads/publish` - Method: `POST` - Headers: `X-Queue-Secret: <THREADS_QUEUE_SECRET>` - Body: JSON payload (see below) ``` ```markdown ## Safety - Never forward secrets from chat into shell commands except as the `-QueueSecret` argument. - Do not log the secret. - Validate that `BaseUrl` is an http(s) URL. ``` ### Technical Analysis The skill permits any syntactically valid HTTP or HTTPS base URL while directing the agent to transmit `THREADS_QUEUE_SECRET` in the `X-Queue-Secret` request header. The documented HTTP example uses a loopback address, where plaintext HTTP may be acceptable, but the validation requirement does not restrict HTTP to loopback destinations. If a remote `http://` URL is configured, the authentication secret, post content, and associated metadata are transmitted without transport encryption. A network-positioned attacker could inspect or modify this traffic. The skill also does not specify redirect validation, so an initially trusted endpoint could potentially redirect a request to an insecure or unintended destination, depending on HTTP tool behavior. ### Attack Path 1. An attacker influences the gateway configuration, configuration guidance, DNS/network path, or user choice so that `THREADS_FASTAPI_BASE_URL` points to a remote plaintext HTTP endpoint. 2. A user asks the agent to queue or publish a Threads post. 3. The agent sends a request to `/api/v1/threads/publish` with `THREADS_QUEUE_SECRET` in the `X-Queue-Secret` header. 4. A network-positioned at ...[truncated 690 chars]
Remediation
<![CDATA[ ## Remediation Suggestions - Require HTTPS for every non-loopback backend URL. - Permit plaintext HTTP only when the resolved destination is strictly `127.0.0.1`, `::1`, or an explicitly approved local endpoint. - Reject URLs containing embedded credentials, ambiguous host representations, or unsupported schemes. - Validate the destination again after DNS resolution to reduce hostname-based bypasses. - Disable automatic redirects for authenticated requests, or validate every redirect target before forwarding the secret. - Maintain an explicit allowlist of approved backend origins where operationally possible. - Use a narrowly scoped, revocable credential and rotate it immediately if plaintext transmission may have occurred. - Update the safety guidance to state that `X-Queue-Secret` must never be transmitted over remote plaintext HTTP. ]]>

other

Note
Location
SKILL.md:64
Finding
Default Payload Discloses Unnecessary Telegram Identifiers<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 64-72 **Vulnerability Type**: Excessive personal data disclosure **Risk Level**: Low ### Vulnerable Code ```json "meta": { "tenant_id": "agency_paris", "source": "telegram", "chat_id": "<tg chat id>", "user_id": "<tg user id>", "username": "<tg username>" } ``` ### Technical Analysis The standard publishing payload instructs the agent to send a Telegram chat identifier, user identifier, and username to the configured FastAPI backend. The documentation does not demonstrate that these personal identifiers are necessary to generate, queue, schedule, or publish a Threads post. Including these values by default violates data-minimization principles and expands the amount of user information exposed to the backend, its logs, monitoring systems, storage providers, and downstream integrations. Because the backend URL is configurable, the recipient may be an external service operated under different retention or access policies. ### Attack Path 1. A user asks the agent to queue, schedule, or publish Threads content. 2. The agent constructs the documented payload and populates the Telegram metadata fields. 3. The payload is transmitted to the configured FastAPI backend. 4. The backend or its infrastructure records, processes, or forwards the identifiers. 5. A backend operator, compromised service, log reader, or downstream integration obtains information that can correlate the user's Telegram identity with their Threads publishing activity. ### Impact Assessment The exposed data can enable identity correlation, activity tracking, profiling, or unwanted disclosure of Telegram account information. The issue does not directly grant system privileges or code execution. Its scope is limited to the personal identifiers transmitted and any records or downstream systems where the backend retains or propagates them. ]]>
Remediation
<![CDATA[ ## Remediation Suggestions - Remove `chat_id`, `user_id`, and `username` from the default publishing payload. - Send only metadata demonstrably required to complete the requested operation. - If correlation is necessary, use a short-lived or pseudonymous request identifier instead of stable personal identifiers. - Obtain informed user consent before transmitting identity data to a backend. - Document the purpose, retention period, access controls, and downstream processing for every collected field. - Ensure sensitive metadata is excluded from application, proxy, and observability logs. - Provide backend-side schema validation that rejects unnecessary personal fields. ]]>
Vulnerability Patterns
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Trigger AbuseOverly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
Findings (3)

Vague Triggers

Medium
Confidence
91% confidence
Finding
The README instructs the agent to invoke the skill whenever a user asks to generate, queue, schedule, or publish Threads content, which is a broad trigger set for an action-capable skill. Because this skill can cause outbound API calls that enqueue or publish content to a production backend, ambiguous user requests could unintentionally activate posting behavior without sufficient confirmation or scope checks.

Missing User Warnings

Medium
Confidence
95% confidence
Finding
The skill description does not clearly warn that user message content and associated metadata like chat ID, user ID, and username will be sent to an external/backend service. This omission weakens informed consent and can lead to privacy and data-handling surprises, especially because the payload examples explicitly include identifiable metadata and backend routing information.

Vague Triggers

Medium
Confidence
95% confidence
Finding
The trigger guidance is broad enough to activate on common requests to generate, queue, schedule, or publish content, which can cause the skill to engage in situations the user may not realize involve a backend side effect. In this skill’s context, that matters because activation leads to transmission of user content and metadata to a FastAPI service and may enqueue or publish posts, increasing the chance of unintended external actions.