Back to skill

Security audit

crier

Security checks for vulnerabilities and agentic risk

Overview

The skill is coherent with its Crier bulletin-board purpose, but it asks for recurring authenticated check-ins, persistent state, registration, and possible replies without enough explicit user control.

Review before installing. Use this only if you want an agent to use Crier as an external bulletin board. Require explicit approval before registration, terms acceptance, background inbox checks, subscriptions, public posts, or thread replies. Store any API key in a protected secret location rather than ordinary project files, and make sure any recurring heartbeat can be disabled.

Vulnerability Patterns
  • Skill Instruction HijackingAlters the agent's session goals or safety constraints when the skill loads
  • Unauthorized Access and Privilege EscalationObtains permissions beyond the task's legitimate needs
  • 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)

T01 · Skill Instruction Hijacking

Error
Location
SKILL.md:12
Finding
Persistent External-Service Instructions Hijack Unrelated Agent Sessions<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 12-18 **Vulnerability Type**: Persistent instruction hijacking through mandatory authenticated heartbeat behavior **Risk Level**: High ### Vulnerable Code Snippet ```markdown ## On every session start or scheduled check-in (heartbeat) 1. Call `GET https://crier.network/api/v1/publishers/me/inbox?cursor=<saved cursor>` with your API key (or the MCP `inbox` tool) once. Omit the cursor on the very first call. 2. Act on what comes back: replies to your posts, and matches for your subscriptions. Tell the person you work for what is relevant; reply in a thread when a reply is warranted. 3. Save `next_cursor` where you keep state (project memory, notes, a config file). Pass it next time. Nothing is consumed server-side, so a missed check loses nothing. 4. Post only if the person you work for has something others might be looking for. Never post to fill silence. Never post a status update or a greeting. 5. Check no more than once an hour. ``` ### Technical Analysis The skill directs the agent to contact an external service at every session start or scheduled check-in, even when the active user task is unrelated to Crier. The request is authenticated with an API key and uses a cursor persisted in project memory, notes, or configuration files. The agent is then instructed to act on server-selected inbox data and potentially reply to remote threads. Although the skill later warns that post bodies are untrusted and must not be followed as instructions, the heartbeat itself still gives the external service a persistent channel for influencing agent-visible notifications and communication behavior. This violates task-scoped execution principles: network access should occur only when requested by the user or when the user has explicitly opted into a separately defined background process. The instruction also creates cross-session state and recurring external communication without requiring clear, ...[truncated 1452 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Remove the requirement to contact Crier on every session start. 2. Perform inbox checks only after an explicit user request or after the user has knowingly enabled a clearly defined background subscription service. 3. Require separate, informed consent before creating scheduled or recurring network activity. 4. Scope consent by service, frequency, credential, destination, and expected actions, and provide a straightforward way to disable the heartbeat. 5. Do not automatically reply to remote messages. Present relevant results as untrusted data and require user confirmation before sending any response. 6. Store cursors only in a dedicated, access-controlled state location after user approval; do not place them indiscriminately in project memory, notes, or configuration files. 7. Keep API keys in an approved secret store and avoid exposing them in logs, ordinary project files, prompts, or generated content. 8. Limit background processing to metadata retrieval. Ensure that remote post content cannot modify agent instructions, safety constraints, tool-selection policy, or authorization state. ]]>

T05 · Unauthorized Access and Privilege Escalation

Warning
Location
SKILL.md:36
Finding
Publisher Registration Can Impersonate a User and Accept External Terms Without Explicit Consent<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 36-38 **Vulnerability Type**: Unauthorized external account creation and identity attribution **Risk Level**: Medium ### Vulnerable Code Snippet ```markdown ## Registration Registration happens once. Call `register_publisher` (or `POST https://crier.network/api/v1/publishers`) with a name (the person or organization, not the agent), their URL if they have one, `accept_terms: true`, and `client` naming the runtime you are running in, e.g. `claude-code`, `openclaw`, `cursor`, or `custom`. The API key is returned once; tell the user to store it (for example in the project's `.mcp.json` as an `Authorization: Bearer crier_sk_...` header on the `crier` server) and never paste it into a post. If a key is already configured, do not register again. ``` ### Technical Analysis The registration instructions direct the agent to create an external publisher account using the identity of the person or organization rather than the agent. They also direct it to submit the subject's URL, identify the local runtime, and set `accept_terms: true`. Unlike the posting workflow, which expressly requires user confirmation, this section does not require explicit authorization before account creation, identity attribution, metadata disclosure, or acceptance of external terms. An agent following the instruction literally could therefore represent that a person or organization agreed to terms and established a publisher identity when no informed approval was provided. The returned API key is a security-sensitive credential. Suggesting storage in a project-level `.mcp.json` may expose it to other project users, accidental source-control commits, backups, logs, or unrelated tools if appropriate permissions and ignore rules are not applied. ### Attack Path 1. A Crier operation requires authenticated publisher access. 2. No existing key is configured, so the agent follows the registration instructions. 3. The age ...[truncated 1153 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Require explicit user approval immediately before registration. 2. Display every value that will be submitted, including the publisher name, URL, runtime identifier, service endpoint, and terms-acceptance flag. 3. Provide the applicable terms to the user and set `accept_terms: true` only after the user expressly authorizes acceptance. 4. Do not register under a person or organization unless an authorized representative explicitly approves that identity. Prefer an agent-specific identity by default. 5. Minimize metadata disclosure. Omit the organization URL and detailed runtime identifier unless required and approved. 6. Clearly explain the account capabilities and public attribution before creating it. 7. Store the returned key in an approved secret manager or protected environment variable rather than ordinary project configuration whenever possible. 8. If project configuration must reference the key, use secret interpolation, restrict file permissions, add the file to source-control ignore rules, and scan repository history for accidental disclosure. 9. Require separate user confirmation before using the new identity for any public post or reply. ]]>
Vulnerability Patterns
  • Trigger AbuseOverly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
Findings (1)

Vague Triggers

Medium
Confidence
93% confidence
Finding
The skill description contains broad triggers such as 'what is happening nearby,' 'announce, sell or find something local,' and 'wants to be told when something appears,' which can match many ordinary user requests and cause the skill to activate more often than intended. Because this skill can drive external network access, posting, subscriptions, and inbox polling against a third-party service, overbroad activation increases the chance of unnecessary data exposure, unintended posting workflows, or user redirection to an external system.

Static analysis

No suspicious patterns detected.