Back to skill

Security audit

multi-account-config

Security checks for vulnerabilities and agentic risk

Overview

The skill does what it says, but it handles bot credentials and changes gateway access settings with weak default group access and limited confirmation guidance.

Review this skill before installing. Only use it in an admin setup session, treat bot tokens as secrets, confirm the exact config before applying it, and change group access from open to a restrictive policy unless unrestricted group access is truly intended.

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 (1)

T09 · Insecure Skill Coding Practices

Warning
Location
SKILL.md:68
Finding

Messaging Accounts Use an Unrestricted Group Access Policy by Default

Content
View full analysis

Vulnerability Details

File Location: SKILL.md, lines 68 and 139
Vulnerability Type: Insecure default configuration
Risk Level: Medium

Vulnerable configuration template (lines 62–70):

json
{
  "name": "<Display Name>",
  "enabled": true,
  "dmPolicy": "allowlist",
  "allowFrom": ["<user-id>"],
  "botToken": "<token>",
  "groupPolicy": "open",
  "streaming": "block"
}

Vulnerable Telegram example (lines 133–141):

json
{
  "name": "Work",
  "enabled": true,
  "dmPolicy": "allowlist",
  "allowFrom": ["USER_ID"],
  "botToken": "123456:ABC-DEF...",
  "groupPolicy": "open",
  "streaming": "block"
}

Technical Analysis

The prescribed configuration template and the concrete Telegram example both assign the account an unrestricted group policy through "groupPolicy": "open". This weakens the otherwise restrictive direct-message configuration established by "dmPolicy": "allowlist".

The workflow does not instruct the agent to ask whether unrestricted group access is required, identify trusted groups, or obtain informed user approval before applying the open policy through gateway config.patch. Consequently, users following the documented workflow can unintentionally expose the connected agent to messages from untrusted group participants.

Attack Path

  1. A user invokes the Skill to add a messaging account.
  2. The agent constructs the account configuration from the prescribed template.
  3. The configuration is applied with groupPolicy set to open without explicit user approval.
  4. The configured bot is added to, or is already present in, a group containing an untrusted participant.
  5. The participant sends adversarial or abusive messages to the bot.
  6. Subject to the messaging platform and gateway's group-message handling, those messages reach the connected agent and can be used for prompt-injection attempts, unauthorized invo ...[truncated 646 chars]
Remediation
View remediation

Remediation Suggestions

  1. Change the default group policy to the most restrictive supported value:

    json
    "groupPolicy": "closed"
    

    Alternatively, use "admin-only" where group operation is required.

  2. Add a workflow step that explicitly asks the user to choose the group-access policy before configuration is applied.

  3. Require clear confirmation before enabling "open" and explain that any group participant may be able to interact with the agent.

  4. Where supported, restrict access to an explicit allowlist of trusted group IDs and sender IDs.

  5. Preserve restrictive existing policies when merging configuration rather than replacing them with the template default.

  6. After applying the configuration, verify the effective access policy and report which groups or users can reach the account without exposing credentials.

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
Category
Not specified by scanner
Confidence
92% confidence
Finding

The trigger description includes broad phrases such as 'add work account' and 'configure multiple accounts', which can cause the skill to activate on routine conversation that was not intended to modify messaging configuration. In this skill's context, unintended invocation is more dangerous because the workflow proceeds toward collecting secrets and patching gateway configuration, increasing the chance of accidental credential handling or unauthorized config changes.

Content

No source excerpt is available for this finding.

Natural-Language Policy Violations

Medium
Category
Not specified by scanner
Confidence
95% confidence
Finding

Step 1 instructs the agent to ask the user a question only in Chinese: "你想配置哪个平台的多账号?..." There is no indication that the skill is China-specific or that the user can choose another language, which creates a language-policy issue for general users.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium
Category
Not specified by scanner
Confidence
95% confidence
Finding

The skill instructs the agent to collect highly sensitive credentials like bot tokens and then modify gateway configuration, but it does not require an explicit warning, consent step, or safe secret-handling procedure before doing so. This is dangerous because accidental disclosure, insecure retention, or unauthorized config changes could expose messaging accounts or let an attacker rebind channels under their control.

Content

No source excerpt is available for this finding.